REC-xml-19980210

Langage de balisage extensible (XML) 1.0

Recommandation du W3C, 10 février 1998

Cette version :

http://www.w3.org/TR/1998/REC-xml-19980210

http://www.w3.org/TR/1998/REC-xml-19980210.xml

http://www.w3.org/TR/1998/REC-xml-19980210.html

http://www.w3.org/TR/1998/REC-xml-19980210.pdf

http://www.w3.org/TR/1998/REC-xml-19980210.ps

Version la plus récente :

http://www.w3.org/TR/REC-xml

Version précédente :

http://www.w3.org/TR/PR-xml-971208

Rédacteurs :

Tim Bray (Textuality and Netscape) <tbray@textuality.com>

Jean Paoli (Microsoft) <jeanpa@microsoft.com>

C. M. Sperberg-McQueen (University of Illinois at Chicago) <cmsmcq@uic.edu>

Sommaire

Le langage de balisage extensible (Extensible Markup Language, XML) est un sous-ensemble de SGML qui est complètement décrit dans ce document. Son but est de permettre au SGML générique d'être transmis, reçu et traité sur le Web de la même manière que l'est HTML aujourd'hui. XML a été conçu pour être facile à mettre en œuvre et interopérable avec SGML et HTML.

Statut de ce document

Ce document a été examiné par des membres du W3C et d'autres parties intéressées et a été approuvé par le Directeur comme Recommandation du W3C. Ce document est stable et peut servir de référence ou être cité comme standard dans un autre document. En promulgant cette recommandation, le W3C cherche à attirer l'attention sur la spécification et à promouvoir sa mise en œuvre. Cette action améliore la fonctionalité et l'interopérabilité du Web.

Ce document précise une syntaxe créée en extrayant un sous-ensemble d'une norme internationale de traitement de texte existante et largement utilisée (le langage normalisé de balisage généralisé, ISO 8879:1986(F) tel qu'amendé et corrigé), dans le but de l'utiliser sur le Web. C'est un produit de l'activité XML du W3C, sur laquelle on trouvera de l'information à l'adresse http://www.w3.org/XML. Une liste des recommandations en vigueur du W3C et d'autres documents techniques se trouve à l'adresse http://www.w3.org/TR.

Ce document utilise le terme URI, défini dans [Berners-Lee et al.], un travail en cours destiné à mettre à jour les documents [IETF RFC1738] et [IETF RFC1808].

La liste des erreurs connues de cette spécification est disponible à l'adresse http://www.w3.org/XML/xml-19980210-errata.

On est prié de signaler toute erreur dans ce document à xml-editor@w3.org.

Langage de balisage extensible (XML) 1.0

Table des matières

Annexes

1. Introduction

Le Langage de balisage extensible [en anglais Extensible Markup Language] (abrégé XML) décrit une classe d'objets de données appelés documents XML et décrit partiellement le comportement des programmes qui les traitent. XML est un profil d'application ou une forme restreinte de SGML, le langage normalisé de balisage généralisé [ISO 8879]. Par construction, les documents XML sont des documents conformes à SGML.

Les documents XML se composent d'unités de stockage appelées entités, qui contiennent des données analysables ou non. Les données analysables se composent de caractères, certains formant les données textuelles, et le reste formant le balisage. Le balisage décrit les structures logique et de stockage du document. XML fournit un mécanisme pour imposer des contraintes à ces structures.

Un module logiciel appelé processeur XML est utilisé pour lire les documents XML et pour accéder à leur contenu et à leur structure. On suppose qu'un processeur XML effectue son travail pour le compte d'un autre module, appelé l'application. Cette spécification décrit le comportement requis d'un processeur XML, c'est à dire la manière dont il doit lire des données XML et les informations qu'il doit fournir à l'application.

1.1 Origine et buts

XML a été développé par un groupe de travail (GT) XML [XML Working Group] (initialement connu sous le nom de comité d'examen éditorial SGML [SGML Editorial Review Board]) constitué sous les auspices du Consortium du World Wide Web (W3C) en 1996. Le GT était présidé par Jon Bosak de Sun Microsystems avec la participation active d'un groupe d'intérêt XML [XML Special Interest Group] (auparavant connu sous le nom de groupe de travail de SGML [SGML Working Group]) également organisé par le W3C. La liste des membres du groupe de travail XML est donnée en annexe. Dan Connolly agissait comme contact du W3C auprès du GT.

Les objectifs de conception de XML sont les suivants :

1. XML devrait pouvoir être utilisé sans difficulté sur Internet ;
2. XML devrait soutenir une grande variété d'applications ;
3. XML devra être compatible avec SGML ;
4. Il devrait être facile d'écrire des programmes traitant les documents XML ;
5. Le nombre d'options dans XML doit être réduit au minimum, idéalement à aucune ;
6. Les documents XML devraient être lisibles par l'homme et raisonnablement clairs ;
7. La conception de XML devrait être préparée rapidement ;
8. La conception de XML sera formelle et concise ;
9. Il devrait être facile de créer des documents XML ;
10. La concision dans le balisage de XML est de peu d'importance.

Cette spécification, ainsi que certaines normes associées (Unicode et l'ISO/CEI 10646 pour les caractères, le RFC 1766 Internet pour les balises d'identification de langue, l'ISO 639 pour les codes de noms de langue et l'ISO 3166 pour les codes de noms de pays) fournissent toutes les informations nécessaires pour comprendre la version 1.0 de XML et pour construire des programmes pour la traiter.

Cette version de la spécification de XML peut être distribuée librement, à condition que tout le texte et les notices juridiques demeurent intacts.

1.2 Terminologie

La terminologie employée pour décrire les documents XML est définie dans cette spécification. Les termes définis dans la liste suivante sont utilisés pour établir ces définitions et pour décrire les actions d'un processeur XML :

pouvoir (verbe)

il n'y a pas obligation pour les documents conformes et les processeurs XML de se comporter tel que décrit.

devoir (verbe)

il y a obligation pour les documents conformes et les processeurs XML de se comporter tel que décrit ; tout manquement est une erreur.

erreur

une violation des règles de cette spécification. Les résultats sont indéterminés. Un logiciel conforme peut détecter et signaler une erreur et peut s'en remettre.

erreur fatale

une erreur qu'un processeur XML conforme doit détecter et signaler à l'application. À la suite d'une erreur fatale, le processeur peut continuer à traiter les données pour rechercher d'autres erreurs et peut signaler de telles erreurs à l'application. Afin d'aider la correction des erreurs, le processeur peut rendre disponibles à l'application des données non-traitées (mélange de données textuelles et de balisage). Dès qu'une erreur fatale est détectée, toutefois, le processeur ne doit pas continuer le traitement normal (c'est à dire qu'il ne doit pas continuer à transmettre à l'application d'une façon normale les données textuelles et l'information sur la structure logique du document).

au gré de l'utilisateur

un logiciel conforme peut ou doit (selon le verbe dans la phrase) se comporter tel que décrit ; s'il le fait, il doit fournir à l'utilisateur un moyen d'activer ou de désactiver le comportement décrit.

contrainte de validité

une règle qui s'applique à tous les documents XML valides. Les violations des contraintes de validité sont des erreurs ; elles doivent, au gré de l'utilisateur, être signalées par les processeurs XML validateurs.

contrainte de forme

une règle qui s'applique à tous les documents XML bien formés. Les violations des contraintes de forme sont des erreurs fatales.

correspondance

(De chaînes de caractères ou de noms :) Deux chaînes de caractères ou deux noms correspondent s'ils sont identiques. Les caractères possédant des représentations multiples dans l'ISO/CEI 10646 (c-à-d les caractères avec des formes précomposée et base+diacritiques) correspondent seulement s'ils ont la même représentation dans les deux chaînes de caractères. Au gré de l'utilisateur, les processeurs peuvent normaliser de tels caractères à une certaine forme canonique. Aucune transformation de casse n'est effectuée. (De chaînes de caractères et de règles de grammaire :) toute chaîne appartenant au langage engendré par une production grammaticale est réputée correspondre à cette production. (Du contenu et des modèles de contenu :) un élément correspond à sa déclaration quand il se conforme à la forme décrite dans la contrainte « élément valide ».

à des fins de compatibilité

un dispositif de XML uniquement inclus pour s'assurer que XML demeure compatible avec SGML.

à des fins d'interopérabilité

une recommandation non-contraignante incluse pour accroître les chances de traitement de document XML par des processeurs SGML antérieurs à l'annexe « WebSGML Adaptations » de l'ISO 8879.

2. Documents

Un objet de données est un document XML s'il est bien formé, tel que précisé dans cette spécification. De plus, un document XML bien formé peut être valide s'il obéit à certaines autres contraintes.

Chaque document XML a une structure logique et une structure physique. Physiquement, le document se compose d'unités appelées entités. Une entité peut appeler d'autres entités pour causer leur inclusion dans le document. Un document commence à la « racine » ou entité document. Logiquement, le document se compose de déclarations, d'éléments, de commentaires, d'appels de caractère et d'instructions de traitement, qui sont indiqués dans le document par du balisage explicite. Les structures logiques et physiques doivent s'imbriquer correctement, tel que décrit dans « 4.3.2 Entités analysables bien formées ».

2.1 Documents XML bien formés

Un objet textuel est un document XML bien formé si :

1. pris dans son ensemble, il correspond à la production étiquetée document ;
2. il obéit à toutes les contraintes de forme données dans cette spécification ;
3. chacune des entités analysables générales qui est appelée directement ou indirectement dans le document est bien formée.

La correspondance à la production document implique que :

1. le document contient un ou plusieurs éléments ;
2. il y a un seul élément, appelé la racine, ou l'élément document, dont aucune partie n'apparaît dans le contenu d'un autre élément. Pour tous les autres éléments, si la balise de début est dans le contenu d'un autre élément, la balise de fin est dans le contenu du même élément. Autrement dit, les éléments, délimités par des balises de départ et de fin, s'imbriquent correctement les uns dans les autres.

En conséquence, pour chaque élément F (autre que la racine) dans le document, il y a un autre élément P dans le document tel que F est dans le contenu de P, mais n'est dans le contenu d'aucun autre élément qui est dans le contenu de P. P est connu comme parent de F, et F comme fils de P.

2.2 Caractères

Une entité analysable contient du texte, une suite de caractères qui peuvent représenter du balisage ou des données textuelles. Un caractère est une unité de texte tel que précisé par l'ISO/CEI 10646 [ISO/CEI 10646]. Les caractères admissibles sont la tabulation, le retour de chariot, le retour à la ligne, et les caractères d'Unicode et de l'ISO/CEI 10646 permis par la production [2] ci-dessous. L'utilisation des « caractères de compatibilité », tel que définis dans la section 6.8 de [Unicode], est déconseillée.

Le mécanisme de codage des positions de code de caractère en configurations binaires peut varier d'une entité à l'autre. Tous les processeurs XML doivent accepter les codages UTF-8 et UTF-16 de l'ISO/CEI 10646 ; les mécanismes pour signaler lequel des deux est utilisé ou pour introduire d'autres codages sont discutés ci-dessous dans « 4.3.3 Codage des caractères dans les entités ».

2.3 Constructions syntaxiques communes

Ce paragraphe définit quelques symboles souvent utilisés dans la grammaire.

S (séparateurs, blanc) se compose d'un ou plusieurs des caractères espace (#x20), retour de chariot, retour à la ligne, ou tabulation.

Par commodité, les caractères sont classifiés en lettres, chiffres ou autres caractères. Une lettre est un caractère de base alphabétique ou syllabique ou encore un caractère idéographique. Des définitions complètes des classes de caractères sont données dans « B. Classes de caractères ».

Un nom est une unité lexicale commençant par une lettre ou par un des caractères de ponctuation d'une courte liste, suivi de lettres, de chiffres, de traits d'union, de traits de soulignement, de deux points ou de points finals, tous connus comme caractères constitutifs de nom. Les noms commençant par la chaîne de caractères « xml », ou par n'importe quelle chaîne de caractères correspondant à (('X'|'x') ('M'|'m') ('L'|'l')), sont réservés à des fins de normalisation dans cette version ou dans des versions ultérieures de la spécification.

Note : Le caractère deux points dans les noms XML est réservé pour l'expérimentation avec les espaces de nom. On s'attend à ce que sa signification soit normalisée bientôt ; les documents utilisant les deux points dans un but expérimental pourront alors nécessiter une mise à jour. (Il n'y a aucune garantie que le mécanisme d'espace de nom éventuellement adopté pour XML utilise en fait les deux points comme séparateur.) Dans la pratique, ceci signifie que les auteurs ne devraient pas utiliser les deux points dans les noms XML, sauf en tant qu'élément expérimental d'espace de nom, mais que les processeurs XML devraient accepter les deux points comme caractère constitutif de nom.

Un AtomeNml (atome nominal) est une suite de caractères constitutifs de nom.

Une chaîne délimitée, ne contenant pas les guillemets (anglais, " ou ') utilisés comme délimiteur, constitue ce que l'on appelle « un littéral ». Des littéraux sont utilisés pour préciser le contenu des entités internes (ValeurEntité), des valeurs des attributs (ValeurAtt) et des identificateurs externes (LittéralSystème). Notez qu'un LittéralSystème peut être analysé sans rechercher le balisage.

2.4 Données textuelles et balisage

Le texte se compose de données textuelles et de balisage. Le balisage prend la forme de balises ouvrantes, de balises fermantes, de balises d'éléments vides, d'appels d'entité, d'appels de caractère, de commentaires, de délimiteurs de section CDATA, de déclarations de type de document, et d'instructions de traitement.

Tout le texte qui n'est pas du balisage constitue les données textuelles du document. Il est à noter que du texte correspondant au non-terminal S (production [3]) est du balisage et non pas des données textuelles.

Les caractères esperluète (&) et crochet gauche (<) peuvent apparaître sous leur forme littérale seulement quand ils sont utilisés comme délimiteurs de balisage ou dans un commentaire, une instruction de traitement, ou une section CDATA. S'ils sont nécessaires ailleurs, ils doivent être déguisés en utilisant des appels de caractères numériques ou en utilisant les chaînes de caractères « & » et « < » respectivement. Le crochet droit (>) peut être représenté en utilisant la chaîne de caractères « > » et doit, pour compatibilité, être déguisé en utilisant « > » ou un appel de caractère quand il apparaît dans la chaîne de caractères « ]]> » dans du contenu, quand cette chaîne ne marque pas la fin d'une section CDATA.

Dans le contenu des éléments, toute chaîne de caractères ne contenant pas un délimiteur de début de balisage est considéré donnée textuelle. Dans une section CDATA, toute chaîne de caractères ne contenant pas le délimiteur de fin de section CDATA, « ]]> », est considéré donnée textuelle.

L'apostrophe (') peut être représentée par « ' », et le caractère guillemet anglais (") par « " », afin de permettre à des valeurs d'attribut de contenir ces caractères.

2.5 Commentaires

Les commentaires peuvent apparaître n'importe où dans un document en dehors d'autre balisage ; de plus, ils peuvent apparaître dans la déclaration de type de document aux endroits permis par la grammaire. Ils ne font pas partie des données textuelles du document ; un processeur XML peut permettre à une application de récupérer le texte des commentaires. À des fins de compatibilité, la chaîne « -- » (double trait d'union) ne doit pas apparaître à l'intérieur de commentaires.

Exemple de commentaire :

Il est à noter que la grammaire ne permet pas qu'un commentaire se termine par --->. L'exemple suivant est mal formé :

2.6 Instructions de traitement

Les instructions de traitement (IT) permettent aux documents de contenir des instructions pour des applications.

Les IT ne font pas partie des données textuelles des documents mais doivent être transmises à l'application. Une IT commence par une cible (CibleIT) qui identifie l'application à laquelle l'instruction est destinée. Les noms de cible « XML », « xml » et ainsi de suite sont réservés à des fins de standardisation dans cette version ou des versions ultérieures de cette spécification. Le mécanisme de Notation de XML peut être utilisé pour la déclaration formelle des cibles d'IT.

2.7 Sections CDATA

Les sections CDATA peuvent se trouver à n'importe quel endroit acceptable pour des données textuelles ; elles sont employées pour déguiser des blocs de texte contenant des caractères qui seraient autrement identifiés comme balisage. Les sections CDATA commencent par la chaîne « <![CDATA[ » et se terminent par la chaîne « ]]> ».

Dans une section CDATA, seule la chaîne de caractères FinDT est identifiée comme balisage, de sorte que les crochets gauches et les esperluètes peuvent s'y trouver littéralement ; ils n'ont pas besoin (et ne peuvent pas) être déguisés en utilisant « < » et « & ». Les sections CDATA ne peuvent pas s'imbriquer.

Voici un exemple de section CDATA, dans lequel « <accueil> » et « </accueil> » sont reconnus comme données textuelles, et non comme balisage :

2.8 Prologue et déclaration de type de document

Les documents XML peuvent, et devraient, commencer par une déclaration XML qui indique la version de XML utilisée. L'exemple suivant est un document XML, bien formé mais non valide :

ainsi que celui-ci :

Le numéro de version « 1.0 » devrait être employé pour indiquer la conformité à cette version de la spécification ; un document utilisant la valeur « 1.0 » mais ne se conformant pas à cette version de la spécification est en erreur. Le Groupe de travail XML a l'intention de produire des versions ultérieures à la version « 1.0 », mais cette intention ne signifie aucunement un engagement à produire de futures versions de XML ni, si d'autres versions sont produites, à utiliser un plan de numérotation particulier. Puisque de futures versions ne sont pas exclues, cette construction est un moyen de permettre l'identification automatique de la version, si celle-ci devient nécessaire. Les processeurs peuvent signaler une erreur s'ils reçoivent des documents étiquetés avec des versions qu'ils ne connaissent pas.

La fonction du balisage dans un document XML est de décrire sa structure de stockage et sa structure logique et d'associer des paires attributs-valeurs à ses structures logiques. XML fournit un mécanisme, la déclaration de type de document, pour définir des contraintes sur la structure logique et pour gérer l'utilisation des unités de stockage prédéfinies.Un document XML est valide si une déclaration de type de document y est associée et si le document est conforme aux contraintes qu'elle exprime.

La déclaration de type de document doit apparaître avant le premier élément dans le document.

La déclaration de type de document XML contient ou désigne des déclarations de balisage qui fournissent une grammaire pour une classe de documents. Cette grammaire est connue comme déclaration de type de document, ou DTD. La déclaration de type de document peut désigner un sous-ensemble externe (un genre spécial d'entités externes) contenant des déclarations de balisage, peut contenir des déclarations de balisage directement dans un sous-ensemble interne ou peut faire les deux. La DTD d'un document se compose des deux sous-ensembles regroupés.

Une déclaration de balisage est une déclaration de type d'élément, une déclaration de liste d'attributs, une déclaration d'entités ou une déclaration de notation. Ces déclarations peuvent être contenues entièrement ou partiellement dans des entités paramètres, tel que décrit ci-dessous dans les contraintes de forme et de validité. Pour plus d'informations, voir « 4. Structure physique ».

Les déclarations de balisage peuvent se composer entièrement ou partiellement du texte de remplacement d'entités paramètres. Les productions ultérieures dans cette spécification pour différents non-terminaux (déclÉlément, DéclListeAtt, et ainsi de suite) décrivent les déclarations après que toutes les entités paramètres aient été développées.

Contrainte de validité : Type de l'élément racine
Le Nom dans la déclaration de type de document doit correspondre au type d'élément de l'élément racine.

Contrainte de forme : Sous-ensemble externe bien formé
Le sous-ensemble externe, s'il y a lieu, doit correspondre à la production [30] sousEnsembleExt.

Contrainte de forme : Entités paramètre bien formées
Une entité paramètre appelée dans une déclTypeDoc doit correspondre soit à la production [30] sousEnsembleExt (si externe), soit à la production [31] déclSousEnsembleExt (si interne).

Contrainte de validité : Imbrication stricte des déclarations et des EP
Le texte de remplacement des entités paramètres doit être correctement imbriqué dans les déclarations de balisage. Si le premier ou le dernier caractère d'une déclaration de balisage (déclBalisage ci-dessus) est contenu dans le texte de remplacement d'un appel d'entité paramètre, tous les deux doivent être contenus dans le même texte de remplacement.

Contrainte de forme : EP dans le sous-ensemble interne
Dans le sous-ensemble interne de la DTD, les appels d'entité paramètre peuvent se produire seulement là où les déclarations de balisage sont permises, pas à l'intérieur des déclarations de balisage. (Ceci ne s'applique pas aux appels qui se produisent dans les entités paramètres externes ou au sous-ensemble externe.)

Tout comme le sous-ensemble interne, le sous-ensemble externe et les entités paramètres externes mentionnés dans la DTD doivent se composer d'une série de déclarations de balisage complètes des types permis par le symbole non-terminal déclBalisage, parsemées d'espaces ou d'appels d'entité paramètre. Cependant, des parties du contenu du sous-ensemble externe ou des entités paramètres externes peuvent conditionnellement être ignorées en utilisant le mécanisme de section conditionnelle ; ceci n'est pas permis dans le sous-ensemble interne. Le sous-ensemble externe et toute entité paramètre externe mentionnée dans la DTD doivent correspondre à la production entParExt. Cf. la section 4.3.2 Entités analysables bien formées.

Le sous-ensemble externe et les entités paramètres externes diffèrent également du sous-ensemble interne, les appels d'entité paramètre y étant autorisés à l'intérieur des déclarations de balisage, et non seulement entre les déclarations de balisage.

Exemple de document XML avec une déclaration de type de document :

L'identificateur de système « bonjour.dtd » donne l'URI d'une DTD pour le document.

Les déclarations peuvent également être données localement, comme dans l'exemple suivant :

Si les sous-ensembles externes et internes sont utilisés, le sous-ensemble interne est considéré comme se produisant avant le sous-ensemble externe. Ceci a pour effet que les déclarations d'entités et de liste d'attributs du sous-ensemble interne ont priorité sur celles du sous-ensemble externe.

2.9 Déclaration de document autonome

Les déclarations de balisage peuvent affecter le contenu du document, tel qu'il est transmis d'un processeur XML à une application ; des exemples sont des valeurs d'attribut implicites et des déclarations d'entité. La déclaration de document autonome, qui peut apparaître comme composante de la déclaration de XML, précise s'il y a de telles déclarations externes à l'entité document..

Dans une déclaration de document autonome, la valeur « yes » indique qu'il n'y a pas de déclarations de balisage externes à l'entité document (dans le sous-ensemble externe de DTD, ou dans une entité paramètre externe appelée dans le sous-ensemble interne) qui affecterait l'information transmise du processeur XML à l'application. La valeur « no » indique qu'il y a ou peut y avoir de telles déclarations de balisage externes. Notez que la déclaration de document autonome précise seulement la présence de déclarations externes ; la présence, dans un document, d'appels à des entités externes ne change pas son caractère d'autonomie, quand ces entités sont déclarées dans le sous-ensemble interne.

S'il n'y a aucune déclaration de balisage externe, la déclaration de document autonome n'a aucune signification. S'il y a des déclarations de balisage externes mais pas de déclaration de document autonome, la valeur « no » est présumée.

Tout document XML non-autonome (standalone="no") peut être converti algorithmiquement en document autonome, ce qui peut être souhaitable pour des applications diffusées en réseau.

Contrainte de validité : déclaration de document autonome
La déclaration de document autonome doit avoir la valeur « no » si des déclarations de balisage externes contiennent les déclarations suivantes :

• d'attributs avec des valeurs implicites, si les élément auxquels s'appliquent ces attributs apparaissent dans le document sans spécification de valeur pour ces attributs, ou
• d'entités (autres que amp, lt, gt, apos et quot), si des appels à ces entités apparaissent dans le document, ou
• des attributs avec des valeurs sujettes à normalisation, où l'attribut apparaît dans le document avec une valeur qui va changer en raison de la normalisation, ou
• des types d'élément avec contenu élémentaire pur, si du blanc apparaît directement dans toute instance de ce type.

Exemple de déclaration XML avec une déclaration de document autonome :

2.10 Traitement du blanc

En éditant des documents XML, il est souvent commode d'employer « du blanc » (des espaces, tabulations et interlignes) pour distinguer le balisage pour une plus grande lisibilité. Du tel blanc n'est pas typiquement destiné à être inclus dans la version livrée du document. D'autre part, le blanc « significatif » qui devrait être préservé dans la version livrée est courant, par exemple en poésie et en code source.

Un processeur XML doit toujours transmettre à l'application tous les caractères d'un document qui ne sont pas du balisage. Un processeur XML validateur doit également informer l'application desquels de ces caractères constituent le blanc apparaissant dans du contenu élémentaire pur.

Un attribut spécial nommé xml:space peut être associé à un élément pour signaler l'intention que dans cet élément, le blanc soit préservé par les applications. Dans les documents valides, cet attribut, comme tout autre, doit être déclaré s'il est utilisé. Si déclaré, il doit être donné comme type énuméré dont les seules valeurs possibles sont « default » et « preserve ». Par exemple :

La valeur « default » indique que les modes implicites de traitement du blanc sont acceptables pour cet élément ; la valeur « preserve » demande que les applications préservent tout le blanc. Cette intention déclarée s'applique à tous les éléments à l'intérieur du contenu de l'élément porteur de la déclaration, à moins qu'elle ne soit annulée par une autre apparition de l'attribut de xml:space.

L'élément racine de n'importe quel document est considéré comme n'avoir indiqué aucune intention en ce qui concerne le traitement du blanc, à moins qu'il ne fournisse une valeur pour cet attribut ou que l'attribut ne soit déclaré avec une valeur implicite.

2.11 Traitement des fins de ligne

Des entités XML analysables sont souvent enregistrées dans des fichiers qui, pour la commodité d'édition, sont organisés en lignes. Ces lignes sont typiquement séparées par une combinaison du caractère retour chariot (#xD) et retour à la ligne (#xA).

Pour simplifier la tâche des applications, quand une entité externe analysable ou une valeur littérale d'entité d'une entité analysable interne contient soit la séquence de deux caractères littéraux « #xD#xA » soit un littéral #xD, un processeur XML doit transmettre à l'application le seul caractère #xA. (Ce comportement peut simplement être produit en normalisant toutes les bris de ligne à #xA à l'entrée, avant l'analyse.)

2.12 Identification de langue

Dans le traitement de document, il est souvent utile d'identifier la langue naturelle ou formelle dans laquelle le contenu est écrit. Un attribut nommé xml:lang peut être inséré dans les documents pour indiquer la langue utilisée dans le contenu et dans les valeurs d'attributs de tout élément d'un document XML. Dans les documents valides, cet attribut, comme tout autre, doit être declaré s'il est utilisé. Les valeurs de l'attribut sont des identificateurs de langue tels que définis par [IETF RFC 1766], « Balises pour l'identification des langues » :

Les paragraphes qui suivent constituent un résumé non-normatif de la définition des codes de langue de [IETF RFC 1766].

Le CodeLang peut être :

• un code de langue à deux lettres défini par [ISO 639], « Codes pour la représentation des noms des langues » ;
• un code de langue inscrit à l'Internet Assigned Numbers Authority [IANA] ; ceux-ci commencent par le préfixe « i- » (ou « I- ») ;
• un code de langue choisi par l'utilisateur ou ayant fait l'objet d'un accord entre toutes les parties pour une utilisation privée ; ceux-ci doivent commencer par le préfixe « x- » ou « X- » afin de s'assurer qu'ils ne sont pas en conflit avec des noms normalisés ultérieurement ou inscrits à l'IANA.

Il peut y avoir n'importe quel nombre de segments SousCode ; le premier tel sous-code, s'il existe et est formé de deux lettres, doit être un code de pays de [ISO 3166], « Codes pour la représentation des noms des pays. » Si le premier sous-code se compose de plus de deux lettres, ce doit être un code inscrit à l'IANA pour la langue en question, à moins que le CodeLang ne commence par le préfixe « x- » ou « X- ».

Il est usuel de donner le code de langue en minuscules, et le code de pays (s'il y a lieu) en majuscules. Notez que ces valeurs, à la différence d'autres noms dans les documents XML, ne sont pas sensibles à la casse.

Exemples :

L'intention déclarée avec xml:lang est considérée s'appliquer à tous les attributs et au contenu de l'élément où on l'indique, à moins qu'elle ne soit annulée par une apparition de xml:lang sur un autre élément dans ce contenu.

Une déclaration simple pour xml:lang pourrait prendre la forme

mais des valeurs implicites spécifiques peuvent également être attribuées, si appropriées. Dans une collection de poésie française pour étudiants anglais, avec des gloses et des notes en anglais, l'attribut xml:lang pourrait être déclaré de cette façon :

3. Structures logiques

Chaque document XML contient un ou plusieurs éléments, dont les limites sont marquées soit par des balises ouvrantes et fermantes, soit, pour les éléments vides, par une balise d'élément vide. Chaque élément a un type, identifié par un nom, parfois appelé son « identificateur générique » (IG), on peut y associer un jeu de spécifications d'attribut. Chaque spécification d'attribut comprend un nom et une valeur.

Cette spécification ne contraint pas la sémantique, l'utilisation ou (au-delà de la syntaxe) les noms des types d'éléments ou d'attributs, hormis le fait que les noms qui commencent par (('X'|'x')('M'|'m')('L'|'l')) sont réservés à des fins de standardisation dans cette version ou d'ultérieures versions de cette spécification.

Contrainte de forme : Correspondance de type d'élément
Le Nom dans une balise fermante d'un élément doit correspondre au type d'élément de la balise ouvrante.

Contrainte de validité : Élément valide
Un élément est valide s'il existe une déclaration correspondant à déclÉlément où le nom correspond à un type d'élément, et l'une des conditions suivantes est vraie :

1. La déclaration correspond à EMPTY et l'élément n'a pas de contenu.
2. La déclaration correspond à sousÉléments et la suite de sous-éléments appartient au langage engendré par l'expression régulière du modèle de contenu, avec du blanc optionnel (des caractères correspondant au non-terminal S) entre chaque paire de sous-éléments. Il est à noter qu'une section CDATA ne contenant que du blanc ne correspond pas au non-terminal S et par conséquent ne peut apparaître entre deux sous-éléments.
3. La déclaration correspond à Mixte et le contenu est constitué de données textuelles et de sous-éléments dont les types correspondent aux noms dans le modèle du contenu.
4. La déclaration correspond à ANY et le type de chaque sous-élément a été déclaré.

3.1 Balises ouvrantes, balises fermantes et balises d'élément vide

Le début de chaque élément XML non vide est marqué d'une balise ouvrante (ou balise de début).

Le Nom des balises de début et de fin spécifie le type de l'élément. Les couples Nom-ValeurAtt constituent les spécifications d'attribut de l'élément, avec pour chaque couple le Nom désigné par le nom de l'attribut, et le contenu de ValeurAtt (le texte compris entre les délimiteurs « ' » ou « " ») désigné par la valeur de l'attribut. Il est à noter que l'ordre des spécifications d'attribut dans une balise ouvrante ou une balise d'élément vide n'est pas significatif.

Contrainte de forme : Spécification unique de l'attribut
Aucun nom d'attribut ne peut apparaître plus d'une fois dans la même balise de début ou d'élément vide.

Contrainte de validité : Type de valeur de l'attribut
L'attribut doit avoir été déclaré; la valeur doit correspondre au type déclaré pour cet attribut. (Pour les types d'attribut, voir « 3.3 Déclarations des listes d'attributs ».)

Contrainte de forme : Pas d'appel d'entité externe
Les valeurs d'attribut ne peuvent contenir d'appels d'entité directs ou indirects à des entités externes.

Contrainte de forme : Pas de < dans les valeurs d'attribut
Le texte de remplacement de toute entité appelée directement ou indirectement dans une valeur d'attribut (autre que « < ») ne peut contenir un <.

Contrainte de validité : xml:lang valide
Si le Nom dans une spécification d'attribut est xml:lang, la valeur, après normalisation en tant que NMTOKEN, doit correspondre à la production [33].

Exemple de balise ouvrante:

La fin de chaque élément qui commence par une balise de début doit être marqué d'une balise fermante (ou balise de fin) contenant un nom qui renvoie au type de l'élément spécifié dans la balise de début :

Exemple de balise fermante :

On appelle le texte compris entre les balises de début et de fin le contenu de l'élément :

Si un élément est vide, il devrait être indiqué soit par une balise ouvrante suivie immédiatement d'une balise fermante, soit par une balise d'élément vide. Une balise d'élément vide se formule d'une manière particulière :

Les balises d'élement vide peuvent être utilisées pour tout élément qui n'a pas de contenu, qu'il ait été déclaré ou non avec le mot-clé EMPTY. À des fins d'interopérabilité, il est souhaitable d'utiliser la balise d'élément vide pour les éléments qui ont été déclarés EMPTY et de ne pas l'utiliser ailleurs.

Exemples d'éléments vides :

3.2 Déclarations de type d'élément

La structure des éléments d'un document XML peut, à des fins de validation, être contrainte à l'aide de déclarations de type d'élément et de liste d'attributs. La déclaration de type d'un élément contraint le contenu de cet élément.

Les déclarations de type d'un élément limitent habituellement les types d'élément qui peuvent apparaître comme sous-éléments de celui-ci. Au choix de l'utilisateur, un processeur XML peut émettre un avertissement quand une déclaration mentionne un type d'élément pour lequel aucune déclaration n'a été fournie, mais ceci ne constitue pas une erreur.

Une déclaration de type d'élément se formule de la façon suivante :

où le Nom fournit le type d'élément que l'on déclare.

Contrainte de validité : Déclaration de type d'élément unique
Aucun type d'élément ne peut être déclaré plus d'une fois.

Exemples de déclarations de type d'élément :

3.2.1 Contenu élémentaire pur

Un type d'élément a un contenu élémentaire pur quand des éléments de ce type ne peuvent contenir que des sous-éléments, (pas de données textuelles), séparés par du blanc (caractères correspondant au non-terminal S) facultatif. Dans ce cas, la contrainte comprend un modèle de contenu, une grammaire simple régissant les types admis pour les sous-éléments et l'ordre dans lequel ceux-ci peuvent apparaître. Cette grammaire est construite à l'aide de particules de contenu (pc), constituées de noms, de listes de choix de particules de contenu, ou de listes de suites de particules de contenu :

où chaque Nom est le type d'un élément qui peut apparaître comme sous-élément. Une particule de contenu dans une liste de choix peut apparaître au sein d'un contenu élémentaire pur à l'endroit où une liste de choix apparaît dans la grammaire; les particules de contenu présentes dans une liste de suite doivent toutes apparaître dans le contenu élémentaire pur dans l'ordre précisé dans la liste. Les caractères optionnels qui suivent un nom ou une liste déterminent si l'élément ou les particules de contenu dans la liste peuvent apparaître une fois ou plus (+), zéro fois ou plus (*), ou bien au maximum une fois(?). L'absence d'un tel opérateur signifie que l'élément ou la particule de contenu doit apparaître exactement une fois. Leur syntaxe et leur sens sont identiques à ceux qui sont utilisés dans les productions de cette spécification.

Le contenu d'un élément correspond à un modèle de contenu si et seulement si l'on peut tracer un chemin à travers le modèle de contenu qui respecte les opérateurs de suite, de choix et de répétition et qui fait correspondre chaque élément du contenu à un type d'élément défini dans le modèle de contenu. À des fins de compatibilité, le fait qu'un élément dans le document puisse correspondre à plus d'une occurrence de ce type d'élément dans le modèle de contenu constitue une erreur. Pour de plus amples informations, voir « E. Modèles de contenu déterministes ».

Contrainte de validité : Imbrication stricte des parenthèses dans EP
Les parenthèses des textes de remplacement d'une entité paramètre doivent être strictement imbriqués. Ceci signifie que si la parenthèse ouvrante ou fermante d'une production choix, séq ou Mixte se retrouve dans le texte de remplacement d'une entité paramètre, ces deux parenthèses doivent être contenues dans le même texte de remplacement. À des fins d'interopérabilité, si un appel d'entité paramètre apparaît dans une production choix, séq ou Mixte, son texte de remplacement doit contenir au moins un caractère significatif (non blanc) ; de plus, ni le premier ni le dernier caractère significatif (non blanc) du texte de remplacement ne peuvent être un connecteur (| ou ,).

Exemples de modèles de contenu élémentaire pur :

3.2.2 Contenu mixte

Un type d'élément a un contenu mixte quand des éléments de ce type peuvent contenir des données textuelles, parsemées, le cas échéant, de sous-éléments. Dans ce cas, les types des sous-éléments peuvent être contraints mais pas leur ordre ni leur nombre.

où les Noms fournissent les types des éléments qui peuvent apparaître comme sous-éléments. L'étymologie du mot-clé PCDATA est l'anglais « parsed character data », c'est à dire « données textuelles analysables ».

Contrainte de validité : Type unique
Le même nom ne peut apparaître plus d'une fois dans une seule déclaration de contenu mixte.

Exemples de déclarations de contenu mixte :

3.3 Déclarations de liste d'attributs

On utilise des attributs pour associer des couples nom-valeur aux éléments. Les spécifications d'attribut ne peuvent apparaître qu'au sein de balises ouvrantes et de balises d'élément vide ; ainsi, les productions utilisées pour les reconnaître apparaissent dans « 3.1 Balises ouvrantes, balises fermantes et balises d'élément vide ». Les déclarations de liste d'attributs peuvent servir à :

• définir un jeu d'attributs se rapportant à un type d'élément donné;
• établir des contraintes de type pour ces attributs;
• fournir des valeurs implicites pour des attributs.

Les déclarations de liste d'attributs précisent le nom, le type de données et la valeur implicite (le cas échéant) de chaque attribut associé à un type d'élément donné :

Le Nom dans la production DéclListeAtt correspond au type d'un élément. Au choix de l'utilisateur, un processeur XML peut émettre un avertissement si on déclare des attributs pour un type d'élément qui lui-même n'est pas déclaré, mais ceci ne constitue pas une erreur. Le Nom que l'on retrouve dans la règle DéfAtt correspond au nom de l'attribut.

Quand plus d'une DéclListeAtt existe pour un type d'élément donné, le contenu de toutes les déclarations fournies est fusionnée. Quand plus d'une définition existe pour un même attribut d'un type d'élément donné, seule la première déclaration compte, les déclarations subséquentes sont ignorées. À des fins d'interopérabilité, les rédacteurs de DTD pourraient décider de fournir pas plus d'une déclaration de liste d'attributs pour un type d'élément donné, pas plus d'une définition d'attribut pour un nom d'attribut donné dans une déclaration de liste d'attributs et au moins une définition d'attribut dans chaque déclaration de liste d'attributs. De même, à des fins d'interopérabilité, un processeur XML pourra au gré de l'utilisateur émettre un avertissement quand il existe plus d'une déclaration de liste d'attributs pour un type d'élément donné ou quand plus d'une définition d'attribut existe pour un attribut donné, mais ceci ne constitue pas une erreur.

3.3.1 Types d'attribut

Les types d'attribut XML  sont de trois genres: un type chaîne, une série de types atomiques et des types énumérés. Le type chaîne peut prendre comme valeur toute chaîne littérale; les types atomiques subissent différentes contraintes lexicales et sémantiques précisées ci-dessous. Les contraintes de validité indiquées dans la grammaire s'appliquent après que la valeur d'attribut ait été normalisée de la façon précisée dans la section 3.3.3 Normalisation de valeur d'attribut.

Contrainte de validité : ID
Les valeurs de type ID doivent correspondre à la production Nom. Un nom ne peut apparaître plus d'une fois dans un document XML comme la valeur de ce type, i.e. les valeurs ID doivent identifier uniquement les éléments qu'elles désignent..

Contrainte de validité : Un seul ID par type d'élément
Aucun type d'élément ne peut posséder plus d'un attribut ID.

Contrainte de validité : Valeur implicite de l'attribut ID
Un attribut ID doit avoir comme valeur implicite déclarée soit #IMPLIED soit #REQUIRED.

Contrainte de validité : IDREF
Les valeurs de type IDREF doivent correspondre à la production Nom, et les valeurs de type IDREFS doivent correspondre à des Noms ; chaque Nom doit correspondre à la valeur d'un attribut ID sur un élément quelconque du document XML, en d'autres mots les valeurs IDREF doivent correspondre à la valeur d'un attribut ID.

Contrainte de validité : Nom d'entité
Les valeurs de type ENTITY doivent correspondre à la production Nom , les valeurs de type ENTITIES doivent correspondre à des Noms ; chaque Nom doit correspondre au nom d'une entitée non-analysable déclarée dans la DTD.

Contrainte de validité : Atome nomimal
Les valeurs de type NMTOKEN doivent correspondre à la production AtomeNml ; les valeurs de type NMTOKENS doivent correspondre à des AtomeNmx.

Les attributs énumérés peuvent prendre une valeur parmi une liste de valeurs fournie dans la déclaration. Il existe deux sortes de types énumérés :

Un attribut NOTATION identifie une notation, déclarée dans la DTD conjointement avec ses identificateurs systèmes et publics, que l'on utilisera pour interpréter l'élément auquel l'attribut est joint.

Contrainte de validité : Attributs de notation
Les valeurs de ce type doivent correspondre à un des noms de notation inclus dans la déclaration ; tous les noms de notation dans la déclaration doivent être déclarés.

Contrainte de validité : Une seule notation par type d'élément
Nul élément ne peut avoir plus d'un attribut de type NOTATION.

Contrainte de validité : Énumération
Les valeurs de ce type doivent correspondre à un des atomes AtomeNml dans la déclaration.

À des fins d'interopérabilité, le même AtomeNml ne devrait pas apparaître plus d'une fois dans les types d'attribut énuméré d'un même type d'élément.

3.3.2 Valeurs implicites des attributs

Une déclaration d'attribut précise si la présence de l'attribut est exigée et, si elle ne l'est pas, précise le comportement du processeur XML quand l'attribut déclaré est absent dans un document.

Dans une déclaration d'attribut, #REQUIRED signifie que l'attribut doit toujours être fourni, #IMPLIED qu'aucune valeur implicite n'est fournie. Si la déclaration n'est ni #REQUIRED ni #IMPLIED alors la valeur de ValeurAtt précise la valeur implicite déclarée; le mot-clé #FIXED indique que l'attribut doit toujours avoir la valeur implicite. Si une valeur implicite est déclarée, le processeur XML doit se comporter comme si l'attribut était présent et égal à la valeur implicite déclarée lorsqu'il s'aperçoit de l'absence d'un attribut.

Contrainte de validité : Attribut obligatoire
Si la déclaration implicite est le mot-clé #REQUIRED il faut alors préciser l'attribut pour tous les éléments du type dans la déclaration de la liste d'attributs.

Contrainte de validité : Valeur implicite de l'attribut permise
La valeur implicite déclarée doit satisfaire aux contraintes lexicales du type d'attribut déclaré.

Contrainte de validité : Valeur implicite de l'attribut fixe
Si un attribut a une valeur implicite déclarée avec le mot-clé #FIXED, les instances de cet attribut doivent correspondre à la valeur implicite.

Exemples de déclarations de liste d'attributs :

3.3.3 Normalisation de valeur d'attribut

Avant que la valeur d'un attribut ne soit passée à l'application ou que l'on vérifie sa validité, mais après normalisation des fins de ligne selon la section 2.11 Traitement des fins de ligne, le processeur XML doit normaliser cette valeur de la façon suivante :

• on commence avec une chaîne vide comme valeur normalisée ;
• pour chaque caractère, appel d'entité ou appel de caractère de la valeur d'attribut non-normalisée, du début à la fin, agir comme suit :
  • on traite un appel de caractère en ajoutant le caractère appelé à la fin de la valeur normalisée ;
  • on traite un appel d'entité en traitant récursivement le texte de remplacement de l'entité ;
  • on traite une suite « #xD#xA » faisant partie d'une entité analysable externe ou de la valeur littérale d'entité d'une entité analysable interne en ajoutant une espace (#x20) à la fin de la valeur normalisée ;
  • on traite un séparateur (#x20, #xD, #xA, #x9) en ajoutant une espace (#x20) à la fin de la valeur normalisée ;
  • on traite les autres caractères en les ajoutant à la fin de la valeur normalisée.

Si la valeur déclarée n'est pas CDATA alors le processeur XML devra poursuivre le traitement de la valeur normalisée de l'attribut en se défaisant des espaces (#x20) de tête et de queue et en replaçant les suites de espaces (#x20) par un seul caractère espace (#x20).

Tous les attributs pour lesquels on a lu aucune déclaration devrait être considéré par un processeur non-validateur comme si on les avait déclarés au moyen de CDATA.

3.4 Sections conditionnelles

Les sections conditionnelles sont des portions du sous-ensemble externe de la déclaration de type de document qui, selon la valeur d'un mot-clé, sont incluses dans la structure logique de la DTD ou excluses de celles-ci.

À l'instar des sous-ensembles internes et externes de DTD, une section conditionnelle peut contenir une ou plusieurs instances complètes de déclarations, de commentaires, d'instructions de traitement ou de sections conditionnelles imbriquées, le tout parsemé de séparateurs (du blanc).

Si le mot-clé d'une section conditionnelle est INCLUDE alors le contenu de la section conditionnelle fait partie de la DTD. Si le mot-clé de la section conditionnelle est IGNORE alors le contenu de la section conditionnelle ne fait pas partie, au niveau logique, de la DTD. Remarquons qu'afin de rendre l'analyse robuste, il faut lire le contenu des sections conditionnelles même ignorées afin de détecter les sections conditionnelles imbriquées et de s'assurer que la fin de la section conditionnelle (ignorée) la plus englobante est correctement décelée. Si une section conditionnelle marquée du mot-clé INCLUDE se trouve au sein d'une section conditionnelle plus importante qui elle est marqué d'un mot-clé IGNORE, les sections intérieure et extérieure sont toutes deux ignorées.

Si le mot-clé d'une section conditionnelle est un appel d'entité paramètre, on remplacera l'entité paramètre par son contenu avant que le processeur ne décide s'il doit inclure ou ignorer la section conditionnelle.

Exemple :

4. Structures physiques

Un document XML peut être constitué d'une ou plusieurs unités de stockage. Ces unités sont appelées entités ; chacune a un contenu et toutes (à l'exception de l'entité document et du sous-ensemble externe de la DTD) sont identifiées par un nom d'entité. Chaque document XML possède une entité appelée entité document qui sert de point de départ pour le processeur XML et qui peut contenir le document au complet.

Une entité peut être analysable ou non. On désigne le contenu d'une entité analysable sous le nom de texte de remplacement ; ce texte fait partie intégrante du document.

Une entité non-analysable est une ressource dont le contenu n'est pas nécessairement textuel (et pas nécessairement du texte XML même si textuel). On associe à chaque entité non-analysable une notation, identifiée par un nom. XML n'impose aucune contrainte au contenu des entités non-analysables, si ce n'est que les noms des entités et des notations soient mis à la disposition de l'application.

Les entités analysables sont appelées par leur nom au moyen d'un appel d'entité ; le nom des entités non-analysables est fourni par la valeur d'un attribut de type ENTITY ou ENTITIES.

Les entités générales sont destinées à être utilisées dans le contenu du document. Les entités paramètres sont des entités analysables destinées à être utilisées dans la DTD. Les appels à ces deux types d'entités sont différents et sont reconnus dans des contextes différents. De plus, les deux types occupent des espaces de noms distincts ; une entité paramètre et une entité générale de même nom sont deux entités distinctes. Dans ce texte, les entités générales sont parfois appelées simplement entités quand il n'y a pas de risque d'ambiguïté.

4.1 Appels de caractère et d'entité

Un appel de caractère fait référence à un caractère particulier du jeu de caractères ISO/CEI 10646, par exemple un caractère inaccessible par le biais du clavier.

Contrainte de forme : Caractère admissible
Le caractère faisant l'objet d'un appel de caractère doit respecter la production Car.

Si un appel de caractère commence par « &#x », les chiffres et lettres jusqu'au terminateur « ; » constituent une représentation hexadécimale de la position de code du caractère dans l'ISO/CEI 10646. S'il commence seulement par « &# », les chiffres jusqu'au terminateur « ; » constituent une représentation décimale de cette position de code.

Un appel d'entité fait référence au contenu d'une entité nommée. Les appels à des entités générales analysables utilisent l'esperluette (&) et le point-virgule (;) comme délimiteurs. Les appels d'entités paramètres utilisent le symbole pour cent (%) et le point-virgule (;) comme délimiteurs.

Contrainte de forme : Entité déclarée
Dans un document sans DTD, un document avec seulement un sous-ensemble interne de DTD sans appel d'entité paramètre ou un document marqué « standalone='yes' », le Nom donné dans un appel d'entité apparaissant ailleurs que dans le sous-ensemble externe ou dans une entité paramètre doit correspondre au nom d'une déclaration d'entité apparaissant ailleurs que dans le sous-ensemble externe ou dans une entité paramètre. Toutefois, dans les documents bien formés, les entités suivantes n'ont pas à être déclarées : amp, lt, gt, apos, quot. La déclaration d'une entité générale doit précéder tout appel à celle-ci apparaissant dans une valeur implicite dans une déclaration de liste d'attributs. Note : si des entités sont déclarées dans le sous-ensemble externe de DTD ou dans des entités paramètres externes, un processeur non-validateur n'est pas obligé de lire et de traiter leurs déclarations ; pour de tels documents, la règle voulant qu'une entité soit déclarée n'est une contrainte de forme que si standalone='yes'.

Contrainte de validité : Entité déclarée
Dans un document avec sous-ensemble externe de DTD ou des entités paramètres externes avec « standalone='no' », le Nom donné dans l'appel doit correspondre au nom d'une déclaration d'entité. À des fins d'interopérabilité, les documents valides devraient déclarer les entités amp, lt, gt, apos, quot, sous la forme précisée en « 4.6 Entités prédéfinies ». La déclaration d'une entité paramètre doit précéder tout appel à celle-ci. De même, la déclaration d'une entité générale doit précéder tout appel à celle-ci apparaissant dans une valeur implicite dans une déclaration de liste d'attributs.

Contrainte de forme : Entité analysable
Un appel d'entité ne doit pas contenir le nom d'une entité non-analysable. On ne peut faire référence à des entités non-analysables que par le biais de valeurs d'attribut déclarées de type ENTITY ou ENTITIES.

Contrainte de forme : Pas de récursion
Une entité analysable ne doit pas contenir d'appel récursif à elle-même, directement ou indirectement.

Contrainte de forme : Dans la DTD
Les appels d'entité paramètre ne peuvent se trouver que dans la DTD.

Exemples d'appels de caractère et d'entité :

Exemple d'appel d'entité paramètre :

4.2 Déclarations d'entités

On déclare des entités de la façon suivante :

Le Nom identifie l'entité dans un appel d'entité ou, dans le cas d'une entité non-analysable, dans la valeur d'un attribut de type ENTITY ou ENTITIES. Si une même entité est déclarée plus d'une fois, seule la première déclaration compte ; un processeur XML peut alors émettre, au gré de l'utilisateur, un avertissement de déclarations multiples.

4.2.1 Entités internes

Si la définition de l'entité est une ValeurEntité, l'entité ainsi définie est appelée entité interne. Il n'y a pas d'objet stocké séparément et le contenu de l'entité est précisé dans la déclaration. Remarquons que la production du texte de remplacement peut nécessiter le traitement d'appels de caractère et d'entité dans la valeur littérale d'entité : cf. « 4.5 Construction du texte de remplacement d'une entité interne ».

Une entité interne est une entité analysable.

Exemple de déclaration d'entité interne :

4.2.2 Entités externes

Si l'entité n'est pas interne, il s'agit d'une entité externe, déclarée comme suit :

Si la production DéclNdata est présente, il s'agit d'une entité non-analysable générale ; autrement il s'agit d'une entité analysable.

Contrainte de validité : Notation déclarée
Le Nom doit correspondre au nom d'une notation déclarée.

La production LittéralSystème est appelée identificateur système de l'entité. Il s'agit d'un URI, destiné à être utilisé pour récupérer des données que le processeur XML utilisera pour construire le texte de remplacement de l'entité. Il est à noter que le croisillon (#) et l'identificateur de fragment, qui sont fréquemment utilisés avec des URI, ne font pas formellement partie de l'URI. Un processeur XML peut signaler une erreur si un identificateur de système contient un identificateur de fragment. Les URI relatifs doivent être interprétés par rapport à l'emplacement de la ressource au sein de laquelle la déclaration d'entité se trouve, sauf en cas d'information de provenance externe et qui ne relève pas de ce standard, comme un élément XML spécial défini dans une DTD particulière ou une instruction de traitement définie par une application particulière. Un URI peut donc être relatif à l'entité document, à l'entité contenant le sous-ensemble externe de DTD ou à une quelconque entité paramètre externe.

Certains URI peuvent contenir des caractères qui sont soit réservés (cf. [IETF RFC2396], section 2.2) soit hors du domaine ASCII. Un processeur XML devrait traiter un tel caractère dans un URI en le représentant sous forme d'un ou plusieurs octets en UTF-8, puis en transformant chacun de ces octets selon le mécanisme de transformation URI (c'est à dire en convertissant chaque octet en %HH, où HH est la notation hexadécimale de la valeur de l'octet).

En plus d'un identificateur système, un identificateur externe peut contenir un identificateur public. Un processeur XML qui essaie de récupérer le contenu d'une entité peut utiliser l'identificateur public pour en tirer un URI de remplacement. Si le processeur en est incapable, il doit utiliser l'URI précisé par l'identificateur système. L'identificateur public doit être normalisé en transformant toute suite de séparateurs (du blanc) en un seul caractère espace (#x20) et en éliminant tout blanc de tête et de queue.

Exemples de déclaration d'entité externe :

4.3 Entités analysables

4.3.1 La déclaration de texte

Les entités analysables externes peuvent commencer par une déclaration de texte.

La déclaration de texte doit être fournie littéralement et non pas par appel d'une entité analysable. Elle ne peut se trouver qu'au début d'une entité analysable externe.

4.3.2 Entités analysables bien formées

On dit d'une entité document qu'elle est bien formée si elle correspond à la production document. Une entité générale analysable externe est bien formée si elle correspond à la production entAnalExt. Une entité paramètre externe est bien formée si elle correspond à la production entParExt.

Une entité générale analysable interne est bien formée si son texte de remplacement correspond à la production contenu. Toute entité paramètre interne est bien formée par définition.

Il découle du caractère bien formé des entités que les structures logique et physique d'un document XML s'imbriquent proprement ; aucun élément, commentaire, balise ouvrante, balise fermante, balise d'élément vide, instruction de traitement, appel de caractère ou appel d'entité ne peut commencer dans une entité et se terminer dans une autre.

4.3.3 Codage des caractères dans les entités

Chaque entité analysable externe d'un document XML peut utiliser un codage différent pour ses caractères. Tous les processeurs XML doivent être à même de lire les entités en UTF-8 ou UTF-16.

Les entités codées en UTF-16 doivent commencer par une marque d'ordre d'octets telle que décrite par l'annexe F de l'ISO/CEI 10646 ou par la section 2.4 d'Unicode (le caractère ESPACE INSÉCABLE SANS CHASSE, #xFEFF). La marque est une signature de codage et ne fait partie ni du balisage ni des données textuelles du document XML. Les processeurs XML doivent être capables d'utiliser ce caractère pour distinguer les documents codés en UTF-8 et en UTF-16.

Bien que seul le soutien des codages UTF-8 et UTF-16 ne soit requis des processeurs XML, il est clair que d'autres codages sont couramment utilisés et qu'il peut être souhaitable que les processeurs XML puissent lire les entités qui les emploient. En absence d'information de codage de caractères externe (comme des en-têtes MIME), les entités analysables stockées dans un codage autre qu'UTF-8 ou UTF-16 doivent commencer par une déclaration de texte contenant une déclaration de codage :

Dans l'entité document, la déclaration de codage se trouve dans la déclaration XML. NomCodage est le nom du codage utilisé.

Dans une déclaration de codage, les valeurs « UTF-8 », « UTF-16 », « ISO-10646-UCS-2 » et « ISO-10646-UCS-4 » devraient être utilisées pour les divers codages et transformation d'Unicode / ISO/CEI 10646, les valeurs « ISO-8859-1 », « ISO-8859-2 », ... « ISO-8859-9 » pour les parties de l'ISO 8859 et les valeurs « ISO-2022-JP », « Shift_JIS » et « EUC-JP » pour les diverses formes de codage de JIS X-0208-1997. Les processeurs XML peuvent reconnaître d'autres codages ; il est recommandé d'utiliser, pour les codages de caractères répertoriés (comme charset) par l'Internet Assigned Numbers Authority [IANA] autres que ceux ci-dessus, les noms du répertoire de l'IANA. Il est à noter que ces noms sont définis comme indépendants de la casse ; les correspondances avec ces noms doivent donc être faites sans égard à la casse.

En l'absence d'information donnée par un protocole de transport externe (p. ex. HTTP ou MIME), une entité comportant une déclaration de codage mais codée autrement est une erreur, de même qu'une entité codée autrement qu'en UTF-8 qui ne commence pas par une marque d'ordre d'octets ni ne contient une déclaration de codage. L'ASCII étant un sous-ensemble d'UTF-8, les entités codées en ASCII n'ont pas absolument besoin de déclaration de codage.

Une DéclTexte se trouvant ailleurs qu'au début d'une entité externe est une erreur fatale.

Une erreur fatale doit être signalée quand un processeur XML se trouve en présence d'une entité utilisant un codage que le processeur est incapable de traiter. À noter le cas d'erreur subtil suivant : lorsqu'un caractère représenté par une paire de seizets d'indirection (Unicode #xD800 à #xDFFF) est présenté à un transcodeur ne connaissant pas UTF-16, il est possible que ce dernier produisent une suite UTF-8 de 6 octets (3 pour chaque seizet d'indirection). Lorsque décodée, une telle suite donnera 2 « caractères » entre #xD800 et #xDFFF ; ce domaine étant exclu par la production [2], il s'agit d'une erreur fatale.

Exemples de déclarations de texte contenant une déclaration de codage :

4.4 Traitement des entités et des appels par un processeur XML

Le tableau ci-dessous résume dans quels contextes les appels de caractère, les appels d'entité et les références à des entités non-analysables peuvent se produire ainsi que le comportement exigé d'un processeur XML dans chaque cas. Les étiquettes de la colonne de gauche indiquent le contexte :

Appel dans le contenu

Un appel n'importe où entre la balise ouvrante et la balise fermante d'un élément ; correspond au non-terminal contenu.

Appel dans une valeur d'attribut

Un appel soit dans la valeur d'un attribut dans une balise ouvrante, soit dans une valeur implicite dans une déclaration d'attribut ; correspond au non-terminal ValeurAtt.

Valeur d'attribut

Un Nom, et non pas un appel, apparaissant soit comme valeur d'un attribut déclaré de type ENTITY, soit comme un des membres (délimités par des espaces) de la valeur d'un attribut déclaré de type ENTITIES.

Appel dans une valeur d'entité

Un appel dans la valeur littérale d'entité d'une entité paramètre ou interne dans la déclaration d'entité ; correspond au non-terminal ValeurEntité.

Appel dans la DTD

Un appel dans le sous-ensemble interne ou externe de la DTD, mais ailleurs que dans une ValeurEntité, une ValeurAtt, une IT, un Commentaire, un LittéralSystème ou un IdPubLittéral.

4.4.1 Non reconnu

Hors de la DTD, le caractère % n'a aucune signification particulière ; pour cette raison, ce qui serait un appel d'entité paramètre dans la DTD n'est pas reconnu comme balisage dans le contenu. De même, les noms des entités non-analysables ne sont pas reconnus sauf dans les valeurs d'attributs de type approprié.

4.4.2 Inclus

Une entité est incluse quand son texte de remplacement est récupéré et traité, à la place de l'appel lui-même, comme s'il se trouvait dans le document à l'endroit où l'appel est reconnu. Le texte de remplacement peut contenir des données textuelles et du balisage (sauf des entités paramètres) qui doit être reconnu de la manière habituelle, sauf que le texte de remplacement des entités utilisées pour déguiser des délimiteurs de balisage (les entités amp, lt, gt, apos, quot) est toujours traité comme des données. (La chaîne « AT&T; » devient « AT&T; » et l'esperluette restante n'est pas reconnue comme un délimiteur d'appel d'entité). Un appel de caractère est inclus quand le caractère en question est traité à la place de l'appel lui-même.

4.4.3 Inclus si validation

Pour valider un document, un processeur XML doit inclure le texte de remplacement des entités analysables qu'il reconnaît. Toutefois, si une entité est externe et si le processeur ne cherche pas à valider le document, il peut ne pas inclure le texte de remplacement. Un tel processeur non-validateur doit signaler à l'application, le cas échéant, qu'il a reconnu mais n'a pas lu une entité.

Cette règle est motivée par le fait que l'inclusion automatique prévue par le mécanisme d'entité de SGML et XML, conçu avant tout pour faciliter la modularité lors de la rédaction, n'est pas nécessairement approprié pour d'autres applications. En feuilletant des documents, par exemple, on pourra choisir de donner une indication visuelle de la présence d'une entité externe et de ne la récupérer pour affichage que sur demande.

4.4.4 Interdit

Les formes suivantes sont interdites et constituent des erreurs fatales :

• un appel à une entité non-analysable ;
• un appel de caractère ou un appel d'entité générale dans la DTD, sauf dans une ValeurEntité ou une ValeurAtt ;
• un appel d'entité externe dans une valeur d'attribut.

4.4.5 Inclus dans littéral

Lorsqu'un appel d'entité apparaît dans une valeur d'attribut ou lorsqu'un appel d'entité paramètre apparaît dans une valeur littérale d'entité, son texte de remplacement est traité à la place de l'appel comme s'il se trouvait dans le document au lieu où l'appel est reconnu, sauf que les caractères guillemet simple et double dans le texte de remplacement sont toujours traités comme données et ne terminent pas le littéral. L'exemple qui suit est bien formé :

alors que celui-ci ne l'est pas :

4.4.6 Signalé

Quand le nom d'une entité non-analysable fait partie de la valeur d'un attribut déclaré de type ENTITY ou ENTITIES, un processeur validateur doit informer l'application des identificateurs système et public (le cas échéant) de l'entité et de sa notation.

4.4.7 Non interprété

Lorsqu'un appel d'entité générale se trouve dans une ValeurEntité dans une déclaration d'entité, il n'est pas interprété et est laissé tel quel.

4.4.8 Inclus comme EP (entité paramètre)

De même que les entités analysables externes, les entités paramètres n'ont à être incluse que s'il y a validation. Lorsqu'un appel d'entité paramètre est reconnu dans la DTD et inclus, son texte de remplacement est augmenté d'une espace (#x20) au début et à la fin ; ceci dans le but de s'assurer que le texte de remplacement des entités paramètres contient bien un nombre entier d'unités lexicales dans la DTD.

4.5 Construction du texte de remplacement d'une entité interne

En faisant état du traitement des entités internes, il convient de distinguer deux formes de la valeur de l'entité. La valeur littérale d'entité est la chaîne entre guillemets qu'on trouve dans la déclaration d'entité, correspondant au non-terminal ValeurEntité. Le texte de remplacement est le contenu de l'entité, après remplacement des appels de caractère et d'entités paramètres.

La valeur littérale d'entité telle que donnée dans une déclaration d'entité interne (ValeurEntité) peut contenir des appels de caractère, d'entité paramètre et d'entité générale. Ces appels doivent être complètement contenus dans la valeur littérale d'entité. Le texte de remplacement qui est inclus, tel que décrit ci-dessus, doit contenir le texte de remplacement de tout appel d'entité paramètre ainsi que le caractère correspondant à tout appel de caractère ; toutefois, les appels d'entité générale doivent être laissés tels quels, sans remplacement. Par exemple, étant donné les déclarations suivantes :

le texte de remplacement de l'entité « livre » est :

L'appel d'entité générale « &droits; » sera remplacé si l'appel « &livre; » venait à apparaître dans le contenu du document ou dans une valeur d'attribut.

Ces règles simples peuvent avoir des interactions complexes ; on trouvera un exemple difficile expliqué en détails en « D. Remplacement des appels d'entité et de caractère ».

4.6 Entités prédéfinies

On peut employer des appels d'entité ou de caractère pour déguiser le signe inférieur-à, l'esperluette et d'autres délimiteurs. Un jeu d'entités générales (amp, lt, gt, apos, quot) est défini à cette fin. On peut aussi employer des appels numériques de caractère ; ils sont remplacés dès que reconnus et doivent être traités comme données textuelles, de sorte que les appels numériques de caractère « < » et « & » peuvent être utilisés pour déguiser < et & dans des données textuelles.

Tous les processeurs XML doivent reconnaître ces entités, qu'elles soient déclarées ou non. À des fins d'interopérabilité, les documents XML valides devraient déclarer ces entités, comme n'importe quelles autres, avant tout appel. S'il y a lieu, les entités en question devraient être déclarées comme entités internes dont le texte de remplacement est le caractère à déguiser ou un appel de caractère à ce caractère, comme ci-dessous :

Remarquons que les caractères < et & dans les déclarations de « lt » et « amp »sont déguisés doublement, de manière à satisfaire l'exigence que le remplacement d'entité soit bien formé.

4.7 Déclarations de notation

Une notation désigne par un nom le format d'une entité non-analysable, le format d'un élément muni d'un attribut notation ou l'application cible d'une instruction de traitement.

Une déclaration de notation donne un nom à la notation, nom servant dans les déclarations d'entité et de liste d'attributs et dans les stipulations d'attribut, ainsi qu'un identificateur externe qui peut permettre à un processeur XML ou à son application cliente de repérer un assistant capable de traiter des données en cette notation.

Contrainte de validité : Nom de notation unique
Le Nom de notation ne doit pas apparaître dans plus d'une DéclNotation.

Les processeurs XML doivent fournir aux applications les nom et identificateur externe de toute notation déclarée et mentionnée dans une valeur d'attribut, une définition d'attribut ou une déclaration d'entité. Le processeur XML peut aussi transformer l'identificateur externe en un identificateur système, un nom de fichier ou toute autre information utile à l'application pour appeler un processeur propre à la notation. (Il n'y a pas erreur, toutefois, lorsqu'un document XML déclare et mentionne des notations pour lesquelles des processeurs idoines ne sont pas disponibles sur le système où tourne le processeur XML ou l'application).

4.8 L'entité document

L'entité document sert de racine à l'arbre des entités et de point de départ au processeur XML. Ce standard ne précise pas comment un processeur XML peut localiser l'entité document. Contrairement aux autres entités, l'entité document n'a pas de nom et peut fort bien apparaître à l'entrée d'un processeur sans la moindre identification.

5. Conformité

5.1 Processeurs validateurs et non-validateurs

Les processeurs XML conformes sont de deux classes : validateur et non-validateur.

Les processeurs des deux classes doivent signaler les violations de contraintes de forme de ce standard dans le contenu de l'entité document et de toute autre entité analysable qu'ils lisent.

Les processeurs validateurs peuvent en outre, au gré de l'utilisateur, signaler les violations de contraintes exprimées par les déclarations de la DTD et les violations des contraintes de validité précisées par ce standard. Pour ce faire, les processeurs XML validateurs doivent lire et traiter la DTD au complet ainsi que toutes les entités analysables externes mentionnées dans le document.

Les processeurs non-validateurs ne sont tenus que de vérifier la forme de l'entité document, y compris le sous-ensemble interne de la DTD au complet. Bien qu'ils ne soient pas tenus de vérifier la validité du document, ils doivent traiter toutes les déclarations lues dans le sous-ensemble interne de la DTD ainsi que dans toute entité paramètre lue, jusqu'au premier appel d'entité paramètre qui n'est pas lu ; traiter signifie qu'ils doivent utiliser ces déclarations pour normaliser les valeurs d'attribut, inclure le texte de remplacement des entités internes et fournir les valeurs implicites d'attribut. Sauf si « standalone='yes' », ils ne doivent pas traiter les déclarations d'entité ni les déclarations de liste d'attributs qui suivent un appel d'entité paramètre qui n'a pas été lu, puisque cette entité pourrait contenir des déclarations contradictoires.

5.2 Utilisation des processeurs XML

Le comportement d'un processeur XML validateur est éminemment prévisible : il doit lire toutes les parties d'un document et signaler toute violation des contraintes de forme et de validité. On est moins exigeant des processeurs non-validateurs, qui ne sont tenus de lire que l'entité document. Il en résulte deux effets qui peuvent être d'importance pour les utilisateurs de processeurs XML :

• Certaines erreurs de forme, notamment celles dont la détection exige de lire les entités externes, peuvent échapper à un processeur non-validateur. Des exemples de contraintes pouvant être violées sans avertissement sont celles appelées Entité déclarée, Entité analysable et Pas de récursion, ainsi que certains cas décrits comme Interdit dans « 4.4 Traitement des entités et des appels par un processeur XML ».
• L'information transmise du processeur à l'application peut varier, selon que le processeur lit ou non les entités paramètres et externes. Ainsi, un processeur non-validateur peut ne pas normaliser des valeurs d'attribut, ne pas inclure le texte de remplacement d'entités internes ou ne pas fournir des valeurs implicites d'attribut, lorsque ces actions impliquent la lecture préalable de déclarations situées dans des entités paramètres ou externes.

Afin d'optimiser l'interopérabilité entre différents processeurs XML, les applications utilisant des processeurs non-validateurs ne devraient pas se fier à des comportements facultatifs de la part de ces processeurs. Les applications qui nécessitent des fonctions comme les valeurs implicites d'attribut ou des entités internes déclarées dans des entités externes devraient utiliser des processeurs validateurs.

6. Notation

La grammaire formelle de XML est précisée dans ce standard en utilisant une notation simple de forme Backus-Naur étendue (EBNF). Chaque règle de la grammaire définit un symbole, sous la forme :

Un symbole prend une majuscule initiale s'il est le symbole initial d'un langage régulier, une minuscule initiale autrement. Les chaînes littérales sont entre guillemets anglais simples ou doubles ('chaîne littérale', "chaîne littérale").

On utilisera, du côté droit d'une règle, les expressions suivantes qui correspondront à un ou plusieurs caractères :

#xN

où N est un entier hexadécimal. L'expression équivaut au caractère de l'ISO/CEI 10646 dont le point de code (UCS-4) a la valeur N, sans égard au nombre de zéros de tête de la forme #xN ; le nombre de zéros de ce point de code dépend en effet du codage utilisé.

[abc], [#xN#xN#xN]

équivaut à n'importe quel caractère parmi ceux mentionnés.

[a-zA-Z], [#xN-#xN]

équivaut à n'importe quel caractère dont la valeur appartient à l'intervalle indiqué (inclusivement).

[a-zABC], [#xN-#xN#xN#xN#xN]

équivaut à n'importe quel caractère dont la valeur appartient à l'intervalle indiqué (inclusivement) ou correspondant à ceux mentionnés.

[^a-z], [^#xN-#xN]

équivaut à n'importe quel caractère dont la valeur n'appartient pas à l'intervalle indiqué.

[^abc], [^#xN#xN#xN]

équivaut à n'importe quel caractère autre que ceux mentionnés.

"chaîne"

équivaut à une chaîne littérale correspondant à celle indiquée entre guillemets anglais doubles.

'chaîne'

équivaut à une chaîne littérale correspondant à celle indiquée entre guillemets anglais simples.

(expression)

l'expression est traitée comme une unité et peut être agencée selon la description de la liste.

A?

équivaut à A ou à rien ; A facultatif.

A B

équivaut à A suivi de B. La concaténation a priorité sur l'alternation. Ainsi, A B | C D est équivalent à (A B)|(C D).

A | B

équivaut à A ou à B mais pas aux deux.

A - B

équivaut à n'importe quelle chaîne qui correspond à A mais ne correspond pas à B.

A+

équivaut à une ou plusieurs apparitions de A. Cet opérateur a priorité sur la concaténation. Ainsi, A+ B est équivalent à (A+) B.

A*

équivaut à zéro, une ou plusieurs apparitions de A. Cet opérateur a priorité sur la concaténation. Ainsi, A* B est équivalent à (A*) B.

/* ... */

commentaire.

[ cf: ... ]

contrainte de forme ; identifie par un nom une contrainte associée à une production et imposée aux documents bien formés.

[ cv: ... ]

contrainte de validité ; identifie par un nom une contrainte associée à une production et imposée aux documents valides.

Annexes

A. Bibliographie

A.1 Bibliographie normative

IANA

(Internet Assigned Numbers Authority) Official Names for Character Sets, éd. Keld Simonsen et al.
Cf. ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets.

IETF RFC 1766

IETF (Internet Engineering Task Force). RFC 1766 : Tags for the Identification of Languages, éd. H. Alvestrand. 1995.

ISO/CEI 10646

ISO (Organisation internationale de normalisation). ISO/CEI 10646-1993 (F). Technologies de l'information -- Jeu universel de caractères codés à plusieurs octets -- Partie 1: Architecture et table multilingue. [Genève] : Organisation internationale de normalisation, 1993 (ainsi que les amendements AM 1 à AM 7). Texte provisoire de la traduction française disponible sur <http://babel.alis.com/codage/iso10646/index.html>.

Unicode

The Unicode Consortium. The Unicode Standard, version 2.0. Reading, Massachusetts : Addison-Wesley Developers Press, 1996.

A.2 Autres ouvrages

Aho/Ullman

Aho, Alfred V., Ravi Sethi et Jeffrey D. Ullman. Compilateurs: Principes, techniques et outils. InterÉditions, Paris, 1994.

Berners-Lee et al.

Berners-Lee, T., R. Fielding, and L. Masinter. Uniform Resource Identifiers (URI): Generic Syntax and Semantics. 1997. (En cours de rédaction, voir les mises à jour au RFC1738.)

Brüggemann-Klein

Brüggemann-Klein, Anne. Formal Models in Document Processing. Habilitationsschrift. Faculté de mathématiques de l'Université de Fribourg, 1993, disponible à ftp://ftp.informatik.uni-freiburg.de/documents/papers/brueggem/habil.ps.

Brüggemann-Klein and Wood

Brüggemann-Klein, Anne und D. Wood. Deterministic Regular Languages. Résumé étoffé dans A. Finkel, M. Jantzen, Hrsg., STACS 1992, S. 173-184. Springer-Verlag, Berlin 1992. Notes de conférence dans Computer Science 577. Version complète intitulée One-Unambiguous Regular Languages dans Information and Computation 140 (2): 229--253, February 1998.

Clark

James Clark. Comparison of SGML and XML. Cf. http://www.w3.org/TR/NOTE-sgml-xml-971215.

IETF RFC1738

IETF (Internet Engineering Task Force). RFC 1738 : Uniform Resource Locators (URL), éd. T. Berners-Lee, L. Masinter, M. McCahill. 1994.

IETF RFC1808

IETF (Internet Engineering Task Force). RFC 1808 : Relative Uniform Resource Locators, éd. R. Fielding. 1995.

IETF RFC2141

IETF (Internet Engineering Task Force). RFC 2141 : URN Syntax, éd. R. Moats. 1997.

IETF RFC2376

IETF (Internet Engineering Task Force). RFC 2376 : XML Media Types, éd. E. Whitehead, M. Murata, 1998.

IETF RFC2396

IETF (Internet Engineering Task Force). RFC 2396 : Uniform Resource Identifiers (URI): Generic Syntax, éd. T. Berners-Lee, R. Fielding, L. Masinter, 1998.

ISO 639

(Organisation internationale de normalisation). ISO 639:1988 (F). Codes pour la représentation des noms de langue. [Genève] : Organisation internationale de normalisation, 1988.

ISO 3166

(Organisation internationale de normalisation). ISO 3166-1:1997 (F). Codes pour la représentation des noms de pays et de leurs subdivisions -- Partie 1: Codes pays. [Genève] : Organisation internationale de normalisation, 1997.

ISO 8879

ISO (Organisation internationale de normalisation). ISO 8879:1986 (F). Traitement de l'information -- Systèmes bureautiques -- Langage normalisé de balisage généralisé (SGML) (Incorpore l'amendement 1:1988 et l'amendement WebSGML (ajout de l'annexe K)). [Genève] : Organisation internationale de normalisation, 1986.

ISO/IEC 10744

ISO (Organisation internationale de normalisation). ISO/IEC 10744-1992 (E). Technologies de l'information -- Langage de structuration temporelle/hypermédia (HyTime) (Publiée actuellement en anglais seulement) [Genève] : Organisation internationale de normalisation, 1992. Extended Facilities Annexe. [Genève] : Organisation internationale de normalisation, 1996.

B. Classes de caractères

Conformément aux caractéristiques définies dans le standard Unicode, les caractères sont classés en caractères de base (parmi lesquels on retrouve les lettres de l'alphabet latin sans diacritiques), en caractères idéographiques et en caractères jonctifs (on y retrouve notamment la plupart des diacritiques). On distingue aussi les chiffres et les modificateurs de lettre.

Les classes de caractères définies ci-dessus peuvent être dérivées de la base de données des caractères d'Unicode de la façon suivante :

• Les caractères initiaux de nom doivent appartenir à une des catégories suivantes : Ll, Lu, Lo, Lt, Nl.
• Les autres caractères constitutifs de nom doivent appartenir à une des catégories Mc, Me, Mn, Lm, ou Nd.
• Les caractères dans la zone de compatibilité (c-à-d ceux dont la valeur est supérieure à #xF900 et inférieure à #xFFFE) ne sont pas admis dans les noms XML.
• Les caractères qui connaissent une décomposition de compatibilité (c-à-d ceux dont le champ 5 dans la base de données contient une « balise de formatage de compatibilité », indiqué par un champ 5 commençant par un « < ») ne sont pas permis.
• Les caractères suivants sont considérés des caractères initiaux de nom, car le fichier de propriétés les classe parmi les caractères alphabétiques : [#x02BB-#x02C1], #x0559, #x06E5, #x06E6.
• Les caractères #x20DD-#x20E0 sont exclus (conformément à la section 5.14 d'Unicode).
• Le caractère #x00B7 est classé parmi les modificateurs de lettre, le fichier de propriétés le classant de la sorte.
• Le caractère #x0387 est considéré comme un caractère constitutif de nom car #x00B7 est son équivalent canonique.
• Les caractères « : » et « _ » sont permis comme caractères initiaux de nom.
• Les caractères « - » et « . » sont permis comme caractères constitutifs de nom.

C. XML et SGML (annexe informative)

XML a été conçu de telle sorte qu'il soit un sous-ensemble de SGML, ce qui signifie que tout document XML devrait également être un document SGML conforme. Pour une comparaison détaillée des restrictions que XML impose aux documents au-delà de celles imposées par SGML, voir [Clark].

D. Développement des appels d'entité et de caractères (annexe informative)

Cette annexe illustre par quelques exemples la suite des opérations de reconnaissance et de développement qui ont lieu lors du traitement des appels d'entité et de caractères, tel que décrit dans « 4.4 Traitement des entités et des appels par un processeur XML ».

Si la DTD contient la déclaration suivante :

alors le processeur XML reconnaîtra les appels de caractères lors de l'analyse de la déclaration d'entité et les résoudra avant de stocker la chaîne suivante comme valeur de l'entité « exemple » :

Un appel à « &exemple; » au sein du document enclenchera une nouvelle analyse du texte, lors de laquelle on reconnaîtra les balises ouvrante et fermante de l'élément « p » ainsi que les trois appels qui seront développés. On aura donc comme résultat un élément « p » avec le contenu suivant (rien que des données, pas de délimiteur ni de balisage) :

Un exemple plus complexe illustrera complètement les règles en question et leurs effets. Dans l'exemple ci-dessous, les numéros de ligne ne servent que de référence.

Ce qui a pour résultat :

• à la ligne 4, de développer d'emblée l'appel au caractère 37, et de stocker l'entité paramètre « xx » dans la table des symboles avec comme valeur « %zz; ». Puisqu'on ne réanalyse pas le texte de remplacement, il n'y a pas reconnaissance de l'appel à l'entité paramètre « zz » par le processur (reconnaissance qui aurait causé une erreur, « zz » n'étant pas encore déclarée.)
• à la ligne 5, de développer sur le champ l'appel de caractère « < » et de stocker l'entité paramètre « zz » avec comme texte de remplacement « <!ENTITY risquée "sujet à erreurs" > », une déclaration d'entité bien formée.
• à la ligne 6, de reconnaître l'appel à « xx » et d'analyser le texte de remplacement de « xx » (à savoir « %zz; »). Le processeur reconnaît alors l'appel à « zz » et analyse son texte de remplacement (« <!ENTITY risquée "sujet à erreurs" > »). L'entité générale « risquée » est donc maintenant déclarée avec comme texte de remplacement « sujet à erreurs ».
• à la ligne 8, de reconnaître l'appel à l'entité générale « risquée » et de la développer de telle sorte que le contenu de l'élément « essai » est la chaîne auto-descriptive (et agrammaticale) Cet exemple illustre une méthode sujet à erreurs.

E. Modèles de contenu déterministes (annexe informative)

Pour favoriser la compatibilité, il est nécessaire que les modèles de contenu des déclarations de type d'éléments soient déterministes.

SGML exige des modèles de contenu déterministes (appelés « non-ambiguës ») ; les processeurs XML construits sur la base de systèmes SGML peuvent signaler comme erreurs les modèles de contenu non-déterministes.

Par exemple, le modèle de contenu ((b, c) | (b, d)) est non-déterministe, car étant donné un b initial, l'analyseur ne peut déterminer à quel b du modèle il correspond sans savoir d'avance quel élément suit le b. Dans ce cas-ci, les deux références àb peuvent être fusionnés en une seule référence, le modèle devenant (b, (c | d)). Un b initial correspond maintenant clairement à un seul nom dans le modèle de contenu. L'analyseur n'a plus besoin de prévoir ce qui suit ; c ou d serait accepté.

Formellement : un automate à états finis peut être construit, à partir du modèle de contenu, en utilisant les algorithmes standards comme l'algorithme 3.5 dans la section 3.9 de Aho, Sethi et Ullman [Aho/Ullman]. Dans plusieurs de ces algorithmes, un ensemble des suivants est construit pour chaque position dans l'expression régulière (c-à-d chaque feuille dans l'arbre syntaxique de l'expression régulière) ; si une des positions a un ensemble des suivants dans lequel plus d'une des positions suivantes a le même nom de type d'élément, alors le modèle de contenu est erroné et peut être signalé comme tel.

Il existe des algorithmes permettant de réduire automatiquement beaucoup de modèles de contenu non-déterministes (mais pas tous) à des modèles déterministes équivalents ; cf. Brüggemann-Klein 1991 [Brüggemann-Klein].

F. Auto-détection du codage de caractères (annexe informative)

La déclaration de codage XML tient le rôle d'étiquette interne à chaque entité, indiquant quel codage de caractères y est utilisé. Pour qu'un processeur XML puisse lire l'étiquette interne, toutefois, il semble devoir connaître le codage utilisé, ce qui est précisément ce que l'étiquette cherche à annoncer. En général, la situation est sans issue. Le cas est néanmoins meilleur en XML, puisque XML limite le cas général de deux façons : un processeur donné ne gère qu'un nombre fini de codages de caractères ; il y a des restrictions sur la position et le contenu de la déclaration de codage XML, restrictions telles qu'il est faisable de détecter automatiquement le codage de chaque entité dans les cas normaux. De plus, dans bien des cas d'autres sources d'information sont disponibles en sus des données XML elles-mêmes. Deux cas sont à distinguer, selon qu'une entité XML est présentée au processeur avec ou sans information externe sur le codage. Nous considérons d'abord le dernier cas.

Étant donné que toute entité XML codée autrement qu'en UTF-8 ou UTF-16 doit commencer par une déclaration de codage, dont les premiers caractères doivent être '<?xml', tout processeur conforme peut déterminer, après avoir lu de deux à quatre octets, lequel des cas suivants s'applique. En lisant cette liste, il peut être utile de se rappeler qu'en UCS-4, '<' et '?' sont représentés par "#x0000003C" et"#x0000003F" respectivement, alors que la marque d'ordre d'octets exigée en UTF-16 est "#xFEFF". La notation ## est utilisée pour indiquer n'importe quelle valeur d'octet sauf 00.

• Avec marque d'ordre d'octets :
  • 00 00 FE FF : UCS-4, machine grand-boutienne (ordre 1234)
  • FF FE 00 00 : UCS-4, machine petit-boutienne (ordre 4321)
  • FE FF 00 ## : UTF-16, grand-boutien
  • FF FE ## 00 : UTF-16, petit-boutien
• Sans marque d'ordre d'octets :
  • 00 00 00 3C : UCS-4, machine grand-boutienne (ordre 1234)
  • 3C 00 00 00 : UCS-4, machine petit-boutienne (ordre 4321)
  • 00 00 3C 00 : UCS-4, ordre des octets inhabituel (2143)
  • 00 3C 00 00 : UCS-4, ordre des octets inhabituel (3412)
  • 00 3C ## ##,
    00 25 ## ##,
    00 20 ## ##,
    00 09 ## ##,
    00 0D ## ## ou
    00 0A ## ## : UTF-16 ou ISO-10646-UCS-2, grand-boutien. Il est à noter que, sans déclaration de codage, ces cas sont à strictement parler des erreurs.
  • 3C 00 ## ##,
    25 00 ## ##,
    20 00 ## ##,
    09 00 ## ##,
    0D 00 ## ## ou
    0A 00 ## ## : UTF-16 ou ISO-10646-UCS-2, petit-boutien. Il est à noter que, sans déclaration de codage, ces cas sont à strictement parler des erreurs.
  • 3C 3F 78 6D : UTF-8, ISO 646, ASCII, quelconque partie de l'ISO 8859, Shift-JIS, EUC, ou tout autre codage à 7 bits, 8 bits ou de largeur variable tel que les caractères ASCII ont leur position, largeur et valeur habituelle ; la déclaration de codage doit être lue pour déterminer exactement de quel codage il s'agit, ce qui peut être fait de façon fiable puisque tous ces codages utilisent les mêmes bits pour les caractères ASCII.
  • 4C 6F A7 94 : EBCDIC (quelconque ; la déclaration de codage doit être lue pour déterminer la page de code exacte).
  • autre : UTF-8 sans déclaration de codage, ou alors le flux de données est corrompu, fragmentaire ou emballé de quelque façon.

Ce niveau d'auto-détection est suffisant pour lire la déclaration de codage XML et en tirer le nom du codage, qui est nécessaire pour distinguer les membres de chaque famille de codage (par ex. distinguer UTF-8 de 8859, distinguer les parties de 8859, distinguer les diverses pages de code EBCDIC, etc.)

Puisque le contenu de la déclaration de codage est limité aux caractères ASCII, un processeur peut la lire de façon fiable dès qu'il a identifié la famille de codage utilisée. En pratique, tous les codages de caractères font partie d'une des familles sus-mentionnées ; la déclaration de codage permet donc une identification raisonnablement robuste du codage des caractères, même en l'absence d'une source fiable d'information externe (système d'exploitation ou protocole de transport). Note : puisque les entités analysables externes en UTF-16 peuvent débuter par n'importe quel caractères, cette auto-détection ne fonctionne pas toujours. De plus, le codage UTF-7 peut ne pas être détecté fiablement, à cause de la surchage qu'il impose aux caractères ASCII.

Dès que le processeur a déterminé le codage utilisé, il peut agir en conséquence, en appelant une routine d'entrée pour chaque cas ou en appelant la fonction de conversion appropriée pour chaque caractère.

Comme tout système d'auto-étiquetage, la déclaration de codage XML cesse de fonctionner si un logiciel change le codage de l'entité sans la mettre à jour. Les concepteurs de routines de codage de caractères doivent être attentifs pour assurer l'exactitude de l'information interne ou externe rattachée à l'entité.

Le second cas de figure se présente lorsque l'entité XML est accompagnée d'information sur le codage, fournie par certains systèmes de fichier et certains protocoles réseau. En présence de plusieurs sources d'information, il convient que le protocole de haut niveau qui transporte l'entité précise leur priorités relatives ainsi que la méthode préconisée pour résoudre les conflits potentiels. Voir notamment le [IETF RFC2376] « XML Media Types » qui définit les types MIME text/xml et application/xml et fournit d'utiles indications. Pour faciliter l'intéropérabilité, toutefois, la règle suivante est recommandée :

• Si une entité XML se trouve dans un fichier, la marque d'ordre d'octet et la déclaration de codage (le cas échéant) sont utilisées pour déterminer le codage de caractères. Toute autre source d'information ne doit servir qu'à la récupération d'erreur.

G. Groupe de travail XML du W3C (annexe informative)

Cette recommendation a été préparée et approuvée pour publication par le groupe de travail XML du W2C (le GT). L'approbation du GT ne signifie pas que tous les membres du GT ont voté positivement. Les membres actuels et passés du GT sont :

Copyright  ©  1998 W3C (MIT, INRIA, Keio ), tous droits réservés. Les règles du W3C sur la responsabilité, les marques de commerce, les droits d'auteur et les licences de logiciels sont applicables.