1.1 Origine et buts

Le XML a été développé par un Groupe de travail XML (initialement connu sous le nom de Comité d'Examen Éditorial SGML) constitué sous les auspices du Consortium World Wide Web (W3C) en 1996. Il était présidé par Jon Bosak de Sun Microsystems avec la participation active d'un Groupe d'Intérêt Spécial XML (auparavant connu comme le Groupe de Travail du SGML), également organisé par le W3C. La composition du Groupe de travail XML est donnée en annexe. Dan Connolly agissait comme contact du Groupe de Travail auprès du W3C.

Les objectifs de conception du XML sont les suivants :

1. le XML devrait pouvoir être utilisé sans difficulté sur l'Internet;

2. le XML devrait supporter une large variété d'applications;

3. le XML devra être compatible avec le SGML;

4. il devrait être facile d'écrire des programmes traitant les documents XML;

5. le nombre de caractéristiques optionnelles du 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 du XML devrait être préparée rapidement;

8. la conception du XML sera formelle et concise;

9. les documents XML devraient être facile à créer;

10. la concision dans le balisage XML a peu d'importance.

Cette spécification, ainsi que certains standards associés (Unicode [Unicode] et l'ISO/CEI 10646 [ISO/IEC 10646] pour les caractères, la BCP 47 [IETF BCP 47] et le Language Subtag Registry [IANA-LANGCODES] pour les balises d'identification de langue), fournissent toute l'information nécessaire pour comprendre la version 1.0 du XML et construire des programmes pour la traiter.

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

1.2 Terminologie

La terminologie utilisée pour décrire les documents XML est définie dans le corps dans cette spécification. Les mots-clés DOIT, NE DOIT PAS, REQUIS, DEVRA, NE DEVRA PAS, DEVRAIT, NE DEVRAIT PAS, RECOMMANDÉ, PEUT, et OPTIONNEL, lorsqu'ils sont SOULIGNÉS, doivent être interprétés dans cette spécification comme décrits dans la [IETF RFC 2119]. Enfin, 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 :

erreur

[Définition : une violation des règles de cette spécification; les résultats sont indéterminés. Sauf indication contraire, l'échec d'une prescription de cette spécification est indiquée dans une erreur par l'un des mots-clés DOIT, REQUIS, NE DOIT PAS, DEVRA ou NE DEVRA PAS. Un logiciel conforme PEUT détecter et signaler une erreur et PEUT s'en remettre.]

erreur fatale

[Définition : 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). Toutefois, dès qu'une erreur fatale est détectée, le processeur NE DOIT PAS continuer le traitement normal (c.-à-d. qu'il NE DOIT PAS continuer de transmettre à l'application les données textuelles et l'information sur la structure logique du document de manière habituelle).]

au gré de l'utilisateur

[Définition : un logiciel conforme PEUT ou DOIT (selon le verbe dans la phrase) se comporter tel que décrit; si tel est le cas, il DOIT fournir à l'utilisateur un moyen d'activer ou de désactiver le comportement décrit.]

contrainte de validité

[Définition : 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 validants.]

contrainte de forme

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

correspondance

[Définition : (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 ayant plusieurs représentations dans l'ISO/CEI 10646 (p. ex. les caractères à la fois précomposés et de la forme base + diacritique) correspondent seulement s'ils ont la même représentation dans les deux chaînes de caractères. Aucune transformation de casse n'est effectuée. (De chaînes de caractères et de règles de grammaire :) Une chaîne de caractères correspond à une production grammaticale si elle appartient au langage généré par 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 par la contrainte [VC: Élément valide].]

à des fins de compatibilité

[Définition : marque une phrase décrivant une caractéristique du XML incluse uniquement afin de s'assurer que le XML demeure compatible avec le SGML.]

à des fins d'interopérabilité

[Définition : marque une phrase décrivant une recommandation incluse pour augmenter les chances que les documents XML puissent être traités par les processeurs SGML de base existant qui sont antérieur au « WebSGML Adaptations » de l'ISO 8879.]

2.1 Documents XML bien formés

[Définition : Un objet textuel est un document XML bien formé si :]

1. pris dans son ensemble, il correspond à la production étiquetée document;

2. il réponds à toutes les contraintes de forme données par cette spécification;

3. chacune des entités analysables générales référencées directement ou indirectement dans le document est bien formée.

Document

La correspondance de la production document implique que :

1. Le document contient un ou plusieurs éléments.

2. [Définition : Il existe un unique élément, appelé racine, ou élément document, dont aucune partie n'apparaît dans le contenu d'un autre élément.] Pour tous autres éléments, si la balise d'ouverture est dans le contenu d'un autre élément, la balise de fermeture est dans le contenu du même élément. Autrement dit, les éléments, délimités par des balises d'ouverture et de fermeture, s'imbriquent correctement les uns dans les autres.

[Définition : En conséquence, pour chaque élément non-racine F dans le document, il existe, dans le document, un autre élément P tel que F soit dans le contenu de P, mais qui n'est pas dans le contenu d'un autre élément qui soit dans le contenu de P. P fait référence au parent de F, et F au fils de P.]

2.2 Caractères

[Définition : Une entité analysable contient du texte, une suite de caractères, qui peuvent représenter du balisage ou des données textuelles.] [Définition : Un caractère est une unité atomique de texte définit par l'ISO/CEI 10646:2000 [ISO/IEC 10646]. Les caractères admis sont la tabulation, le retour chariot, le saut de ligne, les caractères Unicode et les caractères ISO/CEI 10646. Les versions de ces standards, cités dans A.1 Références normatives, étaient courantes au moment où ce document a été préparé. De nouveaux caractères peuvent être ajoutés à ces standards par des amendements ou de nouvelles éditions. Par conséquent, les processeurs XML DOIVENT accepter tous les caractères de l'ensemble spécifié pour Char.]

Ensemble de caractères

Le mécanisme de codage des points de code de caractère en motifs binaires peut varier d'une entité à l'autre. Tous les processeurs XML DOIVENT accepter les codages UTF-8 et UTF-16 d'Unicode [Unicode] ; les mécanismes pour signaler lequel des deux est utilisé, ou pour introduire d'autres codages en jeu, sont discutés ci-dessous, dans 4.3.3 Codage des caractères dans les entités.

[#x7F-#x84], [#x86-#x9F], [#xFDD0-#xFDEF],
[#x1FFFE-#x1FFFF], [#x2FFFE-#x2FFFF], [#x3FFFE-#x3FFFF],
[#x4FFFE-#x4FFFF], [#x5FFFE-#x5FFFF], [#x6FFFE-#x6FFFF],
[#x7FFFE-#x7FFFF], [#x8FFFE-#x8FFFF], [#x9FFFE-#x9FFFF],
[#xAFFFE-#xAFFFF], [#xBFFFE-#xBFFFF], [#xCFFFE-#xCFFFF],
[#xDFFFE-#xDFFFF], [#xEFFFE-#xEFFFF], [#xFFFFE-#xFFFFF],
[#x10FFFE-#x10FFFF].

2.3 Constructions syntaxiques communes

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

S (espace blanc) se compose d'un ou plusieurs caractères espace (#x20), retours chariots, sauts de ligne ou tabulations.

Espace blanc

Un Nmtoken (name token, atome nominal) est un mélange de caractères de nom.

[Définition : Un Name est un Nmtoken avec un ensemble limité de caractères initiaux.] Les caractères initiaux non autorisés pour les Names sont les chiffres, les diacritiques, le point final et la césure.

Dans cette version ou les versions ultérieures de cette spécification, les noms commençant par la chaîne de caractères « xml », ou toute chaîne de caractères correspondant à (('X'|'x') ('M'|'m') ('L'|'l')), sont réservés à des fins de normalisation.

Le premier caractère d'un Name DOIT être un NameStartChar, et tous les autres caractères DOIVENT être des NameChars; ce mécanisme est utilisé afin d'éviter les noms commençant par des chiffres Européens (ASCII) ou par une combinaison de caractères de base. La plupart des caractères sont permit dans les noms, excepter ceux qui sont ou qui pourraient être raisonnablement utilisés comme délimiteurs. L'intention est d'être inclusif plutôt qu'exclusif, de sorte que les systèmes d'écriture pas encore encodés en Unicode puissent être utilisés pour les noms XML. Voir J Suggestions pour les noms XML pour des suggestions sur la création des noms.

Les auteurs de documents sont encouragés à utiliser des noms qui soient des mots ou des combinaisons de mots significatifs dans les langues naturelles, et à éviter la symbolique ou les caractères d'espace blancs. Notez que COLON, HYPHEN-MINUS, FULL STOP (point final), LOW LINE (souligner) et MIDDLE DOT sont explicitement autorisés.

Les symboles ASCII et les marques de ponctuations, ainsi que de nombreux caractères symboliques de l'Unicode, sont exclus des noms parce qu'ils sont plutôt utilisés comme délimiteurs dans des contextes où les noms XML sont utilisés en dehors des documents XML. Le caractère #x037E, POINT D'INTERROGATION GREC, est exclus parce qu'il est normalisé sous la forme d'un point virgule, ce qui pourrait changer la signification des références d'entités.

Noms et atomes nominaux

Une donnée littérale est une chaîne de caractères entre guillemets ne contenant pas le caractère guillemet utilisé comme délimiteur de cette chaîne. Les littéraux sont utilisés pour spécifier le contenu des entités internes (EntityValue), des valeurs d'attributs (AttValue), et des identificateurs externes (SystemLiteral). Notez qu'un SystemLiteral peut être analysé sans parcourir le balisage.

Littéraux

2.4 Données textuelles et balisage

Le texte se compose de données textuelles et de balisage entremêlés. Le [Définition : balisage prend la forme de balises d'ouverture, de balises de fermeture, de balises d'éléments vides, de références d'entité, de références de caractère, de commentaires, de délimiteurs de section CDATA, de déclarations de type de document, d'instructions de traitement, de déclarations XML, de déclarations de texte et de tout espace blanc qui se trouve au niveau de l'entité document (à savoir, en dehors de l'élément document et non pas dans une balise).]

[Définition : Tout le texte qui n'est pas du balisage constitue les données textuelles du document.]

Les caractères esperluète (&) et inférieur à (<) NE DOIVENT PAS apparaître sous leur forme littérale, excepter lorsqu'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 échappés en utilisant des références numériques de caractères ou les chaînes de caractères « & » et « < » respectivement. Le caractère supérieur à (>) peut être représenté en utilisant la chaîne de caractères « > », et pour la compatibilité, il DOIT être échappé en utilisant « > » ou une référence de caractère lorsqu'il apparaît dans la chaîne de caractères « ]]> » d'un contenu, ou lorsque cette chaîne de caractères ne marque pas la fin d'une section CDATA.

Dans le contenu des éléments, une donnée textuelle est une chaîne de caractères ne contenant pas de délimiteur de début de balise et n'incluant pas de délimiteur de fin de section CDATA, « ]]> ». Dans une section CDATA, une donnée textuelle est une chaîne de caractères ne contenant pas le délimiteur de fin de section CDATA, « ]]> ».

Afin de permettre aux valeurs d'attribut de contenir des guillemets droits simples ou doubles, ou le caractère simple quote (') peut être représenté par « ' », et le caractère guillemet droit double (") par « " ».

Données textuelles

2.5 Commentaires

[Définition : 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, mais pas nécessairement, permettre à une application de récupérer le texte des commentaires. Pour la compatibilité, la chaîne de caractères « -- » (double tiret) NE DOIT PAS apparaître dans les commentaires.] Les références d'entité paramètre (abrégée EP) NE DOIVENT PAS être reconnues dans les commentaires.

Commentaires

Un exemple de commentaire :

<!-- declarations for <head> & <body> -->

Notez que la grammaire ne permet pas qu'un commentaire se termine par la chaîne de caractère --->. L'exemple suivant n'est pas bien formé.

<!-- B+, B, or B--->

2.6 Instructions de traitement

[Définition : Les instructions de traitement (IT) permettent aux documents de contenir des instructions pour les applications.]

Instructions de traitement

Les instructions de traitement ne font pas partie des données textuelles des documents, mais DOIVENT être transmises à l'application. Une instruction de traitement commence par une cible (PITarget), utilisée pour identifier l'application à laquelle l'instruction est destinée. Dans cette version ou les versions ultérieures de cette spécification, les noms de cible « XML », « xml », etc, sont réservés à des fins de standardisation. Le mécanisme de Notation du XML peut être utilisé pour la déclaration formelle des cibles d'une instruction de traitement. Les références d'entité paramètre NE DOIVENT PAS être reconnues dans les instructions de traitement.

2.7 Sections CDATA

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

Sections CDATA

Dans une section CDATA, seule la chaîne de caractères CDEnd est reconnue comme balisage, de sorte que les caractères inférieur à et esperluète peuvent s'y trouver sous leur forme littérale; ils n'ont pas besoin (et ne peuvent pas) être échappés en utilisant « < » et « & ». Les sections CDATA ne peuvent pas s'imbriquer.

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

<![CDATA[<greeting>Hello, world!</greeting>]]> 

2.8 Prologue et Déclaration de Type de Document

[Définition : Les documents XML DEVRAIENT commencer par une déclaration XML qui définit la version du XML utilisé.] Par exemple, l'extrait suivant est un document XML bien formé complet mais non valide :

<?xml version="1.0"?>
<greeting>Hello, world!</greeting> 

il en est de même de celui-ci :

<greeting>Hello, world!</greeting>

La fonction du balisage dans un document XML consiste à décrire son stockage et sa structure logique et à associer des paires nom-valeur à ses structures logiques. Le XML fournit un mécanisme, la déclaration de type de document, pour définir des contraintes sur la structure logique et pour supporter l'utilisation des unités de stockage prédéfinies. [Définition : Un document XML est valide s'il est associé à une déclaration de type de document et si le document est conforme aux contraintes exprimées.]

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

Prologue

Bien que la production VersionNum corresponde à un numéro de version de la forme '1.x', les documents XML 1.0 NE DOIVENT PAS spécifiés un numéro de version différent de '1.0'.

[Définition : La déclaration de type de document XML contient ou pointe 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 pointer un sous-ensemble externe (une sorte d'entité externe spéciale) contenant des déclarations de balisage, ou peut contenir des déclarations de balisage directement dans un sous-ensemble interne ou peut contenir les deux. La DTD d'un document se compose des deux sous-ensembles regroupés.]

[Définition : 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é 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 Structures physiques.

Déclaration de Type de Document

Notez qu'il est possible de construire un document bien formé contenant une doctypedecl qui ne pointe pas un sous-ensemble externe et ne contient pas de sous-ensemble interne.

Les déclarations de balisage peuvent se composer entièrement ou partiellement du texte de remplacement d'entités paramètres. Dans cette spécification, les productions suivantes pour les différents non-terminaux (elementdecl, AttlistDecl, et ainsi de suite) décrivent les déclarations après que toutes les entités paramètres aient été incluses.

Les références d'entité paramètre sont reconnues partout dans la DTD (les sous-ensembles interne et externe, et les entités paramètres externes), excepter dans les littéraux, les instructions de traitement, les commentaires, et les contenus de sections conditionnelles ignorées (voir 3.4 Sections conditionnelles). Elles sont également reconnues dans une valeur littérale d'entité. L'utilisation d'entités paramètres dans le sous-ensemble interne est limitée comme décrit ci-dessous.

Tout comme le sous-ensemble interne, le sous-ensemble externe et les entités paramètres externes référencées dans un DeclSep DOIVENT être composer d'une suite de déclarations de balisage complète des types permis par le symbole non-terminal markupdecl, parsemées d'espaces blancs ou de références 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 mais l'est dans les entités paramètres externes référencées dans le sous-ensemble interne.

Sous-ensemble externe

Le sous-ensemble externe et les entités paramètres externes diffèrent également du sous-ensemble interne, les références d'entité paramètre sont permises à l'intérieur des déclarations de balisage, pas seulement entre les déclarations de balisage.

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

<?xml version="1.0"?>
<!DOCTYPE greeting SYSTEM "hello.dtd">
<greeting>Hello, world!</greeting> 

L'identificateur de système « hello.dtd » donne l'adresse (une référence d'URI) d'une DTD du document.

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

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE greeting [
  <!ELEMENT greeting (#PCDATA)>
]>
<greeting>Hello, world!</greeting>

Si les sous-ensembles externe et interne sont utilisés, le sous-ensemble interne DOIT être 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; les attributs par défaut et des déclarations d'entité en sont des exemples. La déclaration de document autonome, qui peut apparaître comme un composant de la déclaration XML, précise s'il existe ou non de telles déclarations, lesquelles apparaissent comme externes à l'entité document ou dans les entités paramètres. [Définition : Une déclaration de balisage externe est définie comme une déclaration de balisage se trouvant dans le sous-ensemble externe ou dans une entité paramètre (externe ou interne, cette dernière étant incluse car les processeurs non-validant ne sont pas tenus de les lire).]

Déclaration de document autonome

Dans une déclaration de document autonome, la valeur "yes" indique qu'il n'y a pas de déclarations de balisage externes 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 uniquement la présence de déclarations externes; dans un document, la présence de références à des entités externes ne change pas son status d'autonomie, lorsque ces entités sont déclarées dans le sous-ensemble interne.

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

Tout document XML pour lequel standalone="no" peut être converti algorithmiquement en un document autonome, ce qui peut être souhaitable pour des applications d'administration réseau.

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

<?xml version="1.0" standalone='yes'?>

2.10 Traitement de l'espace blanc

Lors de l'édition de documents XML, il est souvent commode d'utiliser de l'« espace blanc » (espaces, tabulations et interlignes) afin de distinguer le balisage et d'améliorer la lisibilité. Un tel espace blanc n'est pas typiquement destiné à être inclus dans la version livrée du document. En revanche, l'espace blanc « significatif » qui devrait être préservé dans la version livrée est courant, par exemple dans un poème ou un 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 validant DOIT également informer l'application desquels de ces caractères constituent l'espace blanc apparaissant dans du contenu élémentaire pur.

Un attribut spécial nommé xml:space peut être attaché à un élément pour signaler l'intention de préserver l'espace blanc dans cet élément par les applications. Dans les documents valides, cet attribut, comme tout autre, DOIT être déclaré s'il est utilisé. S'il est déclaré, il DOIT être définit de type énuméré, dont les seules valeurs admises sont "default" et "preserve". Par exemple :

<!ATTLIST poem  xml:space (default|preserve) 'preserve'>

<!ATTLIST pre xml:space (preserve) #FIXED 'preserve'>

La valeur "default" indique que les modes implicites de traitement d'espaces blancs sont acceptables pour cet élément; la valeur "preserve" indique que les applications préservent tous espaces blancs. Cette intention déclarée s'applique à tous les éléments dans le contenu de l'élément porteur de la déclaration, à moins qu'elle ne soit annulée par une autre instance de l'attribut xml:space. Cette spécification ne donne de sens à xml:space que pour les valeurs "default" et "preserve". C'est une erreur de spécifier d'autres valeurs; le processeur XML PEUT signaler l'erreur ou PEUT récupérer en ignorant la spécification d'attribut ou en signalant la valeur (erronée) à l'application. Les applications peuvent ignorer ou rejeter les valeurs erronées.

L'élément racine d'un document est considéré comme ayant signalé aucune intention concernant le traitement du blanc par l'application, sauf s'il fournit une valeur pour cet attribut, ou si l'attribut est déclaré avec une valeur par défaut.

2.11 Traitement des fins de ligne

Les entités analysables XML sont souvent enregistrées dans des fichiers, organisés en lignes afin d'en facilité la rédaction. Typiquement, ces lignes sont séparées par une combinaison de caractères CARRIAGE RETURN (#xD) et LINE FEED (#xA).

Pour simplifier les tâches des applications, le processeur XML DOIT se comporter comme s'il normalisait tous les sauts de ligne dans les entités externes analysables de l'entrée (y compris l'entité document), avant l'analyse, en traduisant la séquence des deux caractères #xD #xA et tout caractère #xD qui ne soit pas suivis par #xA, en un seul caractère #xA.

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 spécial, nommé xml:lang, peut être inséré dans les documents pour spécifier la langue utilisée dans les contenus et les valeurs d'attributs des éléments d'un document XML. Dans les documents valides, lorsque cet attribut est utilisé, il DOIT être déclaré, comme tout autre attribut. Les valeurs de l'attribut sont des identificateurs de langue définis par [IETF BCP 47], Tags for the Identification of Languages; de plus, la chaîne de caractères vide peut être spécifiée.

(Les productions 33 à 38 ont été supprimés.)

Par exemple :

<p xml:lang="en">The quick brown fox jumps over the lazy dog.</p>
<p xml:lang="en-GB">What colour is it?</p>
<p xml:lang="en-US">What color is it?</p>
<sp who="Faust" desc='leise' xml:lang="de">
  <l>Habe nun, ach! Philosophie,</l>
  <l>Juristerei, und Medizin</l>
  <l>und leider auch Theologie</l>
  <l>durchaus studiert mit heißem Bemüh'n.</l>
</sp>

La langue spécifiée par xml:lang s'applique à l'élément dans lequel elle est spécifiée (y compris les valeurs de ses attributs), et à tous les éléments de son contenu, à moins qu'il ne soit remplacé par une autre instance de xml:lang. En particulier, la valeur vide de xml:lang est utilisée dans un élément B pour remplacer une spécification de xml:lang d'un élément A enveloppant, sans spécifier une autre langue. Dans B, on considère qu'il n'existe aucune information de langue de disponible, comme si xml:lang n'avait pas été spécifié dans B ou l'un de ses ancêtres. Les applications déterminent quelles valeurs d'attribut d'un élément et quelles parties de son contenu textuel, sont traitées comme des valeurs dépendantes de la langue décrite par xml:lang.

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

xml:lang CDATA #IMPLIED

mais des valeurs par défaut spécifiques peuvent aussi être données, le cas échéant. Dans un recueil de poèmes français pour étudiants anglais, avec des gloses et des notes en anglais, l'attribut xml:lang pourrait être déclaré de cette façon :

<!ATTLIST poem   xml:lang CDATA 'fr'>
<!ATTLIST gloss  xml:lang CDATA 'en'>
<!ATTLIST note   xml:lang CDATA 'en'>

3.1 Balises d'ouverture, balises de fermeture et balises d'élément vide

[Définition : Le début de chaque élément XML non vide est marqué d'une balise d'ouverture.]

Balise d'ouverture

Le Name des balises d'ouverture et de fermeture spécifie le type de l'élément. [Définition : Les paires Name-AttValue font référence aux spécifications d'attribut de l'élément], [Définition : pour chaque paire, le Name désigne le nom de l'attribut], et [Définition : le contenu de AttValue (le texte entre les délimiteurs ' ou ") désigne la valeur de l'attribut.] Notez que l'ordre des spécifications d'attribut dans une balise d'ouverture ou une balise d'élément vide n'est pas significatif.

Exemple de balise d'ouverture :

<termdef id="dt-dog" term="dog">

[Définition : La fin de chaque élément qui commence par une balise d'ouverture DOIT être marqué d'une balise de fermeture contenant un nom qui renvoie au type de l'élément spécifié dans la balise d'ouverture :]

Balise de fermeture

Exemple de balise de fermeture :

</termdef>

[Définition : Le texte entre la balise d'ouverture et la balise de fermeture est appelé contenu de l'élément :]

Contenu des éléments

[Définition : Un élément sans contenu est dit être vide.] La représentation d'un élément vide est une balise d'ouverture immédiatement suivie d'une balise de fermeture, ou une balise d'élément vide. [Définition : Une balise d'élément vide prends une forme spéciale :]

Balises pour éléments vides

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 en utilisant le mot-clé EMPTY. À des fins d'interopérabilité, la balise d'élément vide DEVRAIT être utilisée, et DEVRAIT être utilisée seulement, pour les éléments qui ont été déclarés EMPTY.

Exemples d'éléments vides :

<IMG align="left"
 src="http://www.w3.org/Icons/WWW/w3c_home" />
<br></br>
<br/>

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

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

Les déclarations de type d'élément limitent habituellement les types d'élément qui peuvent apparaître comme fils de l'élément. 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'est fournie, mais ceci ne constitue pas une erreur.

[Définition : Une déclaration de type d'élément prend la forme :]

Déclarations de type d'élément

où le Name indique le type d'élément déclaré.

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

<!ELEMENT br EMPTY>
<!ELEMENT p (#PCDATA|emph)* >
<!ELEMENT %name.para; %content.para; >
<!ELEMENT container ANY>

<!ELEMENT spec (front, body, back?)>
<!ELEMENT div1 (head, (p | list | note)*, div2*)>
<!ELEMENT dictionary-body (%div.mix; | %dict.mix;)*>

<!ELEMENT p (#PCDATA|a|ul|b|i|em)*>
<!ELEMENT p (#PCDATA | %font; | %phrase; | %special; | %form;)* >
<!ELEMENT b (#PCDATA)>

3.3 Déclarations de liste d'attributs

Les attributs sont utilisés pour associer des pairs nom-valeur avec des éléments. Les spécifications d'attribut NE DOIVENT PAS apparaître en dehors des balises d'ouvertures et des balises d'élément vide; ainsi, les productions utilisées pour les reconnaître apparaissent dans 3.1 Balises d'ouverture, balises de fermeture et balises d'élément vide. Les déclarations de liste d'attributs peuvent être utilisées pour :

• 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 par défault pour des attributs.

[Définition : Les déclarations de liste d'attributs spécifient le nom, le type de données, et la valeur par défault (le cas échéant) de chaque attribut associé à un type d'élément donné :]

Déclaration de liste d'attributs

Dans la règle AttlistDecl, Name est le type d'un élément. Au choix de l'utilisateur, un processeur XML PEUT envoyer un avertissement si des attributs sont déclarés pour un type d'élément non déclaré, mais ceci ne constitue pas une erreur. Dans la règle AttDef, Name est le nom de l'attribut.

Quand plus d'une AttlistDecl 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 la DTD peuvent choisir de fournir au plus une déclaration de liste d'attributs pour un type d'élément donné, au plus 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. À des fins d'interopérabilité, un processeur XML PEUT au gré de l'utilisateur envoyer 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.

<!ATTLIST termdef
          id      ID      #REQUIRED
          name    CDATA   #IMPLIED>
<!ATTLIST list
          type    (bullets|ordered|glossary)  "ordered">
<!ATTLIST form
          method  CDATA   #FIXED "POST">

<!ENTITY d "&#xD;">
<!ENTITY a "&#xA;">
<!ENTITY da "&#xD;&#xA;">

a="xyz"

x y z

#x20 #x20 x y z

a="&d;&d;A&a; &a;B&da;"

A #x20 B

#x20 #x20 A #x20 #x20 #x20 B #x20 #x20

a="

A

B
"

#xD #xD A #xA #xA B #xD #xA

#xD #xD A #xA #xA B #xD #xA

3.4 Sections conditionnelles

[Définition : Les sections conditionnelles sont des portions du sous-ensemble externe de la déclaration de type de document ou des entités paramètres externes qui sont incluses dans, ou excluses de, la structure logique de la DTD suivant le mot-clé qui les régissent.]

Section conditionnelle

Comme les sous-ensembles interne et externe de la DTD, une section conditionnelle peut contenir une ou plusieurs déclarations complètes, des commentaires, des instructions de traitement ou des sections conditionnelles imbriquées, entremêlées avec des espaces blancs.

Si le mot-clé d'une section conditionnelle est INCLUDE, alors le contenu de la section conditionnelle DOIT être traitée comme une partie de la DTD. Si le mot-clé de la section conditionnelle est IGNORE alors le contenu de la section conditionnelle NE DOIT PAS être traitée comme une partie de la DTD. Si une section conditionnelle marquée du mot-clé INCLUDE se trouve dans une section conditionnelle plus importante avec un mot-clé IGNORE, les sections conditionnelles intérieure et extérieure DOIVENT être ignorées. Le contenu d'une section conditionnelle ignorée DOIT être analysé en ignorant tous caractères après le "[" suivant le mot-clé, excepter une section conditionnelle qui commence par "<![" et se termine par "]]>", jusqu'à ce que la fin de la section conditionnelle correspondante soit trouvée. Les références d'entité paramètre NE DOIVENT PAS être reconnues par ce traitement.

Si le mot-clé d'une section conditionnelle est une référence d'entité paramètre, l'entité paramètre DOIT être remplacée par son contenu avant que le processeur ne décide s'il doit inclure ou ignorer la section conditionnelle.

Un exemple :

<!ENTITY % draft 'INCLUDE' >
<!ENTITY % final 'IGNORE' >

<![%draft;[
<!ELEMENT book (comments*, title, body, supplements?)>
]]>
<![%final;[
<!ELEMENT book (title, body, supplements?)>
]]>

4.1 Références de caractère et d'entité

[Définition : Une référence 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 directement à l'aide d'un clavier.]

Référence de caractère

Si une référence de caractère commence par « &#x », alors les chiffres et les lettres, jusqu'au terminateur ;, fournissent une représentation hexadécimale du point de code du caractère dans l'ISO/CEI 10646. Si elle commence seulement par « &# », alors les chiffres jusqu'au terminateur ;, fournissent une représentation décimale du point de code du caractère.

[Définition : Une référence d'entité fait référence au contenu d'une entité nommée.] [Définition : Les délimiteurs des références à des entités générales analysables sont l'esperluette (&) et le point-virgule (;).] [Définition : Les délimiteurs des références d'entités paramètres sont le caractère pour cent (%) et le point-virgule (;).]

Référence d'entité

Exemples de références de caractère et de références d'entité :

Type <key>less-than</key> (&#x3C;) to save options.
This document was prepared on &docdate; and
is classified &security-level;.

Exemple de références d'entité paramètre :

<!-- declare the parameter entity "ISOLat2"... -->
<!ENTITY % ISOLat2 SYSTEM "http://www.xml.com/iso/isolat2-xml.entities" >
<!-- ... now reference it. -->
%ISOLat2;

4.2 Déclarations d'entités

[Définition : Les entités sont déclarées de la façon suivante :]

Déclarations d'entités

Le Name identifie l'entité dans une référence 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 rencontrée est liée; au gré de l'utilisateur, un processeur XML PEUT alors émettre un avertissement si des entités sont déclarées plusieurs fois.

<!ENTITY Pub-Status "This is a pre-release of the specification.">

<!ENTITY open-hatch
         SYSTEM "http://www.textuality.com/boilerplate/OpenHatch.xml">
<!ENTITY open-hatch
         PUBLIC "-//Textuality//TEXT Standard open-hatch boilerplate//EN"
         "http://www.textuality.com/boilerplate/OpenHatch.xml">
<!ENTITY hatch-pic
         SYSTEM "../grafix/OpenHatch.gif"
         NDATA gif >

4.3 Entités analysables

<?xml encoding='UTF-8'?>
<?xml encoding='EUC-JP'?>

4.4 Traitement des entités et des références par un processeur XML

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

Référence dans le contenu

une référence n'importe où après la balise d'ouverture et avant la balise de fermeture d'un élément; correspond au non-terminal contenu.

Référence dans une valeur d'attribut

une référence dans la valeur d'un attribut dans une balise ouvrante, ou dans une valeur par défaut dans une déclaration d'attribut; correspond au non-terminal AttValue.

Valeur d'attribut

un Name, et non pas une référence, apparaissant comme la valeur d'un attribut qui a été déclaré de type ENTITY, ou comme un des membres (séparés par des espaces) de la valeur d'un attribut qui a été déclaré de type ENTITIES.

Référence dans une valeur d'entité

une référence dans la valeur littérale d'entité d'une entité paramètre ou interne dans la déclaration d'entité correspond au non-terminal EntityValue.

Référence dans la DTD

une référence dans les sous-ensembles interne ou externe de la DTD, mais en-dehors de EntityValue, AttValue, PI, Comment, SystemLiteral, PubidLiteral, ou du contenu d'une section conditionnelle ignorée (voir 3.4 Sections conditionnelles).

<!ENTITY % YN '"Yes"' >
<!ENTITY WhatHeSaid "He said %YN;" >

<!ENTITY EndAttr "27'" >
<element attribute='a-&EndAttr;>

4.5 Construction du texte de remplacement d'une entité

En faisant état du traitement des entités internes, il convient de distinguer deux formes de la valeur de l'entité. [Définition : Pour une entité interne, 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 EntityValue.] [Définition : Pour une entité externe, la valeur littérale d'entité est le texte exacte contenu dans l'entité.] [Définition : Pour une entité interne, le texte de remplacement est le contenu de l'entité, après remplacement des références de caractère et des références d'entités paramétrées.] [Définition : Pour une entité externe, le texte de remplacement est le contenu de l'entité, après décapage de la déclaration de texte (en laissant tout l'espace blanc l'encadrant) s'il en existe un mais sans le remplacement des références de caractères ou des références d'entité paramétre.]

La valeur littérale d'entité telle que donnée dans une déclaration d'entité interne (EntityValue) peut contenir des références de caractère, d'entité paramètre et d'entité générale. De telles références DOIVENT être entièrement contenues dans la valeur littérale d'entité. FIXME Le texte de remplacement qui est inclus (ou inclus dans le littérale) tel que décrit ci-dessus DOIT contenir le texte de remplacement de toute référence d'entité paramètre, ainsi DOIT contenir le caractère FIXME toutefois, les références d'entité générale DOIVENT être laissées telles quelles, sans remplacement. Par exemple, étant donné les déclarations suivantes :

<!ENTITY % pub    "&#xc9;ditions Gallimard" >
<!ENTITY   rights "All rights reserved" >
<!ENTITY   book   "La Peste: Albert Camus,
&#xA9; 1947 %pub;. &rights;" >

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

La Peste: Albert Camus,
© 1947 Éditions Gallimard. &rights;

La référence d'entité générale « &rights; » sera développée si la référence « &book; » 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, voir D Développement des références d'entité et de caractère .

4.6 Entités prédéfinies

[Définition : Les références d'entité ou de caractère peuvent être utilisées pour échapper le caractère inférieur-à, l'esperluette et d'autres délimiteurs. Un ensemble d'entités générales (amp, lt, gt, apos, quot) est défini à cette fin. Les références numériques de caractère peuvent aussi être utilisées; elles sont développées dès que reconnues et DOIVENT être traitées comme des données textuelles, de sorte que les références numériques de caractère « < » et « & » peuvent être utilisés pour échapper < et & lorsqu'elles apparaissent dans une donnée textuelle.]

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 leur utilisation. Si les entités lt ou amp sont déclarées, elles DOIVENT être déclarées comme des entités internes dont le texte de remplacement est une référence de caractère au caractère respectif (inférieur à ou esperluette) à échapper; le double échappement est REQUIS pour ces entités afin que les références sur elles produisent un résultat bien formé. Si les entités gt, apos, ou quot sont déclarées, elles DOIVENT être déclarées comme des entités internes dont le texte de remplacement est un seul caractère à échapper (ou une référence de caractère à un caractère; le double échappement est ici OPTIONNEL mais inoffensif). Par exemple :

<!ENTITY lt     "&#38;#60;">
<!ENTITY gt     "&#62;">
<!ENTITY amp    "&#38;#38;">
<!ENTITY apos   "&#39;">
<!ENTITY quot   "&#34;">

4.7 Déclarations de notation

[Définition : Une notation identifiée par un nom le format d'une entité non-analysable, le format des éléments qui portent un attribut de notation, ou l'application à laquelle une instruction de traitement est adressée.]

[Définition : Une déclaration de notation fournit, d'une part, un nom à la notation, à utiliser dans les déclarations d'entité, les déclarations de liste d'attributs et les spécifications d'attribut; d'autre part, un identificateur externe de la notation qui peut permettre à un processeur XML, ou son application cliente, de localiser une application d'aide capable de traiter les données de cette notation.]

Les processeurs XML DOIVENT fournir aux applications les nom et identificateur(s) externe(s) 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é. Ils PEUVENT aussi transformer l'identificateur externe en un identificateur système, un nom de fichier, ou toute autre information nécessaire pour permettre à l'application d'appeler un processeur pour les données dans la notation décrite. (Toutefois, il n'y a pas erreur lorsque des documents XML déclarent et se référent à des notations pour lesquelles des applications idoines ne sont pas disponibles sur le système où le processeur XML ou l'application est en fonctionnement).

4.8 L'entité document

[Définition : L'entité document sert de racine à l'arbre des entités et de point de départ au processeur XML.] Cette spécification ne précise pas comment l'entité document est localisée par un processeur XML; contrairement aux autres entités, l'entité document n'a pas de nom et peut fort bien apparaître dans le flux d'entrée d'un processeur sans la moindre identification.

5.1 Processeurs validant et non-validant

Les processeurs XML conformes sont validant ou non-validant.

Les processeurs validant et non-validant DOIVENT signaler les violations de contraintes de forme de cette spécification dans le contenu de l'entité document et de toute autre entité analysable qu'ils lisent.

[Définition : Les processeurs validatants DOIVENT, 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 cette spécification.] Pour ce faire, les processeurs XML validant DOIVENT lire et traiter la DTD complète ainsi que toutes les entités analysables externes mentionnées dans le document.

Les processeurs non-validant sont tenus de vérifier uniquement la forme de l'entité document, y compris le sous-ensemble interne de la DTD complet. [Définition : Bien qu'ils ne soient pas tenus de vérifier la validité du document, ils sont TENUS de traiter toutes les déclarations qu'ils lisent dans le sous-ensemble interne de la DTD ainsi que dans toute entité paramètre qu'ils lisent, jusqu'à la première référence à une entité paramètre qu'ils ne lisent pas; c'est-à-dire, qu'ils DOIVENT utiliser l'information de 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 une référence d'entité paramètre qui n'est pas lu, puisque l'entité peut contenir des déclarations contradictoires; lorsque standalone="yes", les processeurs DOIVENT traiter ces déclarations.

Notez que lors du traitement de documents non valides avec un processeur non validant, l'application ne peut pas être présentée avec une information cohérente. Par exemple, plusieurs exigences d'unicité peuvent ne pas être respectées dans le document, telles que l'inclusion de plus d'un élément avec le même id, la duplication de déclarations d'éléments ou de notations avec le même nom, etc.

5.2 Utilisation des processeurs XML

Le comportement d'un processeur XML validant est éminemment prévisible; il doit lire chaque parties d'un document et signaler toutes les violations de contrainte de forme et de validité. On est moins exigeant avec un processeur non-validant, qui n'a besoin 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 Entity Declared, Parsed Entity et No Recursion, ainsi que quelques cas décrits comme interdit dans 4.4 Traitement des entités et des références 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. Par exemple, un processeur non-validant 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, où cela dépend de la lecture préalable des déclarations dans les entités externes ou paramètres, ou dans le sous-ensemble interne après une référence d'entité paramètre non lue.

Afin d'optimiser l'interopérabilité entre différents processeurs XML, les applications qui utilisent des processeurs non-validant NE DEVRAIENT PAS se fier à des comportements facultatifs de tels processeurs. Les applications qui nécessitent des fonctions (comme la déclaration de valeurs par défaut d'attribut et des entités internes qui sont ou peuvent être spécifiées dans des entités externes) DEVRAIENT utiliser des processeurs validant.