![[xml logo]](xml.gif)
XMLMis à jour sous l'égide du Groupe d'intérêt spécial (SIG) XML du Consortium World Wide Web par Peter Flynn (University College Cork), avec la collaboration de Terry Allen (), Tom Borgman (Harlequin Ltd), Tim Bray (Textuality, Inc), Robin Cover (Isogen, Inc), Bob DuCharme (Moody's), Christopher Maden (O'Reilly & Associates), Eve Maler (Arbortext, Inc), Peter Murray-Rust (Nottingham University), Liam Quin (Groveware), Michael Sperberg-McQueen (University of Illinois at Chicago), Joel Weber (MIT), Murata Makoto (Fuji Xerox Information Systems) et avec la participation de nombreux autres membres du Groupe d'intérêt spécial XML du W3C et des lecteurs du monde entier de cette FAQ.
Pour apporter toute correction ou information complémentaire, veuillez utiliser le formulaire en fin de document.
Ce document reprend les questions les plus fréquemment posées (FAQ ou foire aux questions) -- ainsi que leurs réponses -- sur le thème du XML (Extensible Markup Language, langage extensible de balisage). Elles ont pour but de fournir aux utilisateurs, développeurs et autres lecteurs intéressés par le sujet un premier niveau d'information, mais ne sauraient en aucune sorte faire partie de la norme XML.
Cette FAQ comporte quatre parties : a) Général, b) Utilisateur, c) Auteur et d) Développeur. Les questions sont numérotées indépendamment les unes des autres à l'intérieur de ces parties. Dans la mesure où cette numérotation évolue avec chaque version du document, il est préférable d'indiquer le numéro de la version (voir l'historique des révisions ci-dessus) ainsi que le numéro de la partie et de la question dans les commentaires et suggestions apportés.
Un formulaire est à
votre disposition en fin de document : vous pouvez y mentionner les bogues
que vous auriez décelées, vos suggestions pour améliorer
ce document, ou tout autre commentaire concernant uniquemen cette FAQ
(vous pouvez aussi envoyer un courrier électronique au responsable du
document : pflynn@imbolc.ucc.ie). Les
commentaires concernant la norme XML sont à
adresser directement au W3C.
§ Merci à Murata Makoto pour la traduction de ce document en japonais (http://www.fxis.co.jp/DMS/sgml/xml/xmlfaq.html) ; à Jaime Sagarduy pour la traduction en espagnol (http://slug.ctv.es/~olea/sgml-esp/xfaq13.html) ; à Kangchan Lee pour la traduction en coréen (http://xml.t2000.co.kr/faq/index.html) ; à Jiang Luqin pour une version en chinois (en préparation) et à Neko pour une autre à http://zxd.webjump.com/xml.html) ; à Miloslav Nic pour une version tchèque (en préparation) et à Tim Bray pour les Annotated Spec - annotations apportées aux spécifications - (http://www.xml.com/axml/testaxml.htm). Une version grecque est également en cours de rédaction.
§ Vous pouvez télécharger le logo XML en format GIF ou EPS et une icône pour vos fichiers en format ICO (Microsoft Windows), Mac, ou XBM (système X Window).
A.5 XML, SGML et HTML n'est-ce pas la même chose ?
A.6 Quelles différences y a-t-il entre SGML/XML et C ou C++
A.7 Qui est responsable de XML ?
A.8 Pourquoi le développement de XML est-il si important ?
A.10 Pourquoi ne continue-t-on pas à développer HTML ?
A.11 À quoi servent tous ces trucs en SGML ? Pourquoi ne pas tout simplement utiliser Word ou Notes?
A.12 Où puis-je obtenir plus d'informations sur XML ?
A.13 Où puis-je discuter de
développement et d'implémentation de XML ?
B.1 Que dois-je faire pour utiliser XML ?
B.2 Pourquoi devrais-je utiliser XML plutôt que HTML ?
B.3 Où puis-je trouver un navigateur XML ?
B.4 Est-ce-que je dois passer de SGML ou
HTML à XML ?
C.1 Est-ce que XML remplace HTML ?
C.2 A quoi ressemble l'intérieur d'un document XML ?
C.3 Comment XML traite-t-il les espaces blancs présents dans mes documents ?
C.4 Quelles parties d'un document XML dépendent de la casse ?
C.5 Comment faire pour que mes fichiers HTML fonctionnent en XML ?
C.6 Y a-t-il une version XML de HTML ?
C.8 Je suis habitué à utiliser HTML. Est-ce que je peux apprendre XML facilement ?
C.9 XML pourra-t-il utiliser des alphabets non latins ?
C.10 Qu'est-ce qu'une définition de type de document (DTD) ? Où en obtenir une ?
C.11 Je reste attentif à des alternatives aux DTD. Qu'est-ce qu'un schéma ?
C.12 Comment XML modifiera-t-il les liens de mes documents ?
C.13 Puis-je faire des maths avec XML ?
C.14 Comment XML gère-t-il les méta-données ?
C.15 Puis-je utiliser Java, ActiveX, etc. dans XML ?
C.16 Puis-je utiliser Java pour créer ou gérer des fichiers XML ?
C.17 Comment contrôler la présentation ?
C.18 Comment utiliser les graphiques en
XML ?
D.2 Que signifient les termes « sans DTD », « valide » et « bien formé » ?
D.2.1 Documents « bien formés »
D.3 Que dois-je utiliser dans ma DTD : des attributs ou des éléments ?
D.4 Quoi d'autre a changé de SGML à XML ?
D.5 Quels logiciels XML puis-je utiliser aujourd'hui ?
D.6 Dois-je changer mes serveurs pour travailler avec XML ?
D.7 Puis-je encore utiliser les INCLUDE côté serveur ?
D.8 Puis-je (ainsi que mes auteurs) encore utiliser les INCLUDE côté clients ?
D.10 Existe-t-il un kit API de développeurs pour XML ?
D.11 Comment XML réagit-il avec les DOM ?
D.12 Existe-t-il un jeu de tests de conformité pour les processeurs XML ?
D.13 Comment inclure une DTD (ou un morceau) dans une autre ?
D.14 Je possède déjà des DTD en SGML : comment les convertir pour les utiliser avec XML ?
D.15 Qu'en est-il de XML et de
l'EDI ?
XML signifie Extensible Markup Language (langage extensible de balisage.). Ce langage est dit extensible car, contrairement à HTML, il ne s'agit pas d'un format fixe. Son but est de permettre d'utiliser SGML sur le World Wide Web.
§ XML n'est pas un simple langage de balisage prédéfini. C'est un méta-langage -- un langage qui permet de définir d'autres langages -- qui vous permet de concevoir votre propre balisage. Un langage de balisage prédéfini comme HTML définit une façon de décrire les informations pour une certaine classe de documents : XML vous permet de définir vos propres langages de balisage personnalisés pour un ensemble de classes de documents. Ceci est possible parce que XML est écrit en SGML, le méta-langage international normalisé de balisage.
XML est conçu pour « rendre l'utilisation de SGML sur le Web facile et directe : il sera facile de définir des types de documents, facile de créer et de gérer des documents définis en SGML et facile de les transmettre et de les partager sur le Web. »
XML définit un « dialecte ou sous-ensemble de SGML extrêmement simple, que la spécification XML décrit complètement. Avec XML, l'objectif est d'envoyer, de recevoir et de traiter du SGML générique comme il est aujourd'hui possible avec HTML
« C'est pourquoi XML a été développé pour sa facilité de mise en oeuvre et son interopérabilité avec SGML et HTML » [citations extraites de la spécification XML].
SGML signifie Standard Generalized Markup Language (ISO 8879), langage normalisé de balisage généralisé ; c'est la norme internationale pour décrire la structure et le contenu de différents types de documents électroniques. La FAQ sur SGML (http://www.infosys.utas.edu.au/info/sgmlfaq.txt) est envoyée chaque mois au newsgroup comp.text.sgml ; les pages Web en SGML sont disponibles à http://www.oasis-open.org/cover/sgml-xml.html.
Les normes ISO sont gouvernées par l'Organisation Internationale de Normalisation à Genève (Suisse). Leur existence ou disparition est votée par les représentants des organismes de normalisation de chaque pays.
HTML signifie HyperText Markup Language (RFC 1866) (langage de balisage avec liens hypertextes). C'est une application spécifique de SGML utilisée sur le World Wide Web.
Pas exactement. SGML, c'est la « langue maternelle » utilisée pour décrire des milliers de types de documents différents dans de nombreux champs de l'activité humaine, de la transcription des anciens manuscrits irlandais à la documentation technique des bombardiers furtifs et des dossiers médicaux de patients jusqu'aux partitions de musique.
§ HTML n'est qu'un de ces types de documents, celui qui est le plus utilisé sur le Web. HTML définit un type de document unique, fixe, dont le balisage a été défini pour une classe commune de rapports simples de type « bureau » ou de rapports techniques, avec des entêtes, des paragraphes, des listes, des illustrations, etc. et avec la possibilité d'éléments hypertextes et multimedia.
XML est une version abrégée de SGML, qui permet de définir ses propres types de documents plus facilement, et qui permet aux programmeurs de développer plus facilement des programmes permettant de traiter ces documents. Les parties les plus complexes et les moins utilisées de SGML ont été supprimées. Du coup, ce produit a gagné en avantages : écriture d'applications plus facile, compréhension plus aisée et produit mieux adapté à sa mise en place et à son interopérabilité sur le Web. Mais il s'agit toujours de SGML et les fichiers XML peuvent toujours être analysés et validés comme tout autre fichier SGML (voir la question sur les logiciels XML).
Les programmeurs trouveront peut-être pratique de considérer XML comme un SGML-- plutôt qu'un HTML++.
C ou C++ (et autres langages comme Fortran, Pascal, Basic, Java et des dizaines d'autres) sont des langages de programmation qu'on utilise pour spécifier des calculs, des actions ou des décisions à prendre :
do when @front(@date,6) is equal "01-Apr"
print "April Fool!\n"
else
print @days(@datesub("25-Dec",@date)),\
" shopping days to Christmas\n"
done
SGML et XML sont des langages de spécification de balisage qu'on utilise pour décrire des informations, en général pour le stockage, la transmission ou pour être traités par un programme :
<para>It was the week after <event class="festival">Christmas</event>
but <name class="person">Max</name>s mind was still running on the
prank he had played on <name class="person">Louise</name> the previous
<name class="month">April</name>.</para>
Tout seuls, des fichiers-textes en SGML ou XML (y compris HTML) ne font rien du tout : il faut un programme qui en fasse quelque chose.
XML est un projet duWorld Wide Web Consortium (W3C) et le développement de sa norme est supervisé par son Groupe de travail XML. Un Groupe d'intérêt spécial composé de collaborateurs admis par cooptation et d'experts issus de divers domaines a apporté commentaires et révisions via le courrier électronique.
XML est un format public : aucune société n'est propriétaire de son développement. La spécification v1.0 a été entérinée par le W3C (recommandation du 10 février 1998).
XML permet de supprimer deux contraintes qui limitent les développements du Web :
Pour simplifier SGML, XML redéfinit certaines fonctions et certains paramètresSGML et supprime un grand nombre des fonctions les plus complexes et parfois les moins utilisées qui rendent l'écriture de programmes de traitement difficile (voir http://www.w3.org/TR/NOTE-sgml-xml-971215).
§ Même si XML garde toutes les fonctions de structure de SGML qui permettent de définir son propre type de document, XML introduit aussi une nouvelle classe de documents qui n'oblige pas à utiliser un type de document prédéfini (en gros, on peut définir son propre balisage à condition de suivre rigoureusement les règles syntaxiques). Voir les questions sur les documents « valides » et « bien formés » et la question Comment définir vos propres types de documents ? dans la Partie Développeur.
HTML est déjà surchargé de dizaines d'inventions de divers constructeurs intéressantes mais souvent incompatibles car il ne prévoit qu'une seule manière de décrire vos informations.
XML permettra à des groupes de personnes ou à des organisations de créer leurs propres langages de balisage personnalisés afin d'échanger des informations dans leurs domaines (musique, chimie, électronique, randonnée, finance, surf, géologie pétrolière, linguistique, cuisine, tricot, cartographie stellaire, histoire, ingénierie, élevage de lapins, mathématiques, etc).
HTML a atteint les limites de son utilité en tant que descripteur d'informations. Et même s'iil continue à jouer un rôle important pour le contenu qu'il représente aujourd'hui, de nombreuses autres applications nécessitent une infrastructure plus robuste et plus flexible.
§ Les informations qui circulent sur un réseau qui relie différents types d'ordinateurs doivent être utilisables par tous ces ordinateurs. Les informations publiques ne peuvent pas se restreindre à une seule marque ou à un seul modèle ou à un seul fabricant, ni ne peuvent céder le format de leurs données à des mains privées. De plus il est pratique que ces informations soient dans un format qui puisse être réutilisé de différentes façons, de manière à réduire temps et effort. Les formats de données propriétaires, même lorsqu'ils sont bien documentés, ne sont pas utilisables : leur contrôle reste dans les mains de privés et ils peuvent être changés ou retirés arbitrairement sans préavis.
§ SGML est la norme internationale utilisée pour définir ce type d'applications. Mais les personnes ayant besoin d'une option différente basée sur un autre logiciel sont entièrement libres de mettre en place des services similaires en utilisant ce système et plus particulièrement s'ils sont conçus pour un usage privé.
Divers documents émanant du W3C sont disponibles en ligne : la Spécification XML et la documentation qui s'y rapporte ; une section XML avec une longue liste de matériels de référence en ligne sur les pages SGML de Robin Cover ; un résumé et une FAQ condensée de Tim Bray.
Les manifestations ci-dessous sont celles dont on m'a parlées : merci de me contacter par courrier électronique si vous en trouvez d'autres.
La Conférence annuelle XML est organisée par la Graphic Communications Association. XML99 aura lieu à Philadelphie du 5 au 9 décembre et comprendra, comme l'an dernier, deux conférences en une : XML Conference 99 et Markup Technologies 99.
SGML/XML Asia/Pacific aura lieu à Sydney du 18 au 21 octobre.
De plus amples informations sur ces manifestations sont disponibles sur le site Web du GCA.
Les pages SGML et XML de Robin Cover proposent une liste des livres et articles sur XML : ce site devrait toujours être votre principale ressource : merci de le consulter avant d'utiliser le formulaire de cette FAQ pour poser des questions sur les logiciels et la documentation.
NoteMerci de lire le fichier Read The Fine Documentation (Lire la documentation détaillée) que vous recevez en vous abonnant à une liste de discussion. En effet, il contient des informations importantes, notamment sur ce qu'il faut faire si votre adresse de courrier électronique change.
Une liste de diffusion appelée xml-dev est accessible aux personnes impliquées dans le développement de composants pour XML. Pour vous abonner à cette liste, envoyez un courrier électronique d'une ligne à majordomo@ic.ac.uk en indiquant :
subscribe xml-dev votre_nom@votre_adresse
(en substituant votre adresse électronique). Pour vous désabonner, envoyez un message d'une seule ligne à la même adresse, disant :
unsubscribe xml-dev votre_nom@votre_adresse
On peut aussi accéder à cette liste à l'adresse http://www.lists.ic.ac.uk/hypermail/xml-dev/. Attention : cette liste s'adresse aux personnes réellement concernées par le développement de ressources pour XML. Il ne s'agit pas d'informations générales sur XML (voir la FAQ et les autres sources) ni de discussions générales sur la mise en place de SGML ni sur les ressources SGML (voir ci-dessous).
Une liste de diffusion du domaine général appelée XML-L est accessible pour des discussions publiques. Pour vous abonner à cette liste, envoyez un courrier électronique d'une ligne à LISTSERV@listserv.heanet.ie en indiquant :
subscribe XML-L prénom nom
(remplacez ces libellés par vos propres prénom et nom). Pour vous désabonner, envoyez un courrier électronique d'une ligne à la même adresse en indiquant :
unsubscribe XML-L
À noter que les listes comme LISTSERV ne demandent pas votre adresse électronique : elles la trouvent dans l'entête de votre message. On peut accéder à XML-L et à ses archives, ou s'abonner et se désabonner interactivement, par http://listserv.heanet.ie/xml-l.html
NoteNotez qu'il y a un grand nombre d'informations erronées ou incomplètes qui trainent dans des documents papier ou sur le Web à propos des listes de discussions. Les informations données ici sont correctes : utilisez les !
¶ Certaines listes de discussions concernent des langues autres que l'anglais :
Gianni Rubagotti signale : « Une nouvelle liste italienne de discussion sur XML est née : pour s'abonner, envoyer un message (sans sujet) disant
subscribe XML-IT
à majordomo@ananas.usr.dsi.unimi.it. Envoyez vos messages de discussion à : xml-it@ananas.usr.dsi.unimi.it (seuls les abonnés peuvent envoyer un mesage). Toute personne, italienne ou non, désirant débattre de XML en italien est bien venue. »
JP Theberg écrit : « Une liste française sur XML a été créée. Pour s'abonner, envoyez subscribe à xml-request@trisome.com. Envoyez vos messages ensuite à xml@trisome.com.
§ Le newsgroup USENET comp.text.xml sert aux discussions sur XML. S'il n'est pas disponible sur votre serveur local, demandez à votre fournisseur d'accès à d'Internet de l'installer, ou utilisez une interface Web comme déjàNews.
§ Pour l'utilisateur du Web moyen, rien sauf d'utiliser un navigateur qui marche avec XML (voir les questions sur les navigateurs). Rappelons que XML est encore en cours d'implémentation, aussi certaines possibilités ne sont pas encore définies ou sont encore à écrire.
On peut utiliser des navigateurs XML pour voir des produits naissants, comme les pièces de Shakespeare de Jon Bosak ou les expériences sur les molécules du CML (Chemical Markup Language -- langage de balisage pour la chimie). On trouvera d'autres exemples dans http://www.oasis-open.org/cover/xml.html#examples.
Pour commencer à vous préparer à écrire votre propre XML, voir les questions dans les parties Auteurs et Développeurs.
Souvenez-vous que la spécification XML est encore récente, donc tout ce que vous voyez est encore expérimental. Comme avec HTML, il n'y aura pas qu'un seul navigateur mais plusieurs. Cependant, parce que le nombre potentiel d'applications XML différentes n'est pas limité, on ne peut attendre d'aucun navigateur donné qu'il traite tous les cas à 100%.
§ Certaines parties génériques de XML (par exemple l'analyse, la gestion d'arbres, la recherche, le formatage, etc) sont combinées dans des bibliothèques de navigateurs ou boîtes à outils (toolkits) pour rendre la tâche plus facile et rigoureuse aux développeurs lorsqu'ils développent des applications XML. De telles applications peuvent ensuite être personnalisées par l'ajout de sémantique propre à des marchés donnés, ou par l'utilisation de langages tels que Java pour développer des plugins pour navigateurs génériques et pour délivrer des modules spécialisés transparents pour le Web.
§ MSIE5 traite XML mais l'affiche par le biais de CSS, en utilisant un modèle très largement emprunté à HTML, aussi toutes les options de feuilles de style ne marchent-elles pas. Microsoft a aussi défini l'architecture d'une solution hybride dans laquelle on peut mélanger des morceaux de XML dans un fichier HTML puisque les navigateurs spécifiques à HTML ignorent simplement les balises qu'ils ne reconnaissent pas.
§ Le code Netscape à diffusion publique (Mozilla) a débouché sur une implémentation test de XML comprenant une application de RDF et l'analyseur XML expat de James Clark.
Les auteurs du navigateur SGML MultiDoc Pro, CITEC, ont fait un gros effort avec Mozilla pour produire un navigateur multi-tout appelé DocZilla qui lit HTML, XML et SGML, avec XSL et les feuilles de style CSS. Ça marche sous NT et linux et est actuellement en version alpha. Voir http://www.doczilla.org pour plus de détails. C'est vraiment du début d'alpha, mais c'est de loin la version la plus ambitieuse et la seule qui soit basée sur une réelle expertise SGML.
Voir aussi les notes sur les logiciels pour les auteurs et les développeurs et la liste plus détaillée de pages XML disponible sur le site Web SGML à l'adresse http://www.oasis-open.org/cover/xml.html.
Non, les logiciels existants pour applications SGML et HTML continueront à fonctionner avec les fichiers existants. Mais comme c'est le cas avec toute fonction améliorée, si vous voulez visualiser ou télécharger et utiliser des fichiers XML, il vous faudra ajouter dès qu'il y en aura sur le marché, un logiciel qui reconnaisse XML.
Les auteurs devraient également lire la partie Développeur : elle contient de
plus amples informations sur le contenu des fichiers XML.
§ Non, XML en soi ne remplace pas HTML : il constitue en fait une alternative qui vous permet de définir vos propres éléments de balisage. HTML devrait encore être utilisé pendant un certain temps. Les DTD pour HTML seront ensuite disponibles au format XML ainsi qu'au format original SGML. XML est conçu pour rendre l'écriture de DTD plus facile qu'avec SGML complet (voir les questions sur les DTD pour savoir ce que c'est et pourquoi vous n'en voulez pas).
Des travaux en cours devraient conduire à la conception de versions XML de DTD HTML et autres DTD connues, mais ceci ne pourra se faire avant que des logiciels plus fiables ne soient disponibles. Surveillez les annonces sur comp.text.sgml, comp.text.xml, XML-L et xml-dev.
La structure de base ressemble énormément à celle de la plupart des applications de SGML y compris HTML. Les documents XML peuvent être très simples, sans déclaration de type de document, et avec un balisage de votre conception directement imbriqué :
<?xml version="1.0" standalone="yes"?>
<conversation>
<greeting>Hello, world!</greeting>
<response>Stop the planet, I want to get off!</response>
</conversation>
Ces documents peuvent également être plus complexes, avec une DTD donnée, et peut-être un sous-ensemble interne et une structure plus complexe :
<?xml version="1.0" standalone="no" encoding="UTF-8"?>
<!DOCTYPE titlepage SYSTEM "http://www.frisket.org/dtds/typo.dtd"
[<!ENTITY % active.links "INCLUDE">]>
<titlepage>
<white-space type="vertical" amount="36"/>
<title font="Baskerville" size="24/30"
alignment="centered">Hello, world!</title>
<white-space type="vertical" amount="12"/>
<!-- In some copies the following decoration is
hand-colored, presumably by the author -->
<image location="http://www.foo.bar/fleuron.eps" type="URL" alignment="centered"/>
<white-space type="vertical" amount="24"/>
<author font="Baskerville" size="18/22" style="italic">Vitam capias</author>
</titlepage>
Ils peuvent également se situer à mi-chemin entre ces deux options : cela dépendra essentiellement de la façon dont vous définirez votre type de document (ou celui que vous utiliserez) et de son usage. Voir la question sur les fichiers valides et bien formés.
§ Les règles de SGML concernant les espaces blancs ou séparateurs ont été modifiées pour XML. Ainsi, tous les séparateurs, y compris les sauts de lignes, les tabulations et les espaces normaux, même entre les éléments où aucun texte ne peut apparaître, passent tels quels dans l'application (navigateur, logiciel de formatage, visionneur, etc). Cela signifie que :
<chapter>
<section>
<title>
My title for Section
1.
</title>
<para>
...
</para>
</section>
</chapter>
§ Le parser doit toutefois indiquer à l'application si tel séparateur est apparu dans tel contenu élémentaire, s'il est connu. (Les utilisateurs de SGML intégral reconnaîtront peut-être que cette information n'apparaît pas dans le ESIS Element Structure Information Set), mais elle figure bel et bien dans le grove (Graph representation of Property Values).) Dans l'exemple ci-dessus, l'application recevra tous les sauts de ligne, tabulations et espaces entre les éléments ainsi que ceux emboïtés dans le titre de section. Il revient à l'application (navigateur, logiciel de formatage, visionneur, etc.) de décider du type de séparateur à supprimer ou à garder.
Tous les éléments de fichiers XML, balisage comme texte, dépendent de la casse. Ceci diffère considérablement du HTML et de la plupart des autres types de documents SGML. Cette contrainte a été mise en place pour permettre le balisage dans des écritures en alphabet non Latin et pour éviter des problèmes avec le traitement des différences entre minuscules et majuscules pour des écritures qui ne connaissent pas une telle différence.
il est donc impossible de dire <BODY> . . . </body> : les majuscules et minuscules doivent correspondre ; par conséquent, <IMG/> et <img/> sont deux types d'élément différents ;
§ Ils doivent être bien formés (voir ci-dessous) et associés à une feuille de style. Une DTD est facultative avec XML, mais les fichiers HTML convertis au format XML doivent aujourd'hui de toute façon n'avoir aucune DTD : il n'existe encore aucune version XML des actuelles DTD HTML de type SGML (en cours de développement) parce qu'elles doivent être considérablement modifiées pour ne plus dépendre des fonctions du SGML exclues du XML.
Il est nécessaire de convertir les fichiers HTML existants afin qu'ils soient bien formés, XML interdisant la suppression des balises de fermeture (absence de </p>, etc.), autorisée dans la plupart des DTD HTML. De nombreux éditeurs HTML produisent déjà du XML presque bien formé (mais pas tout à fait). Pour se préparer à XML, le programme HTML Tidy est recommandé pour nettoyer certaines erreurs de formatage tolérées ou produites par des éditeurs HTML trop tolérants.
Si vous voulez transformer vos fichiers HTML en un autre type de DTD, le site pilote de CommerceNet (http://www.xmlx.com/) permet l'échange des DTD XML et le serveur pilote FPI (http://www.ucc.ie/cgi-bin/public) vous propose plusieurs DTD courantes à partir desquelles commencer.
Si vous avez créé vos fichiers HTML conformément à une des nombreuses Définitions de Type de Document (DTD) HTML et qu'ils sont valides, ces fichiers peuvent alors être convertis de la façon suivante :
< et & (c-à-d les
literal), en < et &
respectivement ;Soyez conscients que de nombreux navigateurs HTML pourraient ne pas accepter les éléments EMPTY XML avec barre oblique ; les changements ci-dessus ne sont donc pas rétro-compatibles (lors de la conversion de XML en HTML). La solution est d'ajouter une balise de fin fictive à tous les éléments EMPTY, de sorte que <IMG src="foo.gif"> devienne <IMG src="foo.gif"></IMG>.
§ Si vous avez beaucoup de fichiers HTML valides, vous pourriez écrire un script dans un système de conversion SGML (tel que Omnimark, Balise, SGMLC, ou un système utilisant une des bibliothèques SGML de Perl, Python ou Tcl) ; vous pourriez également utiliser des macros (d'un éditeur comme emacs) si vous savez ce que vous faites.
Si vos fichiers HTML ne sont pas valides (les fichiers HTML créés par la plupart des éditeurs WYSIWYG ne sont pas valides), ils devront être convertis manuellement. Même si les défauts sont réguliers et constants, les fichiers pourraient être en fait bien formés, et vous pourriez alors écrire un programme ou un script comme on l'a dit ci-dessus. Pour juger de l'invalidité ou de la non-conformité, vérifiez les points suivants :
Le balisage valide mais insignifiant ou inutile devra peut-être être modifié avant la conversion (répétitions de paragraphes vides, de sauts de ligne, de tableaux vides, d'images GIF vides servant à l'espacement, etc.) car XML utilise des feuilles de style, vous n'en aurez donc pas besoin.
Voir les règles pour des fichiers XML « bien formés » pour plus amples informations sur les points à vérifier en XML lors de la conversion.
Il y a des versions XML de la DTD HTML en préparation, mais aucune n'est encore prète :
Ben Trafford est en train de développer une version XML de HTML 3.2
J'ai personnellement démarré l'écriture d'une version XML d'HTML Pro, mais ce n'est pas facile et j'aimerais que l'on me convinque que c'est utile !
XHTML (Extensible HyperText Markup Language) est un projet du W3C. « Les spécifications définissent XHTML 1.0, une reformulation de HTML 4.0 comme une application XML 1.0, et trois DTD correspondant à celles définies par HTML 4.0. La sémantique des éléments et de leurs attributs est définie dans les W3C Recommendation for HTML 4.0. Cette sémantique sert de base à de futures extensions d'XHTML. La compatibilité avec des agents HTML existants est possible à condition de respecter un petit ensemble de recommandations. »
§ Oui, à condition que vous utilisiez un logiciel qui reconnaît les nouvelles WebSGML AQdaptations à la norme ISO 8879 (fonctions nécessaires pour supporter XML : forme particulière des éléments EMPTY ; certains aspects de la déclaration SGML tels que NAMECASE GENERAL NO ; déclarations d'attributs multiples, etc.).
¶ Une autre façon est d'utiliser une DTD SGML qui vous permette de créer un fichier SGML (mais une DTD qui n'utilise pas d'éléments vides) ; supprimer ensuite la DocType Declaration de façon qu'il devienne un fichier XML sans DTD bien formé.
§ Aujourd'hui, peu d'outils permettent de garder intacts les fichiers XML à cause du format de ces éléments EMPTY, mais ça bouge. L'analyseur nsgmls dispose d'une option de conformité XML, introduite pour être utilisée avec Jade par ailleurs, les premiers éditeurs et analyseurs spécifiques pour XML sont en usage (voir la question sur les logiciels).
§ Oui, très facilement. Mais aujourd'hui, il manque toujours des cours, des outils simples et plus d'exemples de documents XML. Des documents XML bien formés peuvent paraître similaires à HTML excepté pour de petits mais très importants points de syntaxe.
¶ La principale différence est que XML doit coller aux règles. Les navigateurs HTML en revanche vous permettent de créer du HTML dégradé car ils ignorent les informations erronées : avec XML, ou bien votre fichier est correct, ou bien ile ne marche pas !
Oui, les spécifications XML indiquent explicitement que XML utilise la norme internationale de codage des caractères sur 31 bits ISO 10646, qui couvre la plupart des langages humains (et quelques langages non-humains). Ceci est actuellement conforme à Unicode.
Les spécifications indiquent (2.2) : « Tous les processeurs XML devront accepter les codages UTF-8 et UTF-16 de la norme ISO 10646... » UTF-8 est un codage d'Unicode en caractères 8-bit : les 128 premiers caractères sont identiques au codage ASCII, les suivants sont utilisés pour coder le reste d'Unicode en séquences de 2 à 6 octets. Dans sa forme mono-octet UTF-8 est donc identique à la norme ISO 646 IRV (ASCII) ; vous pouvez donc continuer à utiliser le code ASCII pour l'anglais ou toute autre langue non accentuée en utilisant l'alphabet latin. À noter que UTF-8 est incompatible avec la norme ISO 8859-1 (ISO Latin-1) au-delà du code 126 décimal (la fin d'ASCII). UTF-16 est semblable à UTF-8 mais avec une méthode de représentation des 16 plans suivants de 64 000 caractères comme deux caractères de 16 bits.
« ... Les mécanismes qui signalent lequel des deux est utilisé et qui mettent d'autres codages en jeu, [...] sont traités lors des débats sur le codage des caractères. » Les spécifications XML expliquent comment indiquer dans un fichier XML le codage du jeu de caractères utilisé.
L'utilisation d'UCS-4 peut seulement être spécifiée en SGML ou XML quand les adaptations WebSGML à la norme ISO 8879 sont mises en place : ceci permet d'utiliser des nombres supérieurs à huit octets dans la déclaration SGML.
« Quel que soit le codage utilisé, tous les caractères du jeu de caractères de la norme ISO 10646 peuvent être définis avec l'équivalent décimal ou hexadécimal de leur chaîne d'octets. » Donc, quel que soit le jeu de caractères que vous utilisez, vous pouvez toujours définir des caractères spécifiques d'un autre endroit du répertoire de codage en utilisant &#dddd; (code de caractères décimal) ou &#xHHHH; (code de caractères hexadécimal, en majuscule). La terminologie, comme les nombres, peut porter à confusion : voir ISO 10646 Concept Dictionary. Rick Jelliffe a "XML-isé" les ensembles d'entité caractères ISO.
§ Une DTD est un fichier (ou plusieurs fichiers à utiliser ensemble), écrit en XML, qui contient une définition formelle d'un type particulier de document. Elle définit les noms qui peuvent être utilisés pour les types d'éléments, où ils peuvent apparaître et comment ils s'arrangent les uns par rapport aux autres. Par exemple, si vous voulez qu'un type de document décrive des <LIST> qui contiennent des <ITEM>, une partie de votre DTD devra contenir quelque chose comme :
<!ELEMENT list (item)+>
<!ELEMENT item (#pcdata)>
Ceci définit une liste comme un type
élément contenant un ou plusieurs items (c'est le rôle du
signe plus) et des items commes des types éléments ne contenant
que du texte. XML est le langage formel de spécification utilisé
par les processeurs pour analyser automatiquement une DTD et utiliser ensuite
cette information pour identifier la place de chaque type
d'élément et la relation qui lie ces éléments,
afin de permettre l'utilisation des feuilles de style, des navigateurs,
des moteurs de recherche, des bases de données, des sous-programmes
d'impression, ou d'autres applications. Les instructions ci-dessus vous
permettent de créer des listes qui sont conservées sous la
forme :
<List><Item>Chocolate</Item><Item>Music</Item><Item>Surfing</Item></List>
La façon dont la liste apparaît sur l'écran ou sur papier dépend de votre feuille de style : vous n'avez normalement rien à mettre en XML pour affecter la mise en page comme il fallait le faire en HTML avant les feuilles de style.
En fait une DTD donne à l'avance aux applications l'information des noms et structures qui peuvent être utilisés dans un type de document particulier. Utiliser une DTD signifie que tous les documents appartenant à un type particulier seront construits et nommés de façon conforme.
§ Il existe déjà des milliers de DTD SGML dans tous les domaines (voir les pages Web SGML pour des exemples). Nombre de ces DTD peuvent être téléchargées et utilisées librement. Vous pouvez aussi écrire vos propres DTD. Pour cela, comme pour tout langage, vous devez auparavant l'apprendre (voir ar exemple : Developing SGML DTDs par Maler et el Andaloussi, Prentice Hall, 1997, 0-13-309881-8). Cependant XML est beaucoup plus simple que SGML intégral : voir la liste de restrictions qui montre ce qui a été supprimé. Les DTD SGML existantes doivent être converties au format XML pour être utilisées dans des systèmes XML : lire la question concernant la conversion des DTD SGML au format XML. Attendez-vous à voir des annonces de DTD connues disponibles au format XML.
Bob DuCharme écrit : « Beaucoup de développeurs XML ne sont pas satisfaits de la syntaxe des déclarations de balises décrites dans les spécifications, pour deux raison. Premièrement, ils pensent que si les documents XML sont si bons pour décrire la structure des informations, alors la description d'une structure de type de document (ses « schémas ») devrait être dans un document XML et non écrite avec sa propre syntaxe. En plus d'être plus consistent, ceci permettrait plus facilement d'éditer et manipuler le schéma avec des outils habituels de manipulation de documents. Deuxièmeement, ils pensent que la notation traditionnelle des DTD ne donne pas aux définisseurs de schémas la puissance nécessaire pour imposer assez de contrainte sur les données -- par exemple, la possibilité de dire qu'un certain type élément doit toujours avoir une valeur positive, qu'il ne peut pas être vide ou qu'il peut faire partie d'une liste au choix. Ceci faciliterait le développemennt de logiciels utilisant ces données car le développeur aurait moins de code de détection d'erreurs à écrire. »
NoteLes utilisateurs ayant une formation en informatique ou en bases de données devraient prendre conscience que les systèmes SGML -- y compris XML -- ne sont pas des systèmes de gestion de bases de données : ce sont des systèmes de balisage de textes. Bien qu'il y ait beaucoup de points communs, comme ceux décrits ici, certains concepts des uns peuvent ne pas exister dans les autres : XML n'a pas les mêmes possibilités que les bases de données, tout comme DBMS n'a pas de possibilités de balisage..
« Plusieurs groupes ont soumis au W3C des propositions alternatives pour exprimer les schémas de type de document. En plus d'offrir des contraintes de schémas comme le typage des données et les autres décrites ici, beaucoup s'appuient sur les tendances actuelles en logiciel telles que les méthodologies orientées-objets. Le groupe de travail sur les schémas du W3C est en train d'analyser ces propositions et de déveloper sa propre proposition basée sur les meilleurs possibilités suggérées dans les propositions existantes ou par les membres du Schema Working Group. »
§ Les possibilités de liens hypertextes des systèmes XML sont beaucoup plus développées que celles du HTML, ce qui vous permettra de faire plus de choses avec eux. Les liens existants de type HREF continueront à être utilisables, mais la nouvelle technologie de liaison est basée sur les enseignements tirés du développement d'autres standards utilisant des hypertextes tels que TEI et HyTime. Cette technologie autorise des liens bi-directionnels et multi-branches, ainsi que des liens vers une sélection de texte (dans vos documents ou autres) et non vers un point unique. SGML connaît déjà ces applications dans des navigateurs tels que DynaText, Panorama et Multidoc Pro et ce depuis de nombreuses années en les utilisant, on gagne expérience et compétence considérables.
Les documents XML Linking Specification (XLink) et XML Extended Pointer Specification (XPointer) contiennent des spécifications provisoires détaillées. Un lien XML peut être soit une URL, soit un pointeur étendu de style TEI : TEI-style Extended Pointer (XPointer), soit les deux. Une URL seule est supposée être une ressource (comme avec HTML) ; si un pointeur étendu suit cette URL, on suppose qu'il est une sous-ressource de cette URL ; un pointeur étendu seul est supposé s'appliquer au document courant
Un XPointer est toujours précédé par un des symboles #, ?, ou |. Les symboles # et ? ont les mêmes fonctions que dans les applications HTML ; le symbole | signifie que la sous-ressource peut-être trouvée en appliquant le XPointer à la ressource, mais la méthode à utiliser dépend de l'application.
La TEI Extended Pointer Notation (EPN) est beaucoup plus puissante que « l'adresse fragmentée » à la fin de certaines URL. Elle permet en effet de spécifier l'emplacement d'une fin de lien en utilisant la structure du document et/ou les points fixes, connus comme les ID. Par exemple, l'expression la seconde occurrence liée du mot « XPointer » deux paragraphes plus haut pourrait avoir pour référence http://www.ucc.ie/xml/faq.sgml#ID(faq-hypertext)CHILD(2,*)(6,*), ce qui signifie le sixième sous-objet dans le deuxième sous-objet après l'élément dont l'ID est faq-hypertext. Compter les objets depuis le début de cette question dans la version SGML (qui a l'ID "faq-hypertext") :
<SECT2 ID="faq-hypertext"> <TITLE>How will XML affect my document links?</TITLE>
<PARA>The
<ULINK URL="http://www.w3.org/TR/WD-xlink">XML Linking Specification (XLink)</ULINK>
and
<ULINK URL="http://www.w3.org/TR/WD-xptr">XML Extended Pointer Specification (XPointer)</ULINK>
documents contain a detailed specification. An XML link can be either a URL or a TEI-style Extended Pointer (
<LINK LINKEND="tei-link">XPointer</LINK>
Oui, si le type de document que vous utilisez est prévu pour les mathématiques. La communauté des utilisateurs de mathématiques développe actuellement un logiciel et il existe une proposition MathML au W3C, qui est une application XML native. Il serait également possible de créer des fragments XML à partir de l'application obsolète HTML3, HTML Pro, ISO 12083 Math, ou OpenMath, ou d'une application de votre propre conception. Il existe déjà des navigateurs qui affichent des maths intégrées à SGML (ex. : DynaText, Panorama, Multidoc Pro).
La complexité de ces expressions mathématiques peut varier d'expressions telles que voire pour afficher en pleine-page des équations telles que :
)
-->
Si vous utilisez un navigateur HTML pour lire ceci, les équations ci-dessus n'apparaissent peut-être pas correctement. Le plugin Techexplorer d'IBM peut être utilisé avec les navigateurs HTML courants pour afficher les maths de TeX. Le navigateur Amaya sur le W3C dispose d'un affichage MathML expérimental.
§ Parce que XML permet de définir votre propre langage de balisage, vous pouvez utiliser pleinement les caractéristiques d'hypertexte étendu (voir la question sur les liens) de XML pour stocker ou lier des méta-données dans n'importe quel format (p. ex.ISO 11179, Dublin Core, Warwick Framework, Resource Description Framework (RDF) et Platform for Internet Content Selection (PICS)).
Étant une architecture et non une application, XML ne comporte aucun élément prédéfini. Ce n'est donc pas le rôle de XML de spécifier si et comment les auteurs devraient ou ne devraient pas implémenter des méta-données. Vous êtes donc libre d'utiliser la méthode qui vous convient, des simples attributs à l'inclusion de tous les registres de méta-données de Dublin Core/Warwick Framework. Les éditeurs de navigateurs pourraient également proposer leurs propres recommandations en matière d'architecture ou leurs méthodes.
Ceci dépend des caractéristiques propres au navigateur. XML a pour fonction de décrire l'information ; les langages de script et les langages pour fonctionnalités intégrées sont les logiciels qui permettent à l'information d'être traitée par l'utilisateur final.
XML lui-même permet de définir le balisage nécessaire à l'implémentation de langages de script : en tant que standard neutre il n'encourage ni ne décourage leur utilisation et ne favorise pas un langage plutôt qu'un autre ; la porte est donc ouverte. Des développements sont en cours : voir les suggestions de John Tigue pour la normalisation de l'API pour Java à propos d'XML.
Les langages de script sont donnés dans le cadre d'une proposition pour un Extensible Style Language (XSL) (voir la question sur les feuilles de style).
Oui, n'importe quel langage de programmation peut être utilisé pour sortir des données de n'importe quel source au format XML. Il y a un nombre croissant de produits amont ou aval pour environnements de programmation et de gestion de données qui permettent d'automatiser ceci.
§ L'utilisation d'une feuille de style est obligatoire en XML. Certains navigateurs offrent peut-être de simples styles par défaut pour des éléments courants comme <PARA> ou <LIST> contenant des <ITEM> ; mais en général une feuille de style permet à l'auteur de mieux contrôler la mise en page. Or, comme dans tout système où les fichiers peuvent être visualisés au hasard par des utilisateurs arbitraires, l'auteur ne peut pas connaître les ressources (polices par exemple) disponibles sur le système de l'utilisateur ; des précautions sont donc de rigueur.
Le XML Styler expérimental d'Arbortext donne des détails sur la façon de l'utiliser avec XML. Il faut aussi les commandes ActiveX et XSL codebase.
Plusieurs systèmes et implémentations de feuilles de style propriétaires pré-existantes sont aussi disponibles. La plupart sont largement intégrés à la communauté de documentation technique (et par conséquent supportés par un ou plusieurs produits) :
§ La plupart des fournisseurs de navigateurs et de serveurs semblent migrer vers XML mais, vu la grande base de systèmes déjà installés, cela ne se fera sans doute pas très vite.
§ Les graphiques sont simplement des liens vers une image plutôt que vers un texte, ils peuvent donc être créés de n'importe quelle manière supportée par les spécifications XLink et XPointer (voir une question précédente), même en utilisant une syntaxe similaire aux images HTML existantes. On peut aussi en faire en utilisant le mécanisme intégré d'XML NOTATION et ENTITY de la meme façon qu'en SGML standard. Cependant, les spécifications de liaison offrent un meilleur contrôle sur les liens de traversée et leur activation. Un auteur peut donc, par exemple, choisir de faire apparaître une image lors du chargement de la page, sur simple clic de l'utilisateur, ou dans une autre fenêtre, sans avoir à modifier le script. Il revient aux concepteurs de navigateurs de choisir les formats de fichiers graphiques qui seront supportés : XML ne comporte aucune restriction. L'utilisation des formats GIF, JPG, TIFF et CGM au minimum seraient logiques : il y a certaines tendances à la création d'une norme de graphiques vectoriels pour réseau (voir paragraphe suivant).
Peter Murray-Rust précise : « Les formats GIF et JPEG traitent des bitmaps (représentation en pixels des images). Les graphiques vectoriels (échelonnables) sont discutés par l'activité graphique du W3C (voir http://www.w3.org/Graphics/Activity). Quand un consensus aboutira, il sera alors possible de transmettre une représentation graphique au sein même du fichier XML. Ceci signifie, pour la plupart des objets graphiques, un temps de téléchargement considérablement réduit et une mise à l'échelle sans perte de définition.. »
NoteOn ne peut pas emboîter un fichier graphique (pas plus qu'un autre fichier binaire [non textuel]) directement dans un fichier XML car n'importe quel octet ressemblant à une marque serait mal interprété. Il faut s'y référer par des liens (voir ci-dessous).
Bob DuCharme ajoute : « Toutes les données dans une entité de document XML doivent être du XML parsable. Vous pouvez définir une entité externe soit en tant qu'entité parsée (XML parsable) soit en tant qu'entité non parsée (n'importe quoi d'autre). Les entités non parsées peuvent être utilisées pour les fichiers images, les fichiers sons, les fichiers vidéo ou tout ce que vous voulez. Elles ne peuvent être appelées qu'à partir d'un document en tant que valeur d'un attribut (de la même façon qu'une image Bitmap d'une page web en HTML est l'attribut src de l'élément <img>) et n'ont pas en tant que partie du document courant. Dans un document XML, cet attribut doit être déclaré de type ENTITY et la déclaration d'entité doit spécifier une NOTATION déclarée. En effet, si l'entité n'est pas du XML, le processeur XML doit savoir ce dont il s'agit. Par exemple, dans le document suivant, l'entité colliepic est déclarée comme ayant une notation JPEG et est utilisée en tant que valeur de l'attribut picfile de l'élément vide dog.
<?xml version="1.0"?>
<!DOCTYPE dog [
<!NOTATION JPEG SYSTEM "Joint Photographic Experts Group">
<!ENTITY colliepic SYSTEM "lassie.jpg" NDATA JPEG>
<!ELEMENT dog EMPTY>
<!ATTLIST dog picfile ENTITY #REQUIRED>
]>
<dog picfile="colliepic"/>
Les spécifications de liaison XLink et XPointer décrivent d'autres manières de pointer vers un fichier non-XML tel qu'un graphique. Ces spécifications permettent de mieux contrôler la position, le traitement et l'apparence d'une entité externe dans un document XML. »
On pourrait toutefois inclure un fichier binaire transformé et
codé en texte comme une section CDATA, en utilisant quelque
chose comme UUencode avec des marques ] et
> supprimées du jeu de façon qu'elles ne puissent
ni être utilisées, ni mal interprétèes.
Ici : (http://www.w3.org/TR/REC-xml). Inclut l'EBNF. Il existe également des versions en japonais (http://www.fxis.co.jp/DMS/sgml/xml/) ; en espagnol (http://www.ucc.ie/xml/faq-es.html) ; en coréen (http://xml.t2000.co.kr/faq/index.html) et une version annotée Java-isée à l'adresse http://www.xml.com/axml/testaxml.htm.
Eve Maler a lancé la DTD et la documentation propres à la spec : il s'agit d'une nouvelle version utilisée pour coder les spécifications XML, XLink, XPointer, DOM, etc. Attention, cette version n'est plus compatible avec la version qu'utilise XML 1.0. Merci d'envoyer vos commentaires et questions à Eve.
§ Le SGML intégral utilise une définition de type de document (DTD) pour décrire le balisage (éléments) disponible dans tout type de document spécifique. Cependant la conception d'une DTD peut s'avérer complexe et peu évidente. XML a donc été conçu pour être utilisé avec ou sans DTD. Opérer sans DTD permet d'inventer un balisage sans avoir à le définir de façon formelle, avec le risque de perdre le contrôle automatique de la structuration de documents additionnels de même type.
En fait un fichier sans DTD « définit » son propre balisage, de manière informelle, par l'existence et la localisation d'éléments là où ils sont créés. Mais lorsqu'une application XML, telle qu'un navigateur, rencontre un fichier sans DTD, elle doit être capable d'en comprendre la structure à la lecture car aucune DTD ne l'informe de ce qu'elle doit faire, aussi quelques modifications ont dues être apportées.
§ Par exemple, l'élément HTML <IMG> est défini comme « EMPTY » : il n'a pas de balise de fin. Une application XML lisant un fichier sans DTD et rencontrant <IMG> n'aurait aucun moyen de savoir si elle doit ou non attendre une balise de fin, aussi le concept « bien formé » a-t-il été introduit. Ceci rend complètement univoque le début et la fin de chaque élément et l'occurrence d'éléments EMPTY .
Tous les documents XML, sans DTD ou valides, doivent être bien formés :
<?xml version="1.0" standalone="yes"?>
<foo>
<bar>...<blort/>...</bar>
</foo>David Brownell signale : « du XML "seulement" bien formé n'a pas du tout besoin d'utiliser de Standalone Document Declaration. De telle déclarations sont là pour permettre certaines accélérations quand on traite des documents en ignorant les entités paramètres externes -- en gros, on ne peut pas compter sur les déclarations externes dans des documents indépendants. Les types concernés sont les entités et les attributs. Les documents indépendants ne doivent pas demander de valeurs d'attribut par défaut ou normales, sinon ils sont invalides. »
Exemple : <BR> devient soit <BR/> soit <BR></BR>.
]]> doit être donnée
sous la forme ]][amp ]gt; si elle
n'est pas à la fin d'une section CDATA ;§ Les fichiers XML sans DTD sont supposés avoir les éléments <, >, ', " et & prédéfinis, qui sont donc utilisables même sans DTD. Les fichiers XML valides doivent les déclarer explicitement s'ils les utilisent. Si on veut utiliser plus que ces cinq entités caractères par défaut, mais si on veut éviter d'avoir à écrire une DTD complète, il est possible de ne déclarer que les entités caractères dans le sous-ensemble interne d'un autre fichier XML indépendant (merci à Richard Lander pour cette information).
<?xml version="1.0" standalone="yes"?> <!doctype example [ <!entity nbsp " "> ]> <example>Three blanks.</example>
§ Les fichiers XML valides sont ceux qui possèdent une Définition de Type de Document (DTD), comme toutes les applications SGML et qui y adhèrent. Ils doivent également être bien-formés.
Un fichier valide, comme tout autre fichier SGML, commence par une Déclaration de Type de Document, qui peut être précédée d'une déclaration XML facultative :
<?xml version="1.0"?> <!DOCTYPE advert SYSTEM "http://www.foo.org/ad.dtd"> <advert> <headline>...<pic/>...</headline> <text>...</text> </advert>
La Spécification XML définit une déclaration SGML pour XML qui est définie pour toutes les instances (la déclaration ne figure plus dans le texte de la spécification et se trouve maintenant dans un document à part). Une version XML de la DTD spécifiée doit être accessible par le processeur XML, soit localement (c'est-à-dire que l'utilisateur a déjà une copie sur son disque), ou via le réseau. Vous pouvez le indiquer une DTD par une URL dans l'identificateur de système (comme dans l'exemple précédent). Il est possible (certains diraient préférable) de fournir un identificateur public formel, mais s'il est utilisé, il doit précéder l'identificateur de système, qui doit toujours être donné (et seul le mot clé PUBLIC est utilisé).
<!DOCTYPE advert PUBLIC "-//Foo, Inc//DTD Advertisements//EN" "http://www.foo.org/ad.dtd">
Les valeurs par défaut pour les autres attributs de la déclaration XML sont version="1.0" et encoding="UTF-8".
Il n'y a pas de réponse unique à cette question : cela dépend beaucloup de la finalité de votre type de document. Les deux extrêmes s'expliquent mieux par des exemples :
la pratique « traditionnelle » est de mettre le texte « réel » (celui que l'on veut imprimer) comme des données de type caractère et de garder les méta-données (comme les numéros de ligne) en attributs, où elles peuvent être plus facilement isolées pour analyse ou pour des traitements spéciaux comme la mise en marge ou dans une mousevoer :
<l n="184"><sp>Portia</sp><text>The quality of mercy is not strain’d,</text></l>
sauf du point de vue système, il n'y a rien de « faux » à garder les données d'une autre façon, notamment lorsque le volume des données textuelles est plutôt petit à chaque occasion :
<line speaker="Portia" text="The quality of mercy is not strain’d,">184</line>
Cela dépend donc pour beaucoup de ce que vous voulez faire des informations et de quelles parties sont le plus facilemement accessibles par chaque méthode. Une règle de bon sens pour les documents textuels usuels est que si l'on supprime toutes les balises, le texte dépouillé doit rester lisible et utilisable, même si c'est difficile. Mais, cependant, pour les sorties de bases de données ou autres documents secondaires, « lire » n'a plus de sens et il est alors tout à fait immaginable d'avoir des documents où toutes les données sont en attributs et où les documents ne contiennent pas du tout de caractère dans le modèle de contenu. Voir http://www.oasis-open.org/cover/elementsAndAttrs.html pour plus de détails.
Les principales modifications portent sur ce que vous pouvez écrire dans une Définition de Type de Document (DTD). Pour simplifier la syntaxe et simplifier l'écriture de logiciels de traitement, de nombreuses options de déclaration de balisage SGML ont été supprimées (voir la référence à la liste des caractéristiques omises).
Un délimiteur supplémentaire (les deux-points) est autorisé dans les noms et est utilisé dans les expériences avec les espaces de nom (ils permettent aux DTD de distinguer la source de l'élément, le propriétaire ou l'application). Les deux-points peuvent n'apparaître qu'au milieu d'un nom et pas au début ou à la fin. Des travaux en cours visent à définir comment ils peuvent être déclarés et référencés en utilisant le balisage des éléments et des attributs.
Les précisions concernant cette question évoluent trop rapidement ; elles n'apparaissent donc pas dans cette FAQ : voir les pages XML à l'adresse suivante http://www.oasis-open.org/cover/xml.html.
¶ Pour un guide détaillé d'exemples de programmes SGML et XML et les concepts sous-jacents, voir le livre de l'auteur de cette FAQ : Understanding SGML and XML Tools (Kluwer, 1998, 0-7923-8169-6).
Concernant les navigateurs, voir la question sur les navigateurs XML et les précisions de la liste de diffusion ml-dev pour les développeurs de logiciels. Bert Bos maintient une liste de quelques développements XML en bison, flex, perl et Python.
Des informations pour les développeurs de XML chinois peuvent être trouvées dans la page web chinoise WML Now! de l'Academia Sinica : http://www.ascc.net/xml/ Ce site propose une FAQ et des fichiers de tests.
§ Seulement pour servir les fichiers .xml au type MIME correct (application/xml, voir RFC2376), donc pour servir les documents XML il suffit de modifier le fichier mime-types (ou son équivalent) et d'ajouter la ligne :
application/xml xml XML
Dans certains serveurs (ex. : Apache), les utilisateurs peuvent modifier le type MIME pour les types de fichiers spécifiques à partir de leurs propres répertoires en utilisant un fichier .htaccess. Le type de contenu MIME text/xml peut seulement être appliqué aux fichiers en ASCII pur (ISO 646 IRV) à cause d'une restriction du jeu de caractères dans le RFC ; en usage normal, aller à application/xml.
§ XML étant conçu pour supporter les feuilles de style et l'hyperliaison sophistiquée, les fichiers XML seront accompagnés de fichiers auxiliaires, tout comme les fichiers SGML : DTD, fichiers d'entité, catalogues, feuilles de style, etc. qui nécessiteront d'autres entrées type de contenu MIME, comme text/css pour les feuilles de style CSS. Le XUA (XML User Agent), qui est l'un des développements envisagés du XML WG, pourrait fournir un système pour englober les documents XML et les styles XSL en un seul message.
Si vous exécutez des scripts générant du HTML que vous voulez faire fonctionner en XML, vous devrez les modifier pour produire le type de document pertinent.
Oui, dans la mesure où le produit généré s'insère dans un fichier conforme au XML (c'est-à-dire valide ou simplement bien formé).
C'est la même règle qu'avec les INCLUDE serveur qui s'applique ici. Vous devez donc vous assurer qu'aucun code intégré qui passe dans un moteur tiers (ex. : requêtes SDQL, codes Java, requêtes LiveWire, contenu « streamed », etc.) ne contient de caractère qui pourrait être interprété comme du balisage XML (c'est-à-dire ni guillemets-chevrons ni esperluète) : utilisez une section CDATA afin d'éviter que votre application XML ne parse le code intégré, ou utilisez à la place les références d'entité de caractère standard <, > et &.
§ Une terminologie précise est nécessaire à une bonne implémentation de XML. L'objectif numéro 8 (design goal 8) des spécifications nous dit que « la définition de XML doit être formelle et concise ». Pour décrire XML en termes formels, sa spécification utilise le langage concis de l'informatique, ce qui déroute les non informaticiens : en effet, il utilise des mots anglais bien connus mais avec un sens bien précis, parfois éloigné de leur sens habituel -- par exemple : grammar (grammaire), production, token (marque) ou terminal (terminal).
La spécification explique rarement ces termes à cause de l'autre aspect de cette définition : la spécification doit être concise. Elle ne répète pas les explciations que l'on peut trouver ailleurs. Ça veut dire que pour dominer les subtitlités des spécifications, il vous faut être compétent en informatique et en sgml !
Une terminologie inappropriée dans les spécifications est source d'interprétations erronnées. Les normes formelles doivent donc être rédigées avec une terminologie formelle. Cette FAQ n'est pas un document formel et le lecteur avisé aura sans doute remarqué qu'on y fait référence à des « noms d'éléments » et non pas à des « noms de types d'éléments », formule qui est certes plus correcte mais mal comprise et moins répandue.
Les novices du SGML pourront peut-être lire le chapitre de TEI intitulé Gentle Introduction to SGML.
Merci à Bod DuCharme pour quelques suggestions et quelques extraits de son livre sur la spécif XML.
Plusieurs kits sont disponibles ou en cours de développement. Des précisions, ainsi que des informations sur les autres logiciels XML, sont disponibles sur les pages Web SGML/XML .
Les gros moteurs de développement d'application et de conversion SGML tels que Balise, Omnimark et SGMLC développent tous des versions XML. Des précisions sur les logiciels SGML de tous types sont disponibles sur les pages Web SGML/XML.
Le Document Object Model (DOM) (http://www.w3.org/TR/PR-DOM-Level-1) fournit des API abstraites pour la construction, l'accès et la manipulation de documents XML et HTML. Une « réalisation » du DOM dans un langage de programmation donné offre une API concrète.
James Clark propose plusieurs tests pour parsers XML à l'adresse http://www.jclark.com/xml/. Il propose également un test de conformité.
Exactement de la même façon que pour SGML normal. Vous déclarez d'abord l'entité que vous voulez inclure, puis vous la référencez par son nom :
<!ENTITY % mylists PUBLIC "-//Foo, Inc//ENTITIES Common list structures//EN" "dtds/listfrag.ent"> ... %mylists;
Normalement de telles déclarations figurent toutes au début du fichier DTD principal, où elles peuvent être gérées ; mais ce n'est pas essentiel. Il faut utiliser une syntaxe d'entité paramètre (signe pourcent) parce que le fichier sera intégré au moment de la compilation de la DTD et non pas lorsque l'instance du document sera parsée.
Avec XML, il est obligatoire de spécifier une URL pour toutes les références à un fichier externe : les règles classiques pour supprimer la référence à une URL s'appliquent (méthodes, serveurs et répertoires identiques à ceux du document les contenant). L'URL peut être indiquée comme un identificateur système seul :
<!ENTITY mydtd SYSTEM "http://www.foo.bar/~blort/my.dtd">
ou comme le deuxième paramètre d'un identificateur public formel comme dans l'exemple précédent.
De nombreux projets sont en cours pour convertir les DTD SGML courantes ou connues au format XML (Patrice Bonhomme par exemple travaille sur une version XML non officielle de la DTD TEI Lite : les détails sont discutés sur la liste de diffusion TEI-L).
La checklist suivante vous est donnée grâce à l'aimable autorisation de Seán McGrath (auteur de XML By Example, Prentice Hall, 1998) [l'italique est mis par l'auteur de la FAQ] :
Dernier point, et non le moindre, CONCUR ! Il existe d'énormes différences entre la portion de sous-ensemble interne et externe d'une DTD en XML : a) les sections ne peuvent apparaître que dans un sous-ensemble externe ; b) les entités paramètres doivent être utilisées pour remplacer des déclarations entières dans la portion d'un sous-ensemble interne d'une DTD ; ex. ce qui suit n'est pas valide en XML :
<!DOCTYPE x [
<!ENTITY % modelx "(A|B)*">
<!ELEMENT x %modelx;>
]>
<x></x>L'échange électronique de documents est utilisé depuis de nombreuses années pour échanger des documents entre partenaires commerciaux dans le cadre d'une transaction. Ceci a nécessité des logiciels propriétaires spécifiques, mais des efforts sont réalisés aujourd'hui pour permettre aux données EDI de circuler dans XML. Des précisions sur les développements en cours sont disponibles à l'adresse http://www.xmledi.com/, ainsi que des directives à l'adresse http://www.geocities.com/WallStreet/Floor/5815/guide.htm.
Illustration extraite de l'article de Dale
Dougherty dans la Web Review (avec l'aimable autorisation des
éditeurs).
![[XMLfiles image]](head-xmlfiles.gif)
Cette FAQ est traduite de The XML FAQ . La traduction a été commanditée par l'Association GUTenberg au CFTTR (Centre de Formation de Traducteurs-Terminologues & Rédacteurs de l'Université de Haute Bretagne - Rennes 2). Elle a été traduite de l'anglais par Morgane Le Bihan qui s'est basée sur la terminologie utilisée pour la version française du langage XML. Elle a été révisée par Jacques André (Irisa/Inria-Rennes), Bernard Gaulle et Michel Goossens (CERN, Genève).
Une version imprimée est parue dans le Cahiers GUTenberg , 33-34, spécial XML, novembre 1999, p. 281-311.