1.1 L'origine et les buts

XML a été développé par un groupe de travail XML (connu à l'origine sous le nom de Conseil de révision éditoriale SGML) formé sous les auspices du World Wide Web Consortium (W3C) en 1996. Il était présidé par Jon Bosak de Sun Microsystems avec la participation active d'un groupe d'intérêts particuliers XML (connu précédemment sous le nom de groupe de travail SGML), également sous l'égide du W3C. La composition du groupe de travail XML est donnée en annexe. Dan Connolly était le contact du groupe de travail auprès du W3C.

Les objectifs déterminant la conception de XML sont :

1. XML devra être directement utilisable sur l'internet.

2. XML devra reconnaître une grande variété d'applications.

3. XML devra être compatible avec SGML.

4. L'écriture des programmes de traitement des documents XML devra être aisée.

5. Le nombre des caractéristiques optionnelles dans XML devra être tenu au strict minimum, idéalement à zéro.

6. Les documents XML devraient être lisibles par un humain et raisonnablement clairs.

7. La conception de XML devrait être préparée rapidement.

8. La conception de XML devra être formelle et concise.

9. Les documents XML devront être faciles à créer.

10. La concision dans le balisage XML est de peu d'importance.

Cette spécification, en même temps que des standards associés (Unicode [Unicode] et ISO/IEC 10646 [ISO/IEC 10646] pour les caractères, le document RFC 3066 [IETF RFC 3066] pour les étiquettes d'identification de langue, ISO 639 [ISO 639] pour les codes de nom de langue et ISO 3166 [ISO 3166] pour les codes de nom de pays), fournit toutes les informations nécessaires pour comprendre XML version 1.1 et construire des logiciels pour l'interpréter.

La distribution de cette version de la spécification XML est libre, tant que le texte et les avis légaux restent intacts.

1.2 La terminologie

La terminologie employée pour décrire les documents XML est définie dans le corps de cette spécification. Les mots-clés DOIT (DOIVENT), NE DOIT (DOIVENT) PAS, OBLIGATOIRE, DEVRA (DEVRONT), NE DEVRA (DEVRONT) PAS, DEVRAIT (DEVRAIENT), NE DEVRAIT (DEVRAIENT) PAS, RECOMMANDÉ, PEUT (PEUVENT) et OPTIONNEL, quand ils sont MIS EN EXERGUE ainsi, doivent s'interpréter comme décrit dans le document [IETF RFC 2119]. En outre, les termes définis dans la liste suivante entrent dans ces définitions et décrivent le fonctionnement d'un processeur XML :

erreur

[Définition : Une violation des règles de cette spécification ; les résultats ne sont pas définis. Sauf indiqué autrement, le non respect d'une prescription de cette spécification, signalée par l'un des mots-clés DOIT, OBLIGATOIRE, NE DOIT PAS, DEVRA et NE DEVRA PAS, constitue une erreur. Un logiciel conforme PEUT détecter et signaler une erreur, et PEUT récupérer de celle-ci.]

erreur fatale

[Définition : Une erreur qu'un processeur XML DOIT détecter et signaler à l'application. Face à une erreur fatale, le processeur PEUT continuer le traitement des données à la recherche d'autres erreurs et PEUT signaler celles-ci à l'application. Pour une prise en charge de la correction des erreurs, le processeur PEUT mettre à la disposition de l'application des données non traitées issues du document (données textuelles et balisage entremêlés). Toutefois, dès qu'une erreur fatale est détectée, le processeur NE DOIT PAS poursuivre le traitement normal (c'est-à-dire, il NE DOIT PAS continuer à passer des données textuelles et des informations concernant la structure logique du document à l'application de façon normale).]

au gré de l'utilisateur

[Définition : Un logiciel conforme PEUT ou DOIT (selon le verbe modal dans la phrase) se comporter comme indiqué ; s'il le fait, alors il DOIT fournir à l'utilisateur le moyen d'activer ou de désactiver le comportement décrit.]

contrainte de validité (CV)

[Définition : Une règle qui s'applique à tous les documents XML valides. Les violation des contraintes de validité constituent des erreurs ; elles DOIVENT, au gré de l'utilisateur, être signalées par les processeurs XML validants.]

contrainte de forme (CF)

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

correspondance

[Définition : (... de chaînes ou de noms :) Deux chaînes de caractères ou deux noms soumis à comparaison DOIVENT être identiques. Les caractères avec plusieurs représentations possibles dans Unicode (par exemple, les caractères ayant à la fois une forme précomposée et une forme de base plus diacritique) ne correspondent que s'ils ont la même représentation dans les deux chaînes. Aucun changement de casse n'intervient. (... de chaînes et de règles dans la grammaire :) Une chaîne correspond à une production grammaticale si elle appartient au langage généré par cette production. (... de contenu et de modèles de contenu :) Un élément correspond à sa déclaration lorsqu'il est conforme, selon les conditions décrites dans la contrainte [CV : Validité de l'élément].]

pour des raisons de compatibilité

[Définition : Marque une phrase décrivant une caractéristique de XML incluse seulement pour faire en sorte que XML reste compatible avec SGML.]

pour des raisons d'interopérabilité

[Définition : Marque une phrase décrivant une recommandation de non-liaison, incluse pour tenir compte de la base installée des processeurs SGML, occupant l'annexe des adaptations WebSGML de ISO 8879, afin d'augmenter les probabilités que ceux-ci puissent traiter les documents XML.]

1.3 Les justifications et la liste des changements en faveur de XML 1.1

La première parution de la recommandation XML 1.0 du W3C a eu lieu en 1998 et, en dépit de nombreux errata aboutissant à la troisième édition de 2004, elle est restée (volontairement) inchangée pour ce qui est de dire si un document XML est bien formé ou non. Cette stabilité a été extrêmement profitable en ce qui concerne l'interopérabilité. Cependant, le standard Unicode, sur lequel XML 1.0 s'appuie pour les spécifications de caractère, n'est pas resté statique, en évoluant d'une version 2.0 à une version 4.0 et plus. Les caractères absent d'Unicode 2.0 peuvent déjà être utilisés dans les données textuelles XML 1.0. Par contre, ils ne sont pas admis dans les noms XML tels que les noms de type d'élément, les noms d'attribut, les valeurs d'attribut énumérées, les cibles d'instruction de traitement et ainsi de suite. En outre, certains caractères qui auraient dû être permis dans les noms XML ne le furent pas, en raison des omissions et des incohérences dans Unicode 2.0.

La philosophie d'ensemble des noms a changé depuis XML 1.0. Tandis que XML 1.0 offrait une définition des noms rigide, selon laquelle tout ce qui n'était pas permis était interdit, les noms XML 1.1 sont conçus de telle sorte que tout ce qui n'est pas interdit (pour une raison particulière) est permis. Comme Unicode continuera d'évoluer après la version 4.0, on peut éviter des changements ultérieurs à XML en autorisant tous les caractères, y compris ceux non encore assignés, dans les noms.

En outre, XML 1.0 essaye de s'adapter aux conventions de fin de ligne des divers systèmes d'exploitation modernes, mais établit une distinction entre les conventions suivies par les ordinateurs centraux IBM et compatibles IBM. En conséquence, les documents XML dans les ordinateurs centraux ne sont pas, selon les conventions locales, des fichiers de texte brut. Les documents XML 1.0 générés par ces ordinateurs centraux doivent donc soit violer les conventions de fin de ligne locales, soit suivre des étapes de conversion indûment nécessaires avant analyse et après génération. Permettre une interopérabilité directe revêt une importance particulière quand des magasins de données sont partagés entre des systèmes centraux et non centraux (et non copiés de l'un à l'autre). C'est pourquoi XML 1.1 ajoute le caractère NEL #x85 à la liste des caractères de fin de ligne. Par souci d'exhaustivité, le caractère de séparation de ligne Unicode #x2028 est également pris en compte.

Finalement, une demande considérable existe afin de définir une représentation standard pour des caractères Unicode arbitraires dans les documents XML. C'est pourquoi XML 1.1 autorise l'utilisation d'appels de caractère vers les caractères de contrôle #x1 à #x1F, la plupart de ceux-ci étant interdits dans XML 1.0. Cependant, pour des questions de fiabilité, on ne peut toujours pas utiliser directement ces caractères dans les documents. Afin de renforcer la fiabilité de la détection du codage des caractères, les caractères de contrôle supplémentaires #x7F à #x9F, qui était permis dans les documents XML 1.0, doivent maintenant n'apparaître que comme appels de caractère. (Les caractères blancs en sont bien entendu exemptés.) Le sacrifice mineur de la rétrocompatibilité n'est pas considéré comme significatif. À cause de problèmes potentiels avec les API, l'utilisation du caractère #x0, directe et comme appel de caractère, est toujours interdite.

En fin de compte, XML 1.1 définit un ensemble de contraintes, appelé normalisation complète, sur les documents XML, auxquelles les créateurs de document DEVRAIENT adhérer et que les processeurs de document DEVRAIENT vérifier. L'utilisation de documents complètement normalisés assure que les comparaisons à l'identité des noms, des valeurs d'attribut et du contenu textuel puisse se faire correctement par simple comparaison binaire de chaînes Unicode.

Au lieu de créer un ensemble d'errata pour XML 1.0, on a choisi de faire une nouvelle version XML car les changements affectent la définition des document bien formés. Les processeur XML 1.0 doivent continuer à rejeter les documents qui contiennent les nouveaux caractères dans les noms XML, les nouvelles conventions de fin de ligne et les appels de caractères de contrôle. La distinction entre documents XML 1.0 et XML 1.1 est indiquée par l'information de numéro de version dans la déclaration XML au début de chaque document.

2.1 Les documents XML bien formés

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

1. Considéré globalement, il correspond à la production document.

2. Il satisfait à toutes les contraintes de bonne forme données dans cette spécification.

3. Chacune des entités analysables appelées directement ou indirectement dans le document est bien formée.

Le document

Une correspondance avec la production document implique que :

1. L'objet contient un ou plusieurs éléments.

2. [Définition : Il existe exactement un seul élément, appelé racine ou élément document, dont aucune partie n'apparaît dans le contenu d'un quelconque autre élément.] Pour tous les autres éléments, si la balise ouvrante se trouve dans le contenu d'un autre élément, alors la balise fermante se trouve aussi dans le contenu du même élément. Dit plus simplement, les éléments, délimités par des balises ouvrantes et fermantes, s'imbriquent correctement les uns dans les autres.

[Définition : En conséquence, pour chaque élément non-racine E dans le document, il existe un seul autre élément P dans le document, tel que E se trouve dans le contenu de P, mais pas dans le contenu d'un quelconque autre élément dans le contenu de P. L'élément P est dit parent de E, et E est dit enfant de P.]

2.2 Les caractères

[Définition : Une entité analysable contient du texte, une séquence de caractères qui peuvent représenter un balisage ou des données textuelles.] [Définition : Un caractère est une unité de texte atomique comme spécifié par la norme ISO/IEC 10646 [ISO/IEC 10646]. Les caractères légaux comprennent les caractères tabulation, retour chariot, saut de ligne et les caractères légaux de Unicode et ISO/IEC 10646. Les versions de ces standards cités au chapitre A.1 Références normatives étaient celles courantes au moment de la préparation de ce document. De nouveaux caractères peuvent venir s'ajouter à ces standards au travers d'amendements ou par de nouvelles éditions. Par conséquent, les processeurs XML DOIVENT accepter tous les caractères de l'étendue spécifiée pour la production Car.]

L'étendue de caractères

Le mécanisme du codage des points de code de caractère vers des formes binaires PEUT varier d'une entité à l'autre. Tous les processeurs XML DOIVENT accepter les codages Unicode UTF-8 et UTF-16 [Unicode]. Les mécanismes pour signaler lequel des deux est employé, ou pour faire intervenir d'autres codages, sont abordés plus loin au chapitre 4.3.3 Le codage des caractères dans les entités.

[#x7F-#x84], [#x86-#x9F], [#xFDD0-#xFDDF],
[#1FFFE-#x1FFFF], [#2FFFE-#x2FFFF], [#3FFFE-#x3FFFF],
[#4FFFE-#x4FFFF], [#5FFFE-#x5FFFF], [#6FFFE-#x6FFFF],
[#7FFFE-#x7FFFF], [#8FFFE-#x8FFFF], [#9FFFE-#x9FFFF],
[#AFFFE-#xAFFFF], [#BFFFE-#xBFFFF], [#CFFFE-#xCFFFF],
[#DFFFE-#xDFFFF], [#EFFFE-#xEFFFF], [#FFFFE-#xFFFFF],
[#10FFFE-#x10FFFF].

2.3 Les structures syntaxiques communes

Ce chapitre définit quelques symboles employés couramment dans la grammaire.

La production S (les caractères blancs) consiste en un ou plusieurs caractères espace #x20, retour chariot, saut de ligne ou tabulation.

Les caractères blancs

[Définition : Un type Nom (nom) représente une unité lexicale commençant par une lettre ou par un caractère issus d'un groupe de quelques caractères de ponctuation, continuant par des lettres, des chiffres, des caractères tiret (-), souligné (_), deux-points (:) ou point (.), appelés collectivement caractères de nom.] Les noms commençant par la chaîne xml, ou par toute chaîne qui correspondrait à (('X'|'x') ('M'|'m') ('L'|'l')), sont réservés à la standardisation dans cette spécification ou dans les versions futures de celle-ci.

Un type AtomeNml (nom d'unité lexicale) se compose d'un mélange quelconque de caractères de nom.

Le premier caractère d'une valeur de type Nom DOIT être du type CarNomInit et tous les autres caractères DOIVENT être du type CarNom. Ce mécanisme est destiné à prévenir les noms commençant par un chiffre (ASCII) ou par des caractères combinants de base. Presque tous les caractères sont autorisés dans les noms, sauf ceux qui font (ou pourraient faire) office de délimiteurs. On veut rester inclusif plutôt qu'exclusif, de sorte que les systèmes d'écriture qui ne sont pas encore codés dans Unicode puissent être utilisés dans les noms XML. Voir l'annexe I Les suggestions de noms XML qui donne des pistes pour la création des noms.

Les auteurs de documents sont invités, en ce qui concerne les noms, à employer des mots ou combinaisons de mots dans la langue naturelle qui soient significatifs et à éviter les caractères symboliques ou blancs. Remarquez que les caractères DEUX-POINTS, TRAIT D'UNION-SIGNE MOINS, POINT, SOULIGNÉ et POINT MÉDIAN sont explicitement autorisés.

Les symboles et marques de ponctuation ASCII, ainsi qu'un groupe conséquent de caractères symboliques Unicode, sont exclus de la composition des noms parce qu'ils sont plus utiles comme délimiteurs quand les noms XML sont employés hors des documents XML ; ce groupe apporte, dans ces contextes, une garantie solide concernant ce qui ne peut pas faire partie d'un nom XML. Le caractère POINT D'INTERROGATION GREC (érotimatiko) #x037E est aussi exclus parce que, une fois normalisé, il devient un point-virgule, ce qui pourrait changer la signification d'un appel d'entité.

Les noms et unités lexicales

Une donnée littérale est une chaîne entre guillemets quelconque ne contenant pas le guillemet employé comme délimiteur pour cette chaîne. Les littéraux s'emploient pour spécifier le contenu des entités internes (ValeurEntité), les valeurs d'attribut (ValeurAtt) et les identificateurs externes (LittéralSystème). Remarquez qu'une valeur de type LittéralSystème peut être analysée sans pour autant donner lieu à la recherche d'un balisage.

Les littéraux

2.4 Les données textuelles et le balisage

Le texte est un mélange composé de données textuelles et de balisage. [Définition : Le balisage se compose de balises ouvrantes, de balises fermantes, de balises d'élément vide, d'appels d'entité, d'appels de caractère, de commentaires, de délimiteurs de section de type CDATA, de déclarations de type de document, d'instructions de traitement, de déclarations XML, de déclarations de texte et de tout blanc se trouvant au niveau supérieur de l'entité document (c'est-à-dire, en dehors de l'élément document et à l'extérieur de tout autre balisage).]

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

Les caractères esperluette (&) et inférieur à (<) NE DOIVENT PAS apparaître dans leur forme littérale, sauf comme délimiteurs de balisage ou à l'intérieur d'un commentaire, d'une instruction de traitement ou d'une section de type CDATA. Si leur présence est requise ailleurs, ils DOIVENT être échappés en utilisant soit des appels de caractère numériques, soit, respectivement, les chaînes & et <. Le caractère supérieur à (>) PEUT être représenté par la chaîne >, et DOIT, pour des raisons de compatibilité, être échappé en utilisant soit la chaîne >, soit un appel de caractère, quand il apparaît dans la chaîne ]]> dans un contenu, si cette chaîne ne marque pas la fin d'une section de type CDATA.

Dans le contenu des éléments, toute chaîne de caractères ne contenant pas le délimiteur d'ouverture d'un balisage quelconque ni le délimiteur de clôture de section CDATA ]]> est une donnée textuelle. Dans une section de type CDATA, toute chaîne de caractères ne contenant pas le délimiteur de clôture de section CDATA est une donnée textuelle.

Afin de permettre aux valeurs d'attribut de contenir des guillemets simples et doubles, on PEUT représenter le caractère apostrophe ou guillemet simple (') par la chaîne ' et le caractère guillemet double (") par ".

Les données textuelles

2.5 Les commentaires

[Définition : Les commentaires PEUVENT apparaître n'importe où dans un document, en dehors d'un autre balisage. Ils PEUVENT en outre apparaître au sein de 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, sans y être obligé, mettre le texte des commentaires à la disposition d'une application. Pour des raisons de compatibilité, la chaîne -- (deux tirets) NE DOIT PAS apparaître au sein d'un commentaire.] Les appels d'entité paramètre NE DOIVENT PAS être interprétés au sein des commentaires.

Les commentaires

Exemple de commentaire :

<!-- déclarations des éléments <head> & <body> -->

Remarquez que la grammaire ne permet pas qu'un commentaire se termine par la chaîne --->. L'exemple qui suit n'est pas bien formé.

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

2.6 Les instructions de traitement

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

Les instructions de traitement

Les instructions de traitement ne font pas partie des données textuelles du document, mais elles DOIVENT être transmises à l'application. L'instruction de traitement commence par une cible (CibleIT) qui identifie l'application visée par l'instruction. Les noms de cible XML, xml et similaires sont réservés à la standardisation dans cette spécification ou dans les versions futures de celle-ci. On PEUT utiliser le mécanisme XML Notation pour la déclaration formelles des cibles des instructions de traitement. Les appels d'entité paramètre NE DOIVENT PAS être interprétés au sein des instructions de traitement.

2.7 Les sections de type CDATA

[Définition : Les sections de type CDATA PEUVENT apparaître partout où les données textuelles le peuvent. On les utilise pour échapper des blocs de texte contenant des caractères qui, sinon, serait interprétés comme du balisage. Les sections de type CDATA commencent par la chaîne <![CDATA[ et se terminent par la chaîne ]]> :]

Les sections de type CDATA

Au sein d'une section de type CDATA, seule la chaîne FinDT est interprétée comme étant du balisage, de sorte que les caractères esperluette et inférieur à peuvent y apparaître sous leur forme littérale. Il n'est pas nécessaire (et c'est impossible) de les échapper en utilisant les chaînes < et &. Les sections de type CDATA ne peuvent pas s'imbriquer.

Voici un exemple de section de type CDATA, dans lequel les chaînes <salutation> et </salutation> sont reconnues comme données textuelles, non comme balisage :

<![CDATA[<salutation>Salut à tous !</salutation>]]>

2.8 Le prologue et la déclaration de type de document

[Définition : Les documents XML 1.1 DOIVENT commencer par une déclaration XML qui spécifie la version XML utilisée.] Par exemple, voici un document XML 1.1 entier, bien formé mais pas valide :

<?xml version="1.1"?>
<salutation>Salut à tous !</salutation>

Par contre, le suivant est un document XML 1.0 car il n'a pas de déclaration XML :

<salutation>Salut à tous !</salutation>

Dans un document XML, la fonction du balisage consiste à décrire son classement et sa structure logique et d'associer des couples nom d'attribut/valeur à cette structure logique. XML fournit un mécanisme, la déclaration de type de document, afin de définir des contraintes sur la structure logique et gérer l'utilisation d'unités de stockage prédéfinies. [Définition : Un document XML est valide si une déclaration de type de document lui est associée et si le document satisfait aux contraintes qui y sont exprimées.]

La déclaration de type de document DOIT précéder le premier élément dans le document.

Le prologue

[Définition : La déclaration de type de document XML contient ou désigne des déclarations de balisage qui fournissent la grammaire d'une classe de document. Cette grammaire est connue sous le nom de définition de type de document (DTD). La déclaration de type de document peut pointer vers un sous-ensemble externe (une sorte d'entité externe particulière), contenant des déclarations de balisage, ou peut contenir directement les déclarations de balisage dans un sous-ensemble interne, ou encore les deux. Le DTD d'un document consiste en la réunion des deux sous-ensembles.]

[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, toutes ou en partie, dans des entités paramètres, comme décrit dans les contraintes de forme et de validité ci-dessous. Pour des précisions, voir le chapitre 4 Les structures physiques.

La définition de type de document

Remarquez qu'il est possible de construire un document bien formé ayant une valeur de type déclTypeDoc qui ne pointe ni vers un sous-ensemble externe ni ne contient de sous-ensemble interne.

Les déclarations de balisage PEUVENT être complétées par tout ou partie du texte de remplacement des entités paramètres. Plus loin dans la spécification, les productions des non-terminaux individuels (déclÉlément, DéclListeAtt, etc.) décrivent les déclarations après que toutes les entités paramètres ont été incorporées.

Les appels d'entité paramètre sont interprétés partout dans le DTD (dans les sous-ensembles interne et externe, et dans les entités paramètres externes), sauf dans les littéraux, les instructions de traitement, les commentaires et le contenu des sections conditionnelles ignorées (voir le chapitre 3.4 Les sections conditionnelles). Elles sont aussi interprétées dans les valeurs d'entité littérales. L'utilisation des entités paramètres dans le sous-ensemble interne est contrôlée, comme décrit ci-dessous.

Comme pour le sous-ensemble interne, le sous-ensemble externe et toutes les entités paramètres externes appelés dans une valeur de type SépDécl DOIVENT se composer d'une suite de déclarations de balisage complètes dans les types admis par le symbole non-terminal déclBalisage, entrecoupées de caractères blancs ou d'appels d'entité paramètre. Toutefois, des parties des contenus du sous-ensemble externe ou de ces entités paramètres externes PEUVENT être conditionnellement ignorées en utilisant une structure de section conditionnelle. Ce n'est pas permis dans le sous-ensemble interne, ça l'est par contre dans les entités paramètres externes appelées dans le sous-ensemble interne.

Le sous-ensemble externe

Le sous-ensemble externe et les entités paramètres externes diffèrent également du sous-ensemble interne en cela que les appels d'entité paramètres sont permis au sein des déclarations de balisage, et pas seulement entre celles-ci.

Voici un exemple de document XML avec une déclaration de type de document :

<?xml version="1.1"?>
<!DOCTYPE salutation SYSTEM "salut.dtd">
<salutation>Salut à tous !</salutation>

L'identificateur de système salut.dtd comporte l'adresse (une adresse URI) d'un DTD pour le document.

Les déclarations peuvent aussi être locales, comme dans cet exemple :

<?xml version="1.1" encoding="UTF-8" ?>
<!DOCTYPE salutation [
<!ELEMENT salutation (#PCDATA)>
]>
<salutation>Salut à tous !</salutation>

Si les deux sous-ensembles interne et externe sont utilisés, alors on DOIT considérer le sous-ensemble interne comme survenant avant le sous-ensemble externe. Cela a pour effet que les déclarations d'entité et de liste d'attributs dans le sous-ensemble interne ont préséance sur ceux du sous-ensemble externe.

Les processeurs XML 1.1 DEVRAIENT également accepter les documents XML 1.0. Si un document est bien formé ou valide selon XML 1.0, et pourvu qu'il ne contienne pas de caractères de contrôle dans l'intervalle [#x7F-#x9F] autres que sous forme d'échappements de caractères, alors il peut être rendu, respectivement, bien formé ou valide selon XML 1.1 en changeant le numéro de version.

2.9 La déclaration de document autonome

Les déclarations de balisage peuvent affecter le contenu du document, lors de la transmission entre un processeur XML et une application. La déclaration de document autonome, qui PEUT apparaître comme composant de la déclaration XML, signale l'existence ou non de telles déclarations, qui apparaissent hors de l'entité document ou dans des entités paramètres. [Définition : Une déclaration de balisage externe se définit comme une déclaration de balisage survenant dans le sous-ensemble externe ou dans une entité paramètre (externe ou interne, qui est incluse, dans ce dernier cas, parce que les processeurs non validants ne sont pas obligés de les lire).]

La déclaration de document autonome

Dans une déclaration de document autonome, la valeur "yes" indique l'absence d'une déclaration de balisage externe susceptible d'affecter les informations transmises du processeur XML à l'application. La valeur "no" indique la présence ou une probabilité de présence de telles déclarations de balisage externes. Remarquez que la déclaration de document autonome indique seulement la présence de déclarations. Dans un document, la présence d'appels d'entités externes, quand la déclaration de ces entités est interne, ne change pas son statut autonome.

S'il n'existe pas de déclaration de balisage externe, la déclaration de document autonome est sans objet. S'il existe des déclarations de balisage externes en l'absence de déclaration de document autonome, alors la valeur "no" est supposée.

Tout document XML pour lequel on a standalone="no" peut être converti par des moyens algorithmiques en un document autonome, ce qui peut être souhaitable pour certaines applications de remise via un réseau.

Un exemple de déclaration XML avec une déclaration de document autonome :

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

2.10 L'interprétation des caractères blancs

Lors de l'édition de documents XML, il est souvent commode d'utiliser des caractères blancs (espace, tabulation et saut de ligne) afin de distinguer le balisage pour une meilleure lisibilité. En général, ces caractères blancs ne sont pas destinés à être inclus dans la version remise du document. Au contraire, il n'est pas rare que des caractères blancs significatifs doivent être conservés dans la version remise, par exemple pour de la poésie ou du code source.

Un processeur XML DOIT toujours transmettre à l'application tous les caractères du document qui ne font pas partie du balisage. Un processeur XML validant DOIT également informer l'application des caractères blancs qui apparaissent dans un contenu d'éléments.

L'attribut spécial xml:space PEUT être attaché à un élément pour signaler que les caractères blancs dans cet élément devraient être préservés par les applications. Dans les documents valides, cet attribut, comme n'importe quel autre, DOIT être déclaré si on l'utilise. Auquel cas, on DOIT le déclarer comme étant d'un type énuméré qui peut prendre la valeur "default", ou "preserve" ou les deux. Par exemple :

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

La valeur "default" indique que les modes de traitement par défaut des caractères blancs des applications sont acceptables pour l'élément en question. La valeur "preserve" exprime l'intention selon laquelle les applications doivent préserver tous les caractères blancs. Cette intention est censée s'appliquer à tous les éléments dans le contenu de l'élément sur lequel elle est spécifiée, à moins qu'elle ne soit annulée par une autre instance de l'attribut xml:space. Cette spécification ne confère aucune signification à une valeur de l'attribut xml:space autre que "default" ou "preserve". La spécification d'une autre valeur constitue une erreur ; le processeur XML PEUT signaler l'erreur ou PEUT récupérer en ignorant la spécification de l'attribut ou en signalant la valeur (erronnée) à l'application. Les applications peuvent ignorer ou rejeter les valeurs erronnées.

L'élément racine d'un document est censé n'avoir signalé aucune intention en ce qui concerne l'interprétation des caractères blancs par l'application, à moins qu'il ne fournisse une valeur pour cet attribut ou que l'attribut soit déclaré avec une valeur implicite.

2.11 L'interprétation des fins de ligne

Les entités analysables XML sont souvent stockées dans des fichiers qui, pour des raisons de commodité d'édition, sont organisés en lignes. Ces lignes sont typiquement séparées par une certaine combinaison des caractères RETOUR CHARIOT #xD et SAUT DE LIGNE #xA.

Pour simplifier la tâche des applications, le processeur XML DOIT agir comme s'il avait normalisé tous les sauts de ligne dans les entités analysables externes (y compris l'entité document) en entrée, avant lecture, en traduisant toutes les combinaisons de caractères suivantes en un seul caractère #xA :

1. La séquence de deux caractères #xD #xA

2. La séquence de deux caractères #xD #x85

3. Le caractère seul #x85

4. Le caractère seul #x2028

5. Chaque caractère #xD qui n'est pas immédiatement suivi par #xA ou #x85.

Les caractères #x85 et #x2028 ne peuvent pas être reconnus et traduits avec fiabilité, tant que la déclaration de codage d'une entité (si elle est présente) n'a pas été lue. De ce fait, leur utilisation au sein de la déclaration XML ou de la déclaration de texte constitue une erreur fatale.

2.12 L'identification de la langue

Lors du traitement d'un document, il est souvent utile d'identifier la langue naturelle ou formelle dans laquelle le contenu est écrit. L'attribut spécial xml:lang PEUT être inséré dans les documents pour spécifier la langue employée pour le contenu et les valeurs d'attribut de n'importe quel élément d'un document XML. Dans les documents valides, cet attribut, comme n'importe quel autre, DOIT être déclaré si on l'utilise. Les valeurs de l'attribut sont les identificateurs de langue tels que définis par le document [IETF RFC 3066], Les étiquettes d'identification des langues, ou par son successeur ; on PEUT, en outre, spécifier la chaîne vide.

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

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&#xDF;em Bem&#xFC;h'n.</l>
</sp>

L'intention déclarée par l'attribut xml:lang est censée s'appliquer à tous les attributs et le contenu de l'élément sur lequel il est spécifié, à moins qu'elle ne soit annulée par une instance de l'attribut xml:lang sur un autre élément dans l'élément en question. En particulier, la valeur vide de l'attribut xml:lang s'utilise sur un élément B pour annuler une spécification sur un élément englobant A, sans spécifier d'autre langue. Aucune information de langue n'est censée exister à l'intérieur de B, tout comme si on n'avait pas attaché d'attribut xml:lang à B ou à un de ses ancêtres.

Une déclaration simple pour l'attribut xml:lang prendrait la forme :

xml:lang CDATA #IMPLIED

Mais on PEUT aussi donner des valeurs d'attribut spécifiques, si nécessaire. Dans un recueil de poèmes français pour des étudiants anglais, comportant des gloses et des notes en anglais, l'attribut xml:lang pourrait s'employer de cette façon :

<!ATTLIST poeme  xml:lang CDATA 'fr'>
<!ATTLIST glose  xml:lang CDATA 'en'>
<!ATTLIST note   xml:lang CDATA 'en'>

2.13 La vérification de la normalisation

Toutes les entités analysables XML (y compris les entités documents) DEVRAIENT être complètement normalisées, selon les définitions de l'annexe B Les définitions pour la normalisation des caractères, complétées par les définitions des structures concernées de XML suivantes :

1. Le texte de remplacement de toutes les entités analysables

2. Tout le texte correspondant, selon le contexte, à l'une des productions suivantes :

   1. DonnéesDT

   2. DonnéesTextuelles

   3. contenu

   4. Nom

   5. AtomeNml

Toutefois, un document reste toujours bien formé même s'il n'est pas complètement normalisé. Les processeurs XML DEVRAIENT fournir une option d'utilisateur afin de vérifier que le document en cours de traitement est dans une forme complètement normalisée et signaler à l'application s'il l'est ou non. L'option de ne pas vérifier DEVRAIT seulement être retenue lorsque le texte en entrée est certifié, comme défini dans l'annexe B Les définitions pour la normalisation des caractères.

La vérification de normalisation complète DOIT être menée de sorte à d'abord vérifier que l'entité est dans une forme inclusion normalisée, comme défini dans l'annexe B Les définitions pour la normalisation des caractères, puis qu'aucune des structures listées précédemment ne commence (après développement des appels de caractère) par un caractère composant, comme défini dans l'annexe B Les définitions pour la normalisation des caractères. Les processeurs non validants DOIVENT ignorer les possibles dénormalisations qui pourraient survenir à la suite de l'inclusion d'entités externes qu'ils ne savent pas lire.

Si, au cours d'une vérification de normalisation complète, un processeur rencontre des caractères pour lesquels il est incapable de déterminer les propriétés de normalisation (c'est-à-dire, des caractères introduit par une version de Unicode [Unicode] postérieure à celle utilisée dans la mise en œuvre du processeur), alors le processeur PEUT, au gré de l'utilisateur, ignorer les éventuelles dénormalisations provoquées par ces caractères. Cette option consistant à ignorer les dénormalisations NE DEVRAIENT PAS être retenue par les applications lorsque la fiabilité ou la sécurité revêtent une importance critique.

Les processeurs XML NE DOIVENT PAS transformer un document en entrée pour l'amener à une forme complètement normalisée. Les applications XML qui produisent du code XML 1.1 en sortie, à partir d'une entrée soit XML 1.1, soit XML 1.0, DEVRAIENT s'assurer que la sortie est complètement normalisée ; les formes de traitement internes n'ont pas nécessité à être complètement normalisées.

L'objectif de ce chapitre est d'encourager vigoureusement les processeurs XML à vérifier que les créateurs de documents XML les aient correctement normalisés au préalable, de sorte que les applications XML puissent effectuer des tests, comme des comparaisons de chaînes à l'identité, sans devoir se soucier des différentes orthographes possibles, pour les chaînes, permises par Unicode.

Quand les entités ont un codage non-Unicode, si le processeur les transcode vers Unicode, alors il DEVRAIT utiliser un transcodeur normalisant.

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

[Définition : Chaque élément XML non vide commence par une balise ouvrante.]

Les balises ouvrantes

La valeur de type Nom dans les balises ouvrante et fermante donne le type de l'élément. [Définition : Les couples formé par les valeurs de type Nom-ValeurAtt représentent les spécifications d'attribut de l'élément], [Définition : la valeur de type Nom dans chaque couple représentant le nom de l'attribut] et [Définition : la valeur de type ValeurAtt (le texte entre les caractères délimiteurs ' ou ") représentant la valeur de l'attribut.] Remarquez que l'ordre des spécifications d'attribut, dans une balise ouvrante ou une balise d'élément vide, n'est pas significatif.

Exemple de balise ouvrante :

<défterme id="dt-chien" terme="chien">

[Définition : Tous les éléments qui commencent par une balise ouvrante DOIVENT être marqués par une balise fermante contenant un nom qui reprend le type d'élément de la balise ouvrante :]

Les balises fermantes

Exemple de balise fermante :

</défterme>

[Définition : Le texte entre la balise ouvrante et la balise fermante est appelé contenu de l'élément :]

Le contenu des éléments

[Définition : Un élément sans contenu est dit vide.] Un élément vide est représenté soit par une balise ouvrante suivie immédiatement de la balise fermante, soit par une balise d'élément vide. [Définition : Une balise d'élément vide prend une forme spéciale :]

Les balises des éléments vides

Les balises d'élément vide PEUVENT s'utiliser pour tout élément sans contenu, que celui-ci ait été déclaré par le mot-clé "EMPTY" ou non. Pour des raisons d'interopérabilité, la balise d'élément vide DEVRAIENT être utilisée, et DEVRAIT seulement l'être, pour les éléments déclarés avec la valeur "EMPTY".

Exemples d'éléments vides :

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

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

La structure des éléments d'un document XML PEUT, pour les besoins de la validation, être contrainte au moyen de déclarations de type d'élément et de liste d'attributs. Une déclaration de type d'élément contraint le contenu de l'élément.

Les déclarations de type d'élément contraignent souvent les types d'élément qui peuvent apparaître comme enfants de l'élément. Un processeur XML PEUT, au gré de l'utilisateur, émettre un avertissement lorsqu'une déclaration mentionne un type d'élément pour lequel aucune déclaration n'existe, mais ce n'est pas une erreur.

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

Les déclarations de type d'élément

La valeur de type Nom donne le type de l'é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 Les 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 DOIVENT PAS apparaître en dehors des balises ouvrantes et des balises d'élément vide ; les productions utilisées pour les reconnaître apparaissent donc dans le chapitre 3.1 Les balises ouvrantes, les balises fermantes et les balises d'élément vide. On PEUT utiliser des déclarations de liste d'attributs :

• Pour définir l'ensemble des attributs relatifs à un type d'élément donné.

• Pour établir des contraintes de type sur ces attributs.

• Pour fournir des valeurs implicites aux attributs.

[Définition : Les déclarations de liste d'attributs spécifient 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é :]

Les déclarations de type d'attribut

La valeur de type Nom dans la règle DéclListeAtt représente le type d'un élément. Un processeur XML MAY, au gré de l'utilisateur, émettre un avertissement si des attributs sont déclarés pour un type d'élément alors que celui-ci ne l'est pas, mais ce n'est pas une erreur. La valeur de type Nom dans la règle DéfAtt représente le nom de l'attribut.

Lorsque plusieurs règles DéclListeAtt sont fournies pour un type d'élément donné, alors tous les contenus présents sont fusionnés. Lorsque plusieurs définitions sont fournies pour le même attribut d'un type d'élément donné, alors seule la première déclaration est attachée et les suivantes sont ignorées. Pour des raisons d'interopérabilité, les rédacteurs de DTD PEUVENT choisir de fournir une déclaration de liste d'attribut au plus pour un type d'élément donné, une définition d'attribut au plus pour un nom d'attribut donné dans une déclaration de liste d'attributs et une définition d'attribut au moins dans chaque déclaration de liste d'attributs. Pour des raisons d'interopérabilité, un processeur XML PEUT, au gré de l'utilisateur, émettre un avertissement lorsque plusieurs déclaration de liste d'attributs sont fournies pour un type d'élément donné ou lorsque plusieurs définitions d'attribut sont fournies pour un attribut donné, mais ce n'est pas une erreur.