FAQ XML : Développeurs et implementeurs (y compris les webmasters et les responsables serveurs)

D.1 Où se trouve la spécif ?

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.

D.2 Que signifient les termes « sans DTD », « valide » et « bien formé » ?

§ 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.

D.2.1 Les documents « bien formés »

Tous les documents XML, sans DTD ou valides, doivent être bien formés :

Si aucune DTD n’est utilisée, le document doit démarrer avec une Déclaration de document autonome (Standalone Document Declaration, SDD) :

        <?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. » Toutes les balises doivent être équilibrées : tous les éléments qui pourraient contenir des données textuelles doivent avoir une balise de début et une balise de fin (l’omission est interdite sauf pour les éléments vides — voir ci-dessous) ; Toutes les valeurs d’attribut doivent être entre apostrophes (le caractère guillemet simple [apostrophe ’] peut être utilisé si la valeur contient un caractère double " et vice versa) : si vous avez besoin des deux signes, utilisez ' et " Toute balise d’éléments EMPTY (ex. : ceux qui n’ont pas de balise de fin comme les <IMG>, <HR> et <BR> et autres) d’HTML doit soit se terminer par « / » ; sinon il faut ajouter une véritable balise de fin aux éléments qui deviennent alors non-EMPTY.

Exemple : <BR> devient soit <BR/> soit <BR></BR>. Il ne doit pas y avoir de caractère de balisage isolé (< ou &) dans vos données textuelles (c’est-à-dire qu’ils doivent apparaître comme < et &) et la séquence ]]> doit être donnée sous la forme ]][amp ]gt; si elle n’est pas à la fin d’une section CDATA ; Les éléments doivent s’imbriquer correctement les uns dans les autres (pas de chevauchement de balisage, de même qu’avec SGML) ; Les fichiers bien-formés sans DTD peuvent utiliser des attributs pour tout élément, mais tous les attributs doivent être de type CDATA par défaut.

§ 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 "&#032;">
    ]>
    <example>Three&nbsp;&nbsp;&nbsp;blanks.</example>

D.2.2 XML valide

§ 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".

D.3 Que dois-je utiliser dans ma DTD : des attributs ou des éléments ?

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 mouse-over :

        <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 d’incorrect à 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.

D.4 Quoi d’autre a changé de SGML à XML ?

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.

D.5 Quels logiciels XML puis-je utiliser aujourd’hui ?

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.

D.6 Dois-je changer mes serveurs pour travailler avec XML ?

§ 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.

D.7 Puis-je encore utiliser les INCLUDE côté serveur ?

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é).

D.8 Puis-je (ainsi que mes auteurs) encore utiliser les INCLUDE côté clients ?

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 &.

D.9 J’essaie de comprendre la spécif XML : pourquoi la terminologie de SGML (et de XML) est-elle si compliquée ?

§ 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.

D.10 Existe-t-il un kit API de développeurs pour 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.

D.11 Comment XML réagit-il avec les DOM ?

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.

D.12 Existe-t-il des tests de conformité pour les processeurs XML ?

James Clark propose plusieurs tests pour parsers XML à l’adresse http://www.jclark.com/xml/. Il propose également un test de conformité.

D.13 Comment inclure une DTD (ou un morceau) dans une autre ?

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.

D.14 Je possède déjà des DTD en SGML : comment les convertir pour les utiliser avec XML ?

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] :

Aucun équivalent de la déclaration SGML. Les mots clés, jeux de caractères, etc. sont donc essentiellement fixes ; La minimisation des balises est interdite, donc <!ELEMENT x - O (A,B)> devient <!ELEMENT X (A,B)> et <!ELEMENT x - O EMPTY> devient <!ELEMENT X EMPTY> ; #PCDATA ne doit apparaître qu’à l’extrême gauche d’un modèle OR ; par exemple, <!ELEMENT x (A|B|#PCDATA|C)> devient <!ELEMENT x (#PCDATA|A|B|C)> et <!ELEMENT x (A,#PCDATA)> est illégal ; Aucun élément CDATA, RCDATA [declared content] ; Certains types d’attributs SGML ne sont pas autorisés en XML ; ex. NUTOKEN. Il n’y a pas non plus d’attributs NOTATION (attributs de données) ; Certains défauts d’attributs SGML ne sont pas autorisés en XML ; ex. CONREF ; Les commentaires et les déclarations ne peuvent pas figurer sur la même ligne ; ex. [légal en SGML] <!ELEMENT x (A,B) -- this is an SGML comment in a declaration --> ; Tout un ensemble de fonctions facultatives de SGML a disparu avec XML : a) toutes les formes de minimisation de balises (OMITTAG, DATATAG, SHORTREF, etc) ; b) les Link Process Definitions ; c) les DTD multiples dans un même document, et bien d’autres : voir la question sur les points de SGML n’apparaissant pas dans XML pour en obtenir la liste complète ;

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>

D.15 Qu’en est-il de XML et de l’EDI ?

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.