‘Extensible Markup Language (XML) 1.1’ (4 février 2004) en version française

Statut du document traduit

Ceci est une traduction de la recommandation XML 1.1 du W3C traitant du langage de balisage extensible XML 1.1.

Cependant, il ne s'agit pas de la version officielle en français. Seul le document original en anglais a valeur de référence. On peut l'obtenir à : http://www.w3.org/TR/2004/REC-xml11-20040204/.

Avertissement

Des erreurs ont pu survenir malgré le soin apporté à ce travail.

Notes sur la traduction

Certains concepts sont difficiles à rendre en français, ou peuvent bénéficier d'une explication. Par moment, les expressions originales en anglais viennent en renfort dans le texte sous cette forme :
ex. traduction [ndt. translation]

D'autres expressions intègrent également les versions originales en anglais, qui apparaissent d'une manière ou d'une autre (selon le navigateur), lorsque l'on laisse le pointeur de la souris au-dessus d'elles. Elles se présentent sous cette forme :
ex. Agent utilisateur

Cette version française intègre toutes les corrections survenues depuis la parution de la recommandation. On peut trouver la liste des dernières modifications à l'adresse http://www.w3.org/XML/xml-V11-1e-errata. Les liens vers l'errata traduit, à jour en date du 29 mars 2005, sont signalés comme ceci :
errata-E01.

Finalement, les liens menant à d'autres documents du W3C déjà traduits sont discrètement doublés vers leur traduction, de cette manière :
ex. un lien vf  vers un document du W3C.

Archives compressées et autres formats

Cette traduction est disponible au format HTML sous forme d'archive compressée et, le cas échéant, dans d'autres formats à l'adresse http://www.yoyodesign.org/doc/w3c/w3c.html.

Autres documents traduits

On peut consulter les traductions en français d'autres documents du W3C à
http://www.w3.org/2003/03/Translations/byLanguage?language=fr

Avis légal

Copyright © 1994-2004 World Wide Web Consortium,
(Massachusetts Institute of Technology,
European Research Consortium for Informatics and Mathematics,
Keio University).
Tous droits réservés. Consulter la notice de copyright pour les productions du W3C.


W3C

Le langage de balisage extensible (XML) 1.1

Recommandation du W3C du 4 février 2004

Cette version :
http://www.w3.org/TR/2004/REC-xml11-20040204/
Dernière version :
http://www.w3.org/TR/xml11
Version précédente :
http://www.w3.org/TR/2003/PR-xml11-20031105/
Rédacteurs :
Tim Bray, Textuality et Netscape <tbray@textuality.com>
Jean Paoli, Microsoft <jeanpa@microsoft.com>
C. M. Sperberg-McQueen, W3C <cmsmcq@w3.org>
Eve Maler, Sun Microsystems, Inc. <eve.maler@east.sun.com>
François Yergeau <fyergeau@alis.com>
John Cowan <cowan@ccil.org>

Veuillez consulter l'errata de ce document qui peut recéler des corrections normatives.

Le document est également disponible dans ces formats non normatifs : XML et XHTML avec des indications de révision par code de couleur.

Voir également d'éventuelles traductions.


Résumé

Le langage de balisage extensible (XML) est un sous-ensemble de SGML entièrement décrit dans ce document. Son but est d'autoriser le service, la réception et le traitement d'un document SGML générique sur le Web comme c'est maintenant possible avec un document HTML. XML est conçu pour être facile à mettre en œuvre et pour être interopérable avec SGML comme avec HTML.

Statut de ce document

Cette section décrit le statut de ce document au moment de sa publication. D'autres documents peuvent venir le remplacer. On peut trouver une liste des publications actuelles du W3C et la dernière révision de ce rapport technique dans l'index des rapports techniques du W3C à http://www.w3.org/TR/.

Ce document est une recommandation vf du W3C. Il a été revu par des membres du W3C et des tiers intéressés et il a été approuvé par le Directeur comme recommandation du W3C. C'est un document stable qui peut être utilisé comme matériel de référence ou cité comme référence normative à partir d'un autre document. Le rôle du W3C en produisant la recommandation consiste à attirer l'attention sur la spécification et à en promouvoir le large déploiement. Cela contribue à l'amélioration du fonctionnement et de l'interopérabilité du Web.

Ce document spécifie une syntaxe, créée par définition d'un sous-ensemble d'une norme de traitement de texte existante, internationale très répandue (le langage de balisage généralisé standard SGML ISO 8879:1986(E), amendé et corrigé), pour une utilisation sur le Web. C'est un produit de l'activité XML du W3C. La version en anglais de cette spécification est la seule normative. Toutefois, voir à http://www.w3.org/2003/03/Translations/byTechnology?technology=xml11 pour des traductions de ce document.

On peut trouver la documentation des éventuels droits de propriété intellectuelle concernant cette recommandation sur la page de divulgation des droits de propriété intellectuelle publique du groupe de travail.

Un rapport de mise en œuvre de XML 1.1 est disponible à http://www.w3.org/XML/2002/09/xml11-implementation.html.

Veuillez signaler les erreurs dans ce document sur la liste de diffusion xml-editor@w3.org (archives disponibles). La liste des erreurs pour cette édition se trouve à http://www.w3.org/XML/xml-V11-1e-errata.

Une batterie de tests a été mise en place pour l'évaluation de la conformité par rapport à cette spécification.

Table des matières

  1. Introduction
    1. L'origine et les buts
    2. La terminologie
    3. Les justifications et la liste des changements en faveur de XML 1.1
  2. Les documents
    1. Les documents XML bien formés
    2. Les caractères
    3. Les structures syntaxiques communes
    4. Les données textuelles et le balisage
    5. Les commentaires
    6. Les instructions de traitement
    7. Les sections de type CDATA
    8. Le prologue et la déclaration de type de document
    9. La déclaration de document autonome
    10. L'interprétation des caractères blancs
    11. L'interprétation des fins de ligne
    12. L'identification de la langue
    13. La vérification de la normalisation
  3. Les structures logiques
    1. Les balises ouvrantes, les balises fermantes et les balises d'élément vide
    2. Les déclarations de type d'élément
      1. Le contenu d'éléments
      2. Le contenu mixte
    3. Les déclarations de liste d'attributs
      1. Les types d'attribut
      2. Les attributs implicites
      3. La normalisation de la valeur d'attribut
    4. Les sections conditionnelles
  4. Les structures physiques
    1. Les appels de caractère et d'entité
    2. Les déclarations d'entité
      1. Les entités internes
      2. Les entités externes
    3. Les entités analysables
      1. La déclaration de texte
      2. Les entités analysables bien formées
      3. Le codage des caractères dans les entités
      4. L'information de version dans les entités
    4. Le traitement des entités et des appels par le processeur XML
      1. Non reconnu
      2. Inclus
      3. Inclus si validation
      4. Interdit
      5. Inclus en littéral
      6. Notifier
      7. Non interprété
      8. Inclus comme entité paramètre
      9. Erreur
    5. La construction du texte de remplacement d'une entité
    6. Les entités prédéfinies
    7. Les déclarations de notation
    8. L'entité document
  5. La conformité
    1. Les processeurs validants et non validants
    2. L'utilisation des processeurs XML
  6. La notation

Annexes


1 Introduction

Le langage de balisage extensible, abrégé en XML, décrit une classe d'objets de données appelés documents XML et décrit partiellement le fonctionnement des logiciels qui les traitent. XML est un profil d'application, ou une forme restreinte d'application, du langage de balisage généralisé standard SGML[ISO 8879]. Par construction, les documents XML sont des documents SGML conformes.

Les documents XML sont constitués d'unités de stockage, appelées entités, qui contiennent soit des données analysables, soit non analysables. Les données analysables sont constituées de caractères, dont certains représentent les données textuelles et les autres le balisage. Le balisage code une description du classement et de la structure logique du document. XML fournit un mécanisme pour imposer des contraintes sur le classement et la structure logique.

[Définition : On utilise un module logiciel appelé processeur XML pour lire les documents XML et permettre un accès à leur contenu et leur structure.] [Définition : Un processeur XML est supposé agir au nom d'un autre module, appelé application.] Cette spécification décrit le fonctionnement obligatoire d'un processeur XML en ce qui concerne la façon dont il doit lire des données XML et les informations qu'il doit fournir à l'application.

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, qu'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 non imposée, incluse afin d'augmenter la probabilité que les documents XML puissent être traités par les moteurs SGML existants antérieurs à l'annexe des adaptations WebSGML de ISO 8879.]

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 entrepôts 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 Les documents

[Définition : Un objet de données est un document XML s'il est bien formé, comme défini par cette spécification. Un document XML bien formé PEUT, en outre, être valide s'il satisfait à certaines autres contraintes.]

errata-E16

Chaque document XML possède à la fois une structure logique et physique. Physiquement, le document se compose d'unités appelées entités. Une entité PEUT appeler d'autres entités afin de provoquer leur inclusion dans le document. Un document commence par une racine ou une 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, lesquels sont tous indiqués par un balisage explicite dans le document. Les structures physique et logique DOIVENT s'imbriquer correctement, comme décrit dans le chapitre 4.3.2 Les entités analysables bien formées.

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
[1]   document   ::=   (prologue élément Divers)* - (Car* CarRestreint Car*)

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
[2]   Car   ::=   [#x1-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]/* tout caractère Unicode, sauf les blocs de substitution FFFE et FFFF. */
[2a]   CarRestreint   ::=   [#x1-#x8] | [#xB-#xC] | [#xE-#x1F] | [#x7F-#x84] | [#x86-#x9F]

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.

Remarque :

Les auteurs de document sont invités à éviter les caractères de compatibilité, tels que défininis dans Unicode [Unicode]. Les caractères définis dans les étendues suivantes sont également déconseillés. Ce sont soit des caractères de contrôle, soit des caractères Unicode définitivement indéfinis :

[#x7F-#x84], [#x86-#x9F], [#xFDD0-#xFDDF],
[#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 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
[3]   S   ::=   (#x20 | #x9 | #xD | #xA)+

Remarque :

La présence du caractère #xD dans la production précédente est uniquement justifiée pour une question de rétrocompatibilité avec la première édition vf. Comme expliqué au chapitre 2.11 L'interprétation des fins de ligne, tous les caractères #xD présents littéralement dans un document XML sont soit supprimés, soit remplacés par des caractères #xA avant tout traitement. La seule façon d'obtenir un caractère #xD qui corresponde à cette production, c'est d'utiliser un appel de caractère dans une valeur d'entité littérale.

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

Remarque :

La recommandation des espaces de nommage dans XML [XML Names] confère un sens particulier aux noms contenant des caractères deux-points (:). De ce fait, les auteurs, sauf pour les besoins des espaces de nommage, ne devraient pas employer le caractère deux-points dans les noms XML, au contraire des processeurs XML qui doivent l'accepter comme caractère de nom.

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
[4]   CarNomInit   ::=   ":" | [A-Z] | "_" | [a-z] | [#xC0-#xD6] | [#xD8-#xF6] | [#xF8-#x2FF] | [#x370-#x37D] | [#x37F-#x1FFF] | [#x200C-#x200D] | [#x2070-#x218F] | [#x2C00-#x2FEF] | [#x3001-#xD7FF] | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF]
[4a]   CarNom   ::=   CarNomInit | "-" | "." | [0-9] | #xB7 | [#x0300-#x036F] | [#x203F-#x2040]
[5]   Nom   ::=   CarNomInit (CarNom)*
[6]   Noms   ::=   Nom (#x20 Nom)*
[7]   AtomeNml   ::=   (CarNom)+
[8]   AtomesNmx   ::=   AtomeNml (#x20 AtomeNml)*

Remarque :

Les productions Noms et AtomesNmx s'utilisent pour définir la validité des valeurs d'attribut lexicalisées après normalisation (voir le chapitre 3.3.1 Les types d'attribut).

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
[9]   ValeurEntité   ::=   '"' ([^%&"] | AppelEP | Appel)* '"'
|  "'" ([^%&'] | AppelEP | Appel)* "'"
[10]   ValeurAtt   ::=   '"' ([^<&"] | Appel)* '"'
|  "'" ([^<&'] | Appel)* "'"
[11]   LittéralSystème   ::=   ('"' [^"]* '"') | ("'" [^']* "'")
[12]   IdPubLittéral   ::=   '"' CarIdPub* '"' | "'" (CarIdPub - "'")* "'"
[13]   CarIdPub   ::=   #x20 | #xD | #xA | [a-zA-Z0-9] | [-'()+,./:=?;!*#@$_%]

Remarque :

Bien que la production ValeurEntité permette la définition d'une entité générale consistant en un seul caractère explicite < dans le littéral (par exemple, <!ENTITY monlt "<">), on déconseille vivement cette pratique dans la mesure où tout appel de cette entité provoquera une erreur de forme.

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 &amp; et &lt;. Le caractère supérieur à (>) PEUT être représenté par la chaîne &gt;, et DOIT, pour des raisons de compatibilité, être échappé en utilisant soit la chaîne &gt;, 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 &apos; et le caractère guillemet double (") par &quot;.

Les données textuelles
[14]   DonnéesTextuelles   ::=   [^<&]* - ([^<&]* ']]>' [^<&]*)

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
[15]   Commentaires   ::=   '<!--' ((Car - '-') | ('-' (Car - '-')))* '-->'

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
[16]   IT   ::=   '<?' CibleIT (S (Car* - (Car* '?>' Car*)))? '?>'
[17]   CibleIT   ::=   Nom - (('X' | 'x') ('M' | 'm') ('L' | 'l'))

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
[18]   SectionDT   ::=   DébutDT DonnéesDT FinDT
[19]   DébutDT   ::=   '<![CDATA['
[20]   DonnéesDT   ::=   (Car* - (Car* ']]>' Car*))
[21]   FinDT   ::=   ']]>'

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 (ni possible) de les échapper en utilisant les chaînes &lt; et &amp;. 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, le rôle du balisage consiste à décrire son classement et sa structure logique ainsi que 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 de 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
[22]   prologue   ::=   DéclXML Divers* (déclTypeDoc Divers*)?
[23]   DéclXML   ::=   '<?xml' InfoVersion DéclCodage? DéclDocAuto? S?'?>'
[24]   InfoVersion   ::=   S 'version' Égal ("'" NumVersion "'" | '"' NumVersion '"')
[25]   Égal   ::=   S? '=' S?
[26]   NumVersion   ::=   '1.1'
[27]   Divers   ::=   Commentaires | IT | S

[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 (un type d'entité externe particulier), 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
[28]   déclTypeDoc   ::=   '<!DOCTYPE' S Nom (S IdExterne)? S? ('[' sousEnsembleInt ']' S?)? '>'[CV : Type d'élément racine]
[CF : Sous-ensemble externe]
[28a]   SépDécl   ::=   AppelEP | S[CF : Entité paramètre entre des déclarations]
[28b]   sousEnsembleInt   ::=   (déclBalisage | SépDécl)*
[29]   déclBalisage   ::=   déclÉlément | DéclListeAtt | DéclEntité | DéclNotation | IT | Commentaires[CV : Imbrication déclaration/entité paramètre correcte]
[CF : Entités paramètres dans un sous-ensemble interne]

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 soumise à des contraintes décrites ci-dessous.

Contrainte de validité : Type d'élément racine

La valeur de type Nom dans la déclaration de type de document DOIT correspondre au type d'élément de l'élément racine.

Contrainte de validité : Imbrication déclaration/entité paramètre correcte

Le texte de remplacement de l'entité paramètre DOIT correctement s'imbriquer avec les déclarations de balisage. C'est-à-dire, que si l'un ou l'autre du premier caractère ou du 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, alors les deux DOIVENT alors y être contenus.

Contrainte de forme : Entités paramètres dans le sous-ensemble interne

Dans le sous-ensemble de DTD interne, les appels d'entité paramètre NE DOIVENT PAS apparaître à l'intérieur des déclarations de balisage ; ils PEUVENT apparaître là où les déclarations de balisage le peuvent. (Ceci ne s'applique pas aux appels qui apparaissent dans des entités paramètres externes ni au sous-ensemble externe.)

Contrainte de forme : Sous-ensemble externe

Le sous-ensemble externe, s'il existe, DOIT correspondre à la production sousEnsembleExt.

Contrainte de forme : Entité paramètre entre des déclarations

Le texte de remplacement d'un appel d'entité paramètre dans une valeur de type SépDécl DOIT correspondre à la production déclSousEnsembleExt.

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 éventuellement 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
[30]   sousEnsembleExt   ::=   DéclTexte? déclSousEnsembleExt
[31]   déclSousEnsembleExt   ::=   ( déclBalisage | sectConditionnelle | SépDécl)*

Le sous-ensemble externe et les entités paramètres externes diffèrent également du sous-ensemble interne par le fait 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.

errata-E15

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
[32]   DéclDocAuto   ::=   S 'standalone' Égal (("'" ('yes' | 'no') "'") | ('"' ('yes' | 'no') '"')) [CV : 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 distribution via un réseau.

Contrainte de validité : Déclaration de document autonome

La déclaration de document autonome DOIT avoir la valeur "no" si une quelconque déclaration de balisage externe contient :

  • des déclarations d'attributs avec des valeurs implicites, si les éléments auxquels ces attributs s'appliquent apparaissent dans le document sans spécification de valeur pour ces attributs, ou

  • des déclarations d'entité (autres que amp, lt, gt, apos, quot), si des appels de ces entités apparaissent dans le document, ou

  • des déclarations d'attribut avec des types lexicalisés, où les attributs apparaissent dans le document avec une valeur pour laquelle la normalisation produira une valeur différente de celle qui aurait été produite en l'absence de la déclaration, ou

  • des déclarations de types d'élément avec un contenu d'éléments, si des caractères blancs apparaissent directement dans une quelconque instance de ces types.

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 distribuée du document. Au contraire, il n'est pas rare que des caractères blancs significatifs doivent être conservés dans la version distribuée, 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 le fait que 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 surchargé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 surchargé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.

errata-E03

Remarque :

L'information de langue peut également être apportée par des protocoles de transport externes (par exemple, HTTP ou MIME. Cette information, le cas échéant, peut être mise à profit par les applications XML, toutefois, l'information plus locale fournie par l'attribut xml:lang la supplantera.

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 possibilité à l'utilisateur 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. La possibilité 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 d'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.

Remarque :

Les caractères composants comprennent tous les caractères Unicode de la classe des caractères combinatoires avec chasse, plus certains caractères de la classe des caractères sans chasse participant à certaines décompositions canoniques Unicode en tant que caractères non initiaux. Puisque ces caractères doivent suivre les caractères de base, empêcher les structures concernées (dont le contenu) de commencer par un caractère composant ne diminue pas significativement la capacité d'expression de XML.

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 ; il n'est pas nécessaire que les structures de traitement internes soient 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 d'identité de chaînes, sans devoir se soucier des différentes orthographes de 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 Les structures logiques

[Définition : Chaque document XML contient un ou plusieurs éléments, dont les frontières sont délimitées soit par des balises ouvrantes et des balises fermantes, soit, pour les éléments vide, par une balise d'élément vide. Chaque élément possède un type, identifié par un nom, parfois appelé identificateur générique, et PEUT avoir un ensemble de spécifications d'attribut.] Chaque spécification d'attribut se compose d'un nom et d'une valeur.

Les éléments
[39]   élément   ::=   BaliseÉlémVide
| BaliseO contenu BaliseF[CF : Correspondance au type d'élément]
[CV : Validité de l'élément]

Cette spécification ne contraint pas la sémantique, l'usage ou les noms (hormi la syntaxe) des types et attributs des éléments, sauf les noms commençant par (('X'|'x')('M'|'m')('L'|'l')) qui sont réservés à la standardisation dans cette version ou les versions futures de cette spécification.

Contrainte de forme : Correspondance au type d'élément

La valeur de type Nom dans la balise fermante d'un élément DOIT correspondre au type d'élément dans la balise ouvrante.

Contrainte de validité : Validité de l'élément

Un élément est valide s'il existe une déclaration correspondant à la valeur de type déclÉlément, pour laquelle la valeur de type Nom correspond au type de l'élément, et si l'une des conditions suivantes est vérifiée :

  1. La déclaration correspond à la valeur "EMPTY" et l'élément n'a pas de valeur de type contenu (pas même d'appel d'entité, de commentaire, d'instruction de traitement ou de caractère blanc).

  2. La déclaration correspond au type enfants et la séquence des éléments enfants appartient au langage généré par l'expression régulière dans le modèle de contenu, avec, en option, des caractères blancs, des commentaires et des instructions de traitement (c'est-à-dire, un balisage correspondant à la production [27] Divers) situés entre la balise ouvrante et le premier élément enfant, entre les éléments enfants ou entre le dernier élément enfant et la balise fermante. Remarquez qu'une section de type CDATA, qui contient seulement des caractères blancs, ou une entité dont le texte de remplacement est un appel de caractère se développant en un caractère blanc, ne correspond pas au non-terminal S et ne peut donc pas apparaître à cette position. Par contre, un appel d'entité interne avec une valeur littérale qui se compose d'appels de caractère se développant en caractères blancs correspond bien à S, puisque son texte de remplacement se compose des caractères blancs issus du développement des appels de caractère.

  3. La déclaration correspond au type Mixte et le contenu (après substitution des éventuels appels d'entité par leur texte de remplacement) se compose de données textuelles, de commentaires, d'instructions de traitement et d'éléments enfants dont les types correspondent aux noms dans le modèle de contenu.

    errata-E11

  4. La déclaration correspond à la valeur "ANY" et le contenu (après substitution des éventuels appels d'entité par leur texte de remplacement) se compose de données textuelles et d'éléments enfants dont les types sont déclarés.

    errata-E11

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
[40]   BaliseO   ::=   '<' Nom (S Attribut)* S? '>'[CF : Spécification d'attribut unique]
[41]   Attribut   ::=   Nom Égal ValeurAtt[CV : Type de valeur d'attribut]
[CF : Pas d'appel d'entité externe]
[CF : Pas de caractère < dans la valeur d'attribut]

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.

Contrainte de forme : Spécification d'attribut unique

Un nom d'attribut NE DOIT PAS apparaître plus d'une fois dans la même balise ouvrante ou la même balise d'élément vide.

Contrainte de validité : Type de valeur d'attribut

L'attribut DOIT avoir été déclaré ; la valeur DOIT être du type déclaré pour elle. (Pour les types d'attribut, voir le chapitre 3.3 Les déclarations de liste d'attributs.)

Contrainte de forme : Pas d'appel d'entité externe

Les valeurs d'attribut NE DOIVENT PAS contenir d'appels d'entité directs ou indirects à des entités externes.

Contrainte de forme : Pas de caractère < dans les valeurs d'attribut

Le texte de remplacement d'une quelconque entité appelée directement ou indirectement dans une valeur d'attribut NE DOIT PAS contenir de caractère <.

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
[42]   BaliseF   ::=   '</' Nom S? '>'

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
[43]   contenu   ::=   DonnéesTextuelles? ((élément | Appel | SectionDT | IT | Commentaires) DonnéesTextuelles?)*

[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
[44]   BaliseÉlémVide   ::=   '<' Nom (S Attribut)* S? '/>'[CF : Spécification d'attribut unique]

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 DEVRAIT ê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
[45]   déclÉlément   ::=   '<!ELEMENT' S Nom S specContenu S? '>'[CV : Déclaration de type d'élément unique]
[46]   specContenu   ::=   'EMPTY' | 'ANY' | Mixte | enfants

La valeur de type Nom donne le type de l'élément déclaré.

Contrainte de validité : Déclaration de type d'élément unique

Un type d'élément NE DOIT PAS être déclaré plus d'une fois.

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

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

3.2.1 Le contenu d'éléments

[Définition : Un élément a un type de contenu d'éléments lorsque les éléments de ce type DOIVENT seulement contenir des éléments enfants (pas de données textuelles), séparés par des caractères blancs optionnels (des caractères correspondant au nonterminal S).] [Définition : Auquel cas, la contrainte inclut un modèle de contenu, une grammaire simple régissant les types des éléments enfants autorisés et l'ordre dans lequel ceux-ci peuvent apparaître.] La grammaire est construite à partir de particules de contenu (type pc), qui se composent de noms, de listes de choix de particules de contenu ou de listes de séquences de particules de contenu :

Les modèles de contenu des éléments
[47]   enfants   ::=   (choix | séq) ('?' | '*' | '+')?
[48]   pc   ::=   (Nom | choix | séq) ('?' | '*' | '+')?
[49]   choix   ::=   '(' S? pc ( S? '|' S? pc )+ S? ')'[CV : Imbrication groupe/entité paramètre correcte]
[50]   séq   ::=   '(' S? pc ( S? ',' S? pc )* S? ')'[CV : Imbrication groupe/entité paramètre correcte]

Chaque valeur de type Nom correspond au type d'un élément qui PEUT apparaître comme élément enfant. N'importe quelle particule de contenu dans une liste de choix PEUT apparaître dans le contenu d'éléments à l'endroit où la liste de choix apparaît dans la grammaire. Les particules de contenu intervenant dans une liste de séquences DOIVENT apparaître chacune dans le contenu d'éléments selon l'ordre donné dans la liste. Le caractère optionnel qui suit un nom ou une liste indique si l'élément ou les particules de contenu de la liste peuvent apparaître une ou plusieurs fois (+), zéro fois ou plus (*) ou zéro ou 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. Cette syntaxe et cette signification sont identiques à celles utilisées dans les productions de cette spécification.

Le contenu d'un élément correspond à un modèle de contenu si et seulement si il est possible de tracer un chemin, au travers du modèle de contenu, en obéissant aux opérateurs de séquence, de choix et de répétition et en faisant correspondre chaque élément du contenu à un type d'élément du modèle de contenu. Pour des raisons de compatibilité, il y a erreur si le modèle de contenu autorise un élément à correspondre à plusieurs occurrences d'un type d'élément du modèle de contenu. Pour des précisions, voir l'annexe D Les modèles de contenu déterministes.

Contrainte de validité : Imbrication groupe/entité paramètre correcte

Le texte de remplacement d'une entité paramètre DOIT être correctement imbriqué dans les groupes entre parenthèses. C'est-à-dire, que si l'une des parenthèses ouvrante ou fermante dans une structure de type choix, séq ou Mixte est contenue dans le texte de remplacement d'une entité paramètre, alors les deux DOIVENT être contenues dans le même texte de remplacement.

Pour des raisons d'interopérabilité, si un appel d'entité paramètre apparaît dans une structure de type choix, séq ou Mixte, alors son texte de remplacement DEVRAIT contenir au moins un caractère non blanc, et ni le premier ni le dernier caractère non blanc du texte de remplacement ne DEVRAIENT être des connecteurs (| ou ,).

Exemples de modèles de contenu d'éléments :

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

3.2.2 Le contenu mixte

[Définition : Un élément a un type de contenu mixte lorsque les éléments de ce type PEUVENT contenir des données textuelles, entrecoupées d'éléments enfants optionnels.] Auquel cas, les types des éléments enfants PEUVENT être contraints, mais non leur ordre ni le nombre de leurs occurences :

Les déclarations de contenu mixte
[51]   Mixte   ::=   '(' S? '#PCDATA' (S? '|' S? Nom)* S? ')*'
| '(' S? '#PCDATA' S? ')' [CV : Imbrication groupe/entité paramètre correcte]
[CV : Pas de type en double]

Les valeurs de type Nom donnent les types des éléments qui peuvent apparaître comme enfants. Historiquement, le mot-clé #PCDATA dérive de l'expression parsed character data [ndt. données textuelles analysables].

Contrainte de validité : Pas de type en double

Le même nom NE DOIT PAS apparaître plus d'une fois dans une seule déclaration de contenu mixte.

Exemples de déclarations de contenu mixte :

<!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
[52]   DéclListeAtt   ::=   '<!ATTLIST' S Nom DéfAtt* S? '>'
[53]   DéfAtt   ::=   S Nom S TypeAtt S DéclValImpl

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 signifiante et les suivantes sont ignorées. Pour des raisons d'interopérabilité, les rédacteurs de DTD PEUVENT choisir de fournir au plus une déclaration de liste d'attribut 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. 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.

3.3.1 Les types d'attribut

Les types d'attribut XML sont de trois sortes : un type chaîne, un ensemble de types lexicalisés et des types énumérés. Le type chaîne accepte n'importe quelle chaîne littérale comme valeur. Les types lexicalisés ont diverses contraintes lexicales et sémantiques. Les contraintes de validité notées dans la grammaire s'appliquent après que la valeur d'attribut a été normalisée, 3.3.3 La normalisation des valeurs d'attribut.

Les types d'attribut
[54]   TypeAtt   ::=   TypeChaîne | TypeAtomique | TypeÉnuméré
[55]   TypeChaîne   ::=   'CDATA'
[56]   TypeAtomique   ::=   'ID'[CV : Valeur de type ID]
[CV : Un seul ID par type d'élément]
[CV : Valeur implicite de l'attribut ID]
| 'IDREF'[CV : Valeur de type IDREF]
| 'IDREFS'[CV : Valeur de type IDREF]
| 'ENTITY'[CV : Nom d'entité]
| 'ENTITIES'[CV : Nom d'entité]
| 'NMTOKEN'[CV : Nom d'unité lexicale]
| 'NMTOKENS'[CV : Nom d'unité lexicale]

Contrainte de validité : Valeur de type ID

Les valeur de type ID DOIVENT correspondre à la production Nom. Un nom NE DOIT PAS apparaître plus d'une fois comme valeur de ce type dans un document XML, c'est-à-dire, que les valeurs de type ID DOIVENT identifier uniquement les éléments qui les portent.

Contrainte de validité : Un seul ID par type d'élément

Un type d'élément NE DOIT PAS avoir plus d'un attribut ID spécifié.

Contrainte de validité : Valeur implicite de l'attribut ID

Un attribut ID DOIT avoir une valeur implicite déclarée égale à "#IMPLIED" ou "#REQUIRED".

Contrainte de validité : Valeur de type IDREF

Les valeurs de type IDREF DOIVENT correspondre à la production Nom, et les valeurs de type IDREFS DOIVENT correspondre à celle du type Noms. Chaque valeur de type Nom DOIT correspondre à la valeur d'un attribut ID sur un certain élément du document XML, c'est-à-dire, que les valeurs IDREF DOIVENT correspondre à la valeur d'un certain attribut ID.

Contrainte de validité : Nom d'entité

Les valeurs de type ENTITY DOIVENT correspondre à la production Nom, et les valeurs de type ENTITIES DOIVENT correspondre à celle du type Noms. Chaque valeur de type Nom DOIT correspondre au nom d'une entité non analysable déclarée dans le DTD.

Contrainte de validité : Nom d'unité lexicale

Les valeurs de type NMTOKEN DOIVENT correspondre à la production AtomeNml, et les valeurs de type NMTOKENS DOIVENT correspondre à celle du type AtomesNmx.

[Définition : Les attribut énumérés DOIVENT prendre l'une des valeurs d'une liste fournie dans la déclaration]. Il existe deux sortes de types énumérés :

Les types d'attribut énumérés
[57]   TypeÉnuméré   ::=   TypeNotation | Énumération
[58]   TypeNotation   ::=   'NOTATION' S '(' S? Nom (S? '|' S? Nom)* S? ')' [CV : Attributs de notation]
[CV : Une seule notation par type d'élément]
[CV : Pas de notation sur un élément vide]
[CV : Pas d'unité lexicale en double]
[59]   Énumération   ::=   '(' S? AtomeNml (S? '|' S? AtomeNml)* S? ')'[CV : Énumeration]
[CV : Pas d'unité lexicale en double]

L'attribut NOTATION identifie une notation, déclarée dans le DTD avec des identificateurs système et/ou publique, qui s'utilise pour interpréter l'élément auquel l'attribut est attaché.

Contrainte de validité : Attributs de notation

Les valeurs de ce type DOIVENT correspondre à l'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

Un type d'élément NE DOIT PAS avoir plus d'un attribut NOTATION spécifié.

Contrainte de validité : Pas de notation sur un élément vide

Pour des raisons de compatibilité, un attribut de type NOTATION NE DOIT PAS être déclaré sur un élément "EMPTY".

Contrainte de validité : Pas d'unité lexicale en double

Les noms de notation dans une seule déclaration d'attribut TypeNotation, tout comme les valeurs de type AtomeNml dans une seule déclaration d'attribut Énumération, DOIVENT tous être distincts.

Contrainte de validité : Énumeration

Les valeurs de ce type DOIVENT correspondre à l'une des unités lexicales AtomeNml dans la déclaration.

Pour des raisons d'interopérabilité, la même valeur de type AtomeNml NE DEVRAIT PAS apparaître plus d'une fois dans les types d'attribut énumérés d'un seul type d'élément.

3.3.2 La valeur implicite des attributs

Une déclaration d'attribut fournit des informations sur le caractère OBLIGATOIRE de la présence de l'attribut et, si ce n'est pas le cas, sur le comportement d'un processeur XML quand un attribut déclaré est absent d'un document.

La valeur implicite des attributs
[60]DéclValImpl   ::=   '#REQUIRED' | '#IMPLIED'
| (('#FIXED' S)? ValeurAtt)[CV : Attribut obligatoire]
[CV : Syntaxe de la valeur implicite de l'attribut correcte]
[CF : Pas de caractère < dans la valeur d'attribut]
[CV : Valeur implicite de l'attribut fixe]

Dans une déclaration d'attribut, la valeur "#REQUIRED" signifie que l'attribut DOIT toujours être fourni, et la valeur "#IMPLIED" qu'aucune valeur implicite n'est fournie. [Définition : Si la déclaration n'a ni la valeur "#REQUIRED" ni la valeur "#IMPLIED", alors la valeur ValeurAtt contient la valeur implicite déclarée ; le mot-clé "#FIXED" indique que l'attribut DOIT toujours avoir la valeur implicite. Lorsqu'un processeur XML rencontre un élément dont la valeur d'un attribut n'est pas spécifiée et pour lequel il a lu une déclaration de valeur implicite, alors il DOIT signaler l'attribut et sa valeur implicite à l'application.]

Contrainte de validité : Attribut obligatoire

Si la déclaration par défaut est le mot-clé "#REQUIRED", alors l'attribut DOIT être spécifié pour tous les éléments du type dans la déclaration de liste d'attributs.

Contrainte de validité : Syntaxe de la valeur implicite de l'attribut correcte

La valeur implicite déclarée DOIT satisfaire aux contraintes syntaxiques du type d'attribut déclaré.

Remarquez que seules les contraintes syntaxiques du type sont requises ici ; d'autres contraintes (par exemple, que la valeur soit le nom d'une entité non analysable déclarée, pour un attribut de type ENTITY) peuvent entrer en ligne de compte si la valeur déclarée implicite est réellement utilisée (un élément apparaît sans spécification pour cet attribut).

errata-E12

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 :

<!ATTLIST défterme
id      ID      #REQUIRED
nom     CDATA   #IMPLIED>
<!ATTLIST liste
type    (puces|numéros|glossaire)  "numéros">
<!ATTLIST form
method  CDATA   #FIXED "POST">

3.3.3 La normalisation de la valeur d'attribut

Avant de transmettre la valeur d'un attribut à l'application ou de la vérifier, le processeur XML DOIT normaliser cette valeur d'attribut en lui appliquant l'algorithme ci-dessous, ou en utilisant une méthode équivalente de telle sorte que la valeur transmise à l'application soit identique à celle produite par cet algorithme.

  1. Toutes les fins de ligne DOIVENT avoir été normalisées à l'entrée en caractères #xA, comme décrit au chapitre 2.11 L'interprétation des fins de ligne, de sorte que le déroulement de l'algorithme se poursuive avec un texte ainsi normalisé.

  2. Commencer avec une valeur normalisée consistant en la chaîne vide.

  3. Pour chaque caractère, appel d'entité ou appel de caractère dans la valeur d'attribut non normalisée, en commençant par le premier et en poursuivant jusqu'au dernier, faire ce qui suit :

    • Dans le cas d'un appel de caractère, ajouter le caractère appelé à la valeur normalisée.

    • Dans le cas d'un appel d'entité, appliquer récursivement l'étape 3 de cet algorithme au texte de remplacement de l'entité.

    • Dans le cas d'un caractère blanc (#x20, #xD, #xA, #x9), ajouter un caractère espace #x20 à la valeur normalisée.

    • Pour un autre caractère, ajouter le caractère à la valeur normalisée.

Si l'attribut n'est pas du type CDATA, alors le processeur XML DOIT, en outre, traiter la valeur d'attribut normalisée en rejetant les éventuels caractères espace #x20 de tête ou de queue et en remplaçant les séquences de ces caractères par un seul caractère espace #x20.

Remarquez que, si la valeur d'attribut non normalisée contient un appel de caractère à un caractère blanc autre que le caractère espace #x20, la valeur normalisée contient le caractère appelé en question (#xD, #xA ou #x9). Ce cas diffère de celui où la valeur non normalisée contient un caractère blanc (pas un appel), lequel est remplacé par un caractère espace #x20 dans la valeur normalisée, et ce cas diffère également de celui où la valeur non normalisée contient un appel d'entité dont le texte de remplacement contient un caractère blanc ; lors de son traitement récursif, le caractère blanc est remplacé par un caractère espace #x20 dans la valeur normalisée.

Un processeur non validant DEVRAIENT traiter tous les attributs dont la déclaration n'a pu être lue comme s'ils étaient déclarés avec un type CDATA.

Il y a erreur si une valeur d'attribut contient un appel d'entité dont aucune déclaration n'a été lue.

Voici des exemples de normalisation d'attribut. Soit les déclarations suivantes :

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

Les spécifications d'attribut dans la colonne de gauche apparaîtraient normalisées selon la séquence de caractères de la colonne centrale, si l'attribut était déclaré comme étant du type NMTOKENS, et selon la colonne de droite, si a était déclaré comme étant du type CDATA.

Spécification d'attributa est du type NMTOKENSa est du type CDATA
a="xyz"
x y z
#x20 #x20 x y z
a="&d;&d;A&a;&#x20;&a;B&da;"
A #x20 B
#x20 #x20 A #x20 #x20 #x20 B #x20 #x20
a="&#xd;&#xd;A&#xa;&#xa;B&#xd;&#xa;"
#xD #xD A #xA #xA B #xD #xA
#xD #xD A #xA #xA B #xD #xA

Remarquez que le dernier exemple est invalide (mais bien formé), si a est déclaré de type NMTOKENS.

3.4 Les sections conditionnelles

[Définition : Les sections conditionnelles sont des morceaux du sous-ensemble externe de la déclaration de type de document ou d'entités paramètres externes qui sont incorporés dans la structure logique du DTD, ou exclus de celle-ci, en fonction du mot-clé qui les régit.]

Les sections conditionnelles
[61]   sectConditionnelle   ::=   sectInclude | sectIgnore
[62]   sectInclude   ::=   '<![' S? 'INCLUDE' S? '[' déclSousEnsembleExt ']]>' [CV : Imbrication section conditionnelle/entité paramètre correcte]
[63]   sectIgnore   ::=   '<![' S? 'IGNORE' S? '[' contenuSectIgnore* ']]>'[CV : Imbrication section conditionnelle/entité paramètre correcte]
[64]   contenuSectIgnore   ::=   Ignore ('<![' contenuSectIgnore ']]>' Ignore)*
[65]   Ignore   ::=   Car* - (Car* ('<![' | ']]>') Car*)

Contrainte de validité : Imbrication section conditionnelle/entité paramètre correcte

Si l'une des chaînes <![, [ ou ]]> d'une section conditionnelle est contenue dans le texte de remplacement d'un appel d'entité paramètre, alors elles DOIVENT toutes être contenues par le même texte de remplacement.

Tout comme les sous-ensembles de DTD interne et externe, une section peut contenir une ou plusieurs déclarations complètes, commentaires, instructions de traitement ou sections conditionnelles imbriquées, entrecoupés de caractères blancs.

Si le mot-clé régissant la section conditionnelle est INCLUDE, alors le contenu de celle-ci DOIT être considéré comme faisant partie du DTD. Si le mot-clé est IGNORE, alors le contenu de la section conditionnelle DOIT être considéré comme ne faisant pas logiquement partie du DTD. Si une section conditionnelle avec un mot-clé INCLUDE apparaît au sein d'une section conditionnelle plus grande avec un mot-clé IGNORE, alors les deux sections conditionnelles, celle externe comme celle interne, DOIVENT être ignorées. Le contenu d'une section conditionnelle ignorée DOIT être analysé en ignorant tous les caractères situés après la chaîne [ suivant le mot-clé, sauf les chaînes marquant le début <![ et la fin ]]> de la section conditionnelle, jusqu'à rencontrer la fin de la section conditionnelle correspondante. Les appels d'entité paramètres NE DOIVENT PAS être interprétés dans cette phase du traitement.

Si le mot-clé de la section conditionnelle est un appel d'entité paramètre, alors l'entité paramètre DOIT être remplacée par son contenu avant que le processeur ne décide d'inclure ou d'ignorer la section conditionnelle.

Un exemple :

<!ENTITY % brouillon 'INCLUDE' >
<!ENTITY % versionfinale 'IGNORE' >
<![%brouillon;[
<!ELEMENT livre (commentaires*, titre, corps, compléments?)>
]]>
<![%versionfinale;[
<!ELEMENT livre (titre, corps, compléments?)>
]]>

4 Les structures physiques

[Définition : Un document XML peut se composer d'une ou plusieurs unités de stockage. On les appelle des entités ; elles ont un contenu et sont toutes (sauf l'entité document et le sous-ensemble de DTD externe) identifiées par un nom d'entité.] Chaque document XML possède une entité, appelée l'entité document, qui sert de point de départ pour le processeur XML et peut contenir le document entier.

Les entités peuvent être analysables ou non. [Définition : Le contenu d'une entité analysable est appelé son texte de remplacement ; ce texte est considéré faire partie intégrale du document.]

[Définition : Une entité non analysable est une ressource dont le contenu peut être du texte ou non, et si c'est du texte, peut être autre chose que du XML. À chaque entité non analysable est associée une notation, identifiée par un nom. À part l'obligation faite au processeur XML de mettre à la disposition de l'application les identificateurs de l'entité et de la notation, XML n'exerce aucune contrainte sur le contenu des entités non analysables.]

Les entités analysables sont invoquées par leur nom au moyen d'appels d'entité ; le nom des entités non analysables est fourni par les attributs ENTITY ou ENTITIES.

[Définition : Les entités générales sont des entités destinées à un usage à l'intérieur du contenu du document. Dans cette spécification, les entités générales sont parfois désignées par le terme sans qualificatif entité quand cela ne présente aucune ambiguïté.] [Définition : Les entités paramètres sont des entités analysables utilisées au sein du DTD.] Ces deux types d'entités utilisent des formes d'appel différentes et sont reconnus dans divers contextes. En outre, ils occupent des espaces de nommage différents : une entité paramètre et une entité générale avec un même nom sont deux entités distinctes.

4.1 Les appels de caractère et d'entité

[Définition : Un appel de caractère se rapporte à un caractère particulier dans le jeu de caractères ISO/IEC 10646, par exemple un caractère qui ne soit pas directement accessible depuis les périphériques d'entrée disponibles.]

Les appels de caractère
[66]   AppelCar   ::=   '&#' [0-9]+ ';'
| '&#x' [0-9a-fA-F]+ ';'[CF : Caractère légal]

Contrainte de forme : Caractère légal

Les caractères désignés par des appels de caractères DOIVENT correspondre à la production Car.

Si l'appel de caractère commence par la chaîne &#x, alors les chiffres et lettres jusqu'au caractère de terminaison ; composent une représentation hexadécimale du point de code du caractère dans ISO/IEC 10646. S'il commence simplement par &#, alors les chiffres jusqu'au caractère de terminaison ; composent une représentation décimale du point de code du caractère.

[Définition : Un appel d'entité désigne le contenu d'une entité nommée.] [Définition : Les appels d'entités générales analysables utilisent les caractères esperluette (&) et point-virgule (;) comme délimiteurs.] [Définition : Les appels d'entité paramètre utilisent les caractères symbole pour cent (%) et point-virgule (;) comme délimiteurs.]

Les appels d'entité
[67]   Appel   ::=   AppelEntité | AppelCar
[68]   AppelEntité   ::=   '&' Nom ';'[CF : Entité déclarée]
[CV : Entité déclarée]
[CF : Entité analysable]
[CF : Pas de récursion]
[69]   AppelEP   ::=   '%' Nom ';'[CV : Entité déclarée]
[CF : Pas de récursion]
[CF : Dans le DTD]

Contrainte de forme : Entité déclarée

Dans un document sans DTD, ou dans un document avec seulement un sous-ensemble de DTD interne ne contenant aucun appel d'entité paramètre, ou dans un document avec l'attribut standalone='yes', pour un appel d'entité qui n'apparaît pas dans le sous-ensemble externe ou dans une entité paramètre, alors la valeur de type Nom donnée dans l'appel d'entité DOIT correspondre à celle dans une déclaration d'entité qui n'apparaît pas dans le sous-ensemble externe ou dans une entité paramètre, à l'exception des documents bien formés qui ne sont pas tenus de déclarer les entités suivantes : amp, lt, gt, apos, quot. La déclaration d'une entité générale DOIT précéder tout appel de celle-ci apparaissant dans une valeur implicite dans une déclaration de liste d'attributs.

Remarquez que les processeurs non validant ne sont pas obligés de lire et traiter les déclarations d'entité qui apparaissent dans les entités paramètres ou dans le sous-ensemble externe ; dans ces cas, la règle selon laquelle une entité doit être déclarée n'est une contrainte de forme que si on a standalone='yes'.

Contrainte de validité : Entité déclarée

Dans un document avec un sous-ensemble externe ou des entités paramètres externes, avec standalone='no', la valeur de type Nom donnée dans l'appel d'entité DOIT correspondre à celle dans une déclaration d'entité. Pour des raisons d'interopérabilité, les documents valides DEVRAIENT déclarer les entités amp, lt, gt, apos, quot, selon la forme spécifiée au chapitre 4.6 Les entités prédéfinies. La déclaration d'une entité paramètre DOIT précéder tout appel de celle-ci. De même, la déclaration d'une entité générale DOIT précéder toute déclaration de liste d'attributs contenant une valeur implicite en rapport direct ou indirect avec cette entité générale.

Contrainte de forme : Entité analysable

Un appel d'entité NE DOIT PAS contenir le nom d'une entité non analysable. Les entités non analysables peuvent seulement être appelées dans les valeurs d'attribut déclarées du 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, que ce soit directement ou indirectement.

Contrainte de forme : Dans le DTD

Les appels d'entité paramètre NE DOIVENT PAS apparaître en dehors du DTD.

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

Appuyez sur <touche>inférieur à</touche> (&#x3C;) pour sauvegarder les choix.
Ce document a été préparé le &datedoc; et
il est classé &accréditation;.

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

<!-- déclaration de l'entité paramètre "ISOLat2"... -->
<!ENTITY % ISOLat2
SYSTEM "http://www.xml.com/iso/isolat2-xml.entities" >
<!-- ... maintenant, on peut l'appeler. -->
%ISOLat2;

4.2 Les déclarations d'entité

[Définition : Les entités se déclarent ainsi :]

Les déclarations d'entité
[70]   DéclEntité   ::=   DéclEG | DéclEP
[71]   DéclEG   ::=   '<!ENTITY' S Nom S DéfEntité S? '>'
[72]   DéclEP   ::=   '<!ENTITY' S '%' S Nom S DéfEP S? '>'
[73]   DéfEntité   ::=   ValeurEntité| (IdExterne DéclNdata?)
[74]   DéfEP   ::=   ValeurEntité | IdExterne

La valeur de type Nom identifie l'entité dans un appel d'entité, ou, dans le cas d'une entité non analysable, dans la valeur d'un attribut ENTITY ou ENTITIES. Si la même entité est déclarée plusieurs fois, alors la première déclaration rencontrée est liante ; un processeur XML PEUT, au gré de l'utilisateur, émettre un avertissement lorsque des entités sont déclarées plusieurs fois.

4.2.1 Les entités internes

[Définition : Si la définition d'entité est du type ValeurEntité, alors on appelle l'entité définie une entité interne. Il n'existe pas d'objet de stockage physique distinct et le contenu est donné dans la déclaration.] Remarquez que certains traitements d'appels d'entité et de caractère dans la valeur d'entité littérale peuvent être amenés à produire le texte de remplacement correct : voir le chapitre 4.5 La construction du texte de remplacement de l'entité.

Une entité interne est une entité analysable.

Exemple de déclaration d'entité interne :

<!ENTITY Statut-publication "C'est une version préliminaire de la
spécification.">

4.2.2 Les entités externes

[Définition : Si l'entité n'est pas interne, alors c'est une entité externe déclarée comme suit :]

La déclaration des entités externes
[75]   IdExterne   ::=   'SYSTEM' S LittéralSystème
| 'PUBLIC' S IdPubLittéral S LittéralSystème
[76]   DéclNdata   ::=   S 'NDATA' S Nom[CV : Notation déclarée]

Si la valeur DéclNdata est présente, alors il s'agit d'une entité non analysable générale ; sinon, c'est une entité analysable.

Contrainte de validité : Notation déclarée

La valeur de type Nom DOIT correspondre au nom d'une notation déclarée.

[Définition : La valeur LittéralSystème est appelée l'identificateur système de l'entité. Celui-ci doit être converti en un appel d'adresse URI (comme défini dans le document [IETF RFC 2396], mis à jour par [IETF RFC 2732]), lors de sa résolution afin d'alimenter le processeur XML pour qu'il construise le texte de remplacement de l'entité.] Un identificateur de fragment (commençant par un caractère #) qui ferait partie d'un identificateur système constituerait une erreur. À moins d'informations hors du propos de cette spécification (par exemple, un type d'élément XML spécial défini par un DTD particulier, ou une instruction de traitement définie par une spécification d'application particulière), les adresses URI relatives ne le sont que par rapport à l'emplacement de la ressource au sein de laquelle la déclaration d'entité apparaît. Cet emplacement est défini comme étant l'entité externe contenant le caractère < qui marque le commencement de la déclaration, au moment où celle-ci est interprétée en tant que déclaration. Une adresse URI peut ainsi être relative à l'entité document, à l'entité contenant le sous-ensemble de DTD externe, ou à une autre entité paramètre externe. Les tentatives pour rechercher la ressource identifiée par une adresse URI PEUVENT être redirigées au niveau de l'analyseur (par exemple, dans un module de résolution d'entité) ou à un niveau inférieur (au niveau du protocole, par exemple via une en-tête HTTP Location:). En l'absence d'autres informations au sein de la ressource (hors du propos de cette spécification), l'adresse URI de base d'une ressource est toujours l'adresse de la ressource réelle retournée. En d'autres termes, c'est l'adresse URI de la ressource recherchée après que toute la redirection a eu lieu.

Les identificateurs systèmes (et les autres chaînes XML destinées à une utilisation comme appels d'adresse URI) PEUVENT contenir des caractères qui, selon les documents [IETF RFC 2396] et [IETF RFC 2732], doivent être échappés avant que l'adresse URI puisse être exploitée pour rechercher la ressource référencée. Les caractères à échapper sont les caractères de contrôle de #x0 à #x1F, et #x7F (la plupart d'entre eux ne peuvent apparaître dans XML), le caractères espace #x20 ( ), les délimiteurs #x3C (<), #x3E (>) et #x22 ("), les caractères spéciaux #x7B ({), #x7D (}), #x7C (|), #x5C (\), #x5E (^) et #x60 (`), ainsi que tous les caractères au-delà de #x7F. Comme l'échappement n'est pas toujours une opération complètement réversible, on DOIT l'effectuer seulement quand c'est absolument nécessaire et aussi tard que possible au cours du traitement. En particulier, ni l'opération de conversion d'une adresse URI relative en une adresse absolue ni l'opération de transmission d'un appel d'adresse URI vers un traitement ou vers un composant logiciel chargés de le résoudre ne DEVRAIENT initier d'échappement. Lorsque l'opération d'échappement a effectivement lieu, elle DOIT se dérouler comme suit :

  1. Chaque caractère à échapper est représenté dans le codage UTF-8 [Unicode] par un ou plusieurs octets.

  2. Les octets obtenus sont échappés selon le mécanisme d'échappement des adresses URI (c'est-à-dire, convertis en une expression %HH, dans laquelle HH est la notation hexadécimale de la valeur d'octet).

  3. Le caractère original est remplacé par la séquence de caractères résultante.

[Définition : Outre un identificateur système, un identificateur externe PEUT inclure un identificateur public.] Un processeur XML, lors de sa tentative de recherche du contenu de l'entité, PEUT mettre à profit n'importe quelle combinaison d'identificateurs publics et d'identificateurs systèmes, tout comme d'autres informations hors du propos de cette spécification, pour essayer de générer un appel d'adresse URI alternative. Si le processeur en est incapable, alors il DOIT utiliser l'appel d'adresse URI spécifié dans le littéral de système. Avant d'essayer de trouver une correspondance, toutes les chaînes de caractères blancs dans l'identificateur public DOIVENT être normalisées en un seul caractère espace #x20, et tous les caractères blancs de tête et de queue DOIVENT être supprimés.

Exemples de déclarations d'entités externes :

<!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 Les entités analysables

4.3.1 La déclaration de texte

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

La déclaration de texte
[77]   DéclTexte   ::=   '<?xml' InfoVersion? DéclCodage S? '?>'

La déclaration de texte DOIT être faite littéralement, et non par l'appel d'une entité analysable. La déclaration de texte NE DOIT PAS apparaître ailleurs qu'au début d'une entité analysable externe. La déclaration de texte dans une entité analysable externe ne fait pas partie du texte de remplacement de celle-ci.

4.3.2 Les entités analysables bien formées

L'entité document est bien formée si elle correspond à la production document. Une entité analysable générale externe est bien formée si elle correspond à la production entAnalExt. Toutes les entités paramètres externes sont bien formées par définition.

errata-E14

Les entités analysables externes bien formées
[78]   entAnalExt   ::=   (DéclTexte? contenu) - (Car* CarRestreint Car*)

Une entité analysable générale interne est bien formée si son texte de remplacement correspond à la production contenu. Toutes les entités paramètres internes sont bien formées par définition.

La bonne forme des entités générales entraîne l'imbrication correcte des structures logique et physique dans un document XML ; aucune balise ouvrante, ni balise fermante, ni balise d'élément vide, ni élément, ni commentaire, ni instruction de traitement, ni appel de caractère, ni appel d'entité ne peuvent commencer dans une entité et finir dans une autre.

4.3.3 Le codage des caractères dans les entités

Chaque entité analysable externe dans un document XML PEUT utiliser un codage de caractères différent. Tous les processeurs XML DOIVENT pouvoir lire les entités dans les deux codages UTF-8 et UTF-16. Dans cette spécification, les termes UTF-8 et UTF-16 ne s'appliquent pas aux codages de caractères ayant une quelconque autre étiquette, même si les codages ou étiquettes sont très similaires à UTF-8 ou UTF-16.

Les entités ayant un codage UTF-16 DOIVENT commencer par la marque d'ordre des octets, décrite dans ISO/IEC 10646 [ISO/IEC 10646] ou Unicode [Unicode] (le caractère #xFEFF ESPACE INSÉCABLE SANS CHASSE), tandis que les entités ayant un codage UTF-8 le PEUVENT. C'est une signature de codage qui ne fait partie ni du balisage ni des données textuelles du document XML. Les processeurs XML DOIVENT pouvoir utiliser ce caractère pour distinguer les documents codés en UTF-8 de ceux codés en UTF-16.

Bien qu'un processeur XML soit seulement obligé de reconnaître les entités avec les codages UTF-8 ou UTF-16, il existe d'autres codages dans le monde et on peut attendre des processeurs XML qu'ils puissent lire des entités les utilisant. En l'absence d'informations extérieures sur le codage des caractères (telles que des en-têtes MIME), les entités analysables enregistrées dans un codage autre que UTF-8 ou UTF-16 DOIVENT commencer par une déclaration de texte (voir le chapitre 4.3.1 la déclaration de texte) contenant une déclaration de codage :

La déclaration de codage
[80]   DéclCodage   ::=   S 'encoding' Égal ('"' NomCodage '"' | "'" NomCodage "'" )
[81]   NomCodage   ::=   [A-Za-z] ([A-Za-z0-9._] | '-')*/* Un nom de codage ne contient que des caractères latins */

Dans l'entité document, la déclaration de codage fait partie de la déclaration XML. La valeur de type NomCodage représente le nom du codage employé.

Dans une déclaration de codage, on DEVRAIT utiliser les valeurs "UTF-8", "UTF-16", "ISO-10646-UCS-2" et "ISO-10646-UCS-4" pour les divers codages et transformations de Unicode/ISO/IEC 10646, les valeurs "ISO-8859-1", "ISO-8859-2", ..., "ISO-8859-n" (où n représente le numéro de partie) pour les parties de ISO 8859, et les valeurs "ISO-2022-JP", "Shift_JIS" et "EUC-JP" pour les diverses formes codées de JIS X-0208-1997. Il est RECOMMANDÉ de se référer aux codages de caractères enregistrés (comme jeux de caractères) auprès de l'IANA [IANA-CHARSETS], autres que ceux listés précédemment, au moyen de leurs noms enregistrés ; les autres codages DEVRAIENT utiliser des noms commençant par le préfixe x-. Les processeurs XML DEVRAIENT comparer les noms de codage de caractères sans tenir compte de la casse et ils DEVRAIENT interpréter un nom enregistré auprès de l'IANA soit comme étant le codage enregistré avec ce nom, soit le traiter comme étant inconnu (les processeurs ne sont pas obligés, bien sûr, de reconnaître tous les codages enregistrés auprès de l'IANA).

En l'absence d'information fournie par un protocole de transport externe (par exemple, HTTP ou MIME), présenter une entité avec une déclaration de codage au processeur XML dans un codage différent de celui nommé dans la déclaration, ou présenter une entité ne qui commence ni par une marque d'ordre des octets ni par une déclaration de codage indiquant l'utilisation d'un codage autre que UTF-8, constitue une erreur fatale. Remarquez, puisque le codage ASCII est un sous-ensemble de UTF-8, que les entités ASCII ordinnaires ne sont pas strictement tenues à une déclaration de codage.

L'apparition d'une valeur de type DéclTexte ailleurs qu'au début d'une entité externe constitue une erreur fatale.

Lorsqu'un processeur XML rencontre une entité avec un codage qu'il est incapable de traiter, c'est une erreur fatale. De même, lorsqu'une entité XML est censée être dans un certain codage (par défaut, au moyen d'une déclaration de codage ou d'un protocole de niveau supérieur) et contient pourtant des séquences d'octets illégales dans ce codage. Plus particulièrement, si une entité codée en UTF-8 contient une quelconque séquence d'unités de code irrégulière, comme défini dans Unicode [Unicode]. À moins qu'un protocole de niveau supérieur ne détermine le codage, c'est aussi une erreur fatale si une entité XML ne contient aucune déclaration de codage et si son contenu n'est pas un code UTF-8 ou UTF-16 légal.

Exemples de déclarations de texte contenant des déclarations de codage :

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

4.3.4 L'information de version dans les entités

Chaque entité, y compris l'entité document, peut se déclarer séparément comme appartenant à XML 1.0 ou XML 1.1. La déclaration de version apparaissant dans l'entité document détermine la version du document dans son entier. Un document XML 1.1 peut invoquer des entités externes XML 1.0, de sorte qu'il n'est pas nécessaire sinon de maintenir des versions d'entités externes en double, notamment des sous-ensembles de DTD externes. Toutefois, dans ce cas, les règles de XML 1.1 s'appliquent au document entier.

Si une entité (y compris l'entité document) n'est pas étiquetée d'un numéro de version, alors elle est traitée comme si elle avait une étiquette de version 1.0.

4.4 Le traitement des entités et des appels par le processeur XML

Le tableau ci-dessous résume les circonstances dans lesquelles peuvent apparaître les appels de caractère, les appels d'entité et les invocations d'entités non analysables, et le comportement OBLIGATOIRE du processeur XML dans chaque cas. Les étiquettes dans la colonne de gauche décrivent le contexte de reconnaissance :

Appel dans un contenu

c'est un appel n'importe où après la balise ouvrante et avant la balise fermante d'un élément ; cela correspond au non-terminal contenu.

Appel dans une valeur d'attribut

c'est un appel depuis l'intérieur soit de la valeur d'un attribut dans une balise ouvrante, soit d'une valeur implicite dans une déclaration d'attribut ; cela correspond au non-terminal ValeurAtt.

Comme valeur d'attribut

c'est une valeur de type Nom, et non un appel, qui apparaît soit comme valeur d'un attribut déclaré du type ENTITY, soit comme l'une des unités lexicales, séparées par des espaces, dans la valeur d'un attribut déclaré du type ENTITIES.

Appel dans une valeur d'entité

c'est un appel à l'intérieur de la valeur d'entité littérale d'un paramètre ou d'une entité interne, dans la déclaration d'entité ; cela correspond au non-terminal ValeurEntité.

Appel dans un DTD

c'est un appel soit à l'intérieur des sous-ensembles interne ou externe du DTD, mais hors des types ValeurEntité, ValeurAtt, IT, Commentaires, LittéralSystème et IdPubLittéral, soit dans le contenu d'une section conditionnelle ignorée (voir le chapitre 3.4 Les sections conditionnelles).

Type d'entitéCaractère
Entité paramètreEntité générale interneEntité générale analysable externeEntité non analysable
Appel dans un contenuNon reconnuInclusInclus si validationInterditInclus
Appel dans une valeur d'attributNon reconnuInclus en littéralInterditInterditInclus
Comme valeur d'attributNon reconnuInterditInterditNotifierNon reconnu
Appel dans une valeur d'entitéInclus en littéralNon interprétéNon interprétéErreurInclus
Appel dans un DTDInclus comme entité paramètreInterditInterditInterditInterdit

4.4.1 Non reconnu

Le caractère % n'a aucune signification particulière hors du DTD ; ce qui seraient des appels d'entité paramètre dans le DTD ne sont ainsi pas reconnus dans le contenu. De la même manière, les noms des entités non analysables ne sont pas reconnus sauf lorsqu'ils apparaissent dans la valeur d'un attribut correctement déclaré.

4.4.2 Inclus

[Définition : Une entité est incluse lorsque son texte de remplacement est ramené et traité, à l'endroit de l'appel en question, comme s'il faisait partie du document à l'endroit où l'appel a été reconnu.] Le texte de remplacement PEUT contenir à la fois des données textuelles et (hormi les entités paramètres) du balisage, qui DOIT s'interpréter de la manière habituelle. (La chaîne AT&amp;T; se développe en AT&T; et le caractère esperluette (&) restant n'est pas reconnu comme délimiteur d'appel d'entité.) Un appel de caractère est inclus lorsque le caractère désigné est traité à la place de l'appel en question.

4.4.3 Inclus si validation

Lorsqu'un processeur XML reconnaît un appel d'entité analysable, dans un contexte de validation du document, il DOIT inclure son texte de remplacement. S'il s'agit d'une entité externe et que le processeur n'essaye pas de valider le document XML, le processeur PEUT, mais ce n'est pas obligatoire, inclure le texte de remplacement de l'entité. Si un processeur non validant n'inclut pas le texte de remplacement, alors il DOIT informer l'application qu'il a reconnu l'entité, mais ne l'a pas lue.

Cette règle se fonde sur le fait que l'inclusion automatique offerte par le mécanisme des entités SGML et XML, conçu principalement pour les besoins de modularité de l'édition, n'est pas forcément appropriée pour d'autres applications, en particulier la navigation dans les documents. Les navigateurs, par exemple, lorsqu'ils rencontrent un appel d'entité analysable externe, pourraient choisir de produire une indication visuelle de la présence de l'entité et ne la rechercher, pour l'afficher, que sur demande.

4.4.4 Interdit

Les situations suivantes sont interdites et constituent des erreurs fatales :

  • la présence d'un appel d'entité non analysable, sauf dans une valeur de type ValeurEntité dans une déclaration d'entité.

  • la présence d'un quelconque appel de caractère ou d'entité générale dans le DTD, sauf à l'intérieur de valeurs de type ValeurEntité ou ValeurAtt.

  • un appel d'entité externe dans une valeur d'attribut.

4.4.5 Inclus en littéral

Lorsqu'un appel d'entité apparaît dans une valeur d'attribut, ou un appel d'entité paramètre dans une valeur d'entité littérale, son texte de remplacement DOIT être traité à la place de l'appel en question comme s'il faisait partie du document à l'endroit où l'appel a été reconnu, hormi le fait que les caractères guillemet simple (') et guillemet double (") dans ce texte de remplacement DOIVENT, d'une part, toujours être traités comme des données textuelles normales et NE DOIVENT PAS, d'autre part, terminer le littéral. Par exemple, cet extrait-ci est bien formé :

<!ENTITY % OuiNon '"Oui"' >
<!ENTITY CeQuIlaDit "Il a dit %OuiNon;" >

Alors que celui-là ne l'est pas :

<!ENTITY FinAtt "27'" >
<élément attribut='a-&FinAtt;>

4.4.6 Notifier

Lorsque le nom d'une entité non analysable apparaît comme unité lexicale dans la valeur d'un attribut avec un type déclaré ENTITY ou ENTITIES, un processeur validant DOIT informer l'application des identificateurs systèmes et publics (le cas échéant) des entités et sa notation associée.

4.4.7 Non interprété

Lorsqu'un appel d'entité générale apparaît dans la valeur ValeurEntité dans une déclaration d'entité, alors on DOIT l'ignorer et la laisser telle quelle.

4.4.8 Inclus comme entité paramètre

De même que pour les entités analysables externes, les entités paramètres ont seulement besoin d'être incluses en cas de validation. Lorsqu'une entité paramètre est reconnue dans le DTD puis incluse, son texte de remplacement DOIT grossir de deux caractères espace #x20, l'un accolé en tête l'autre en queue ; la raison : contraindre le texte de remplacement des entités paramètres à contenir un nombre entier d'unités lexicales grammaticales dans le DTD. Ce comportement NE DOIT PAS s'appliquer aux appels d'entité paramètre au sein de valeurs d'entité ; ce cas est décrit au chapitre 4.4.5 Inclus en littéral.

4.4.9 Erreur

L'apparition d'un appel d'entité non analysable dans une valeur de type ValeurEntité dans une déclaration d'entité constitue une erreur.

4.5 La construction du texte de remplacement d'une entité

Il est utile de distinguer deux formes de la valeur d'entité dans la discussion sur le traitement des entités. [Définition : Pour une entité interne, la valeur d'entité littérale est la chaîne entre guillemets réellement présente dans la déclaration d'entité, correspondant au non-terminal ValeurEntité.] [Définition : Pour une entité externe, la valeur d'entité littérale est le texte exact contenu dans l'entité.] [Définition : Pour une entité interne, le texte de remplacement est le contenu de l'entité, après remplacement des appels de caractère et des appels d'entité paramètre.] [Définition : Pour une entité externe, le texte de remplacement est le contenu de l'entité, après suppression, le cas échéant, de la déclaration de texte (en laissant les caractères blancs autour) mais sans remplacement des éventuels appels de caractère ou d'entité paramètre.]

La valeur d'entité littérale, telle qu'elle apparaît 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 entièrement contenus dans la valeur d'entité littérale. Le texte de remplacement réel inclus (ou inclus en littéral), comme décrit précédemment, DOIT contenir le texte de remplacement de toute entité paramètre appelée et DOIT contenir les caractères appelés, à la place des éventuels appels de caractère dans la valeur d'entité littérale ; toutefois, les appels d'entité générale DOIVENT être laissés tels quels, non développés. Soit, par exemple, les déclarations suivantes :

<!ENTITY % editeur  "&#xc9;ditions Gallimard" >
<!ENTITY   droits   "Tous droits réservés" >
<!ENTITY   ouvrage  "La Peste : Albert Camus,
&#xA9; 1947 %editeur;. &droits;" >

En ce cas, le texte de remplacement de l'entité ouvrage est :

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

L'appel d'entité générale &droits; serait développé, si l'appel &ouvrage; apparaissait dans le contenu du document ou dans une valeur d'attribut.

Ces règles simples peuvent s'imbriquer de manière complexe ; voir l'explication détaillée d'un exemple difficile dans l'annexe C Le développement des appels d'entité et de caractère.

4.6 Les entités prédéfinies

[Définition : Les appels d'entité et de caractère PEUVENT tous deux s'utiliser pour échapper les caractères inférieur à (<), esperluette (&) et d'autres délimiteurs. Un jeu d'entités générales (amp, lt, gt, apos, quot) est défini dans ce but. On PEUT aussi employer des appels numériques de caractère ; sitôt reconnues, ces entités sont immédiatement développées et DOIVENT être traitées comme des données textuelles, on PEUT donc employer les appels numériques de caractère &#60; et &#38; pour échapper les caractères < et & quand ils apparaissent dans des données textuelles.]

Tous les processeurs XML DOIVENT reconnaître ces entités, que celles-ci soient déclarées ou non. Pour des raisons d'interopérabilité, les documents XML valides DEVRAIENT déclarer ces entités, comme n'importe quelle autre, avant leur utilisation. Si les entités lt ou amp sont déclarées, elles DOIVENT l'être comme entités internes dont le texte de remplacement est un appel de caractère vers le caractère à échapper respectif (caractère inférieur à (<) ou esperluette (&) ; le double échappement est OBLIGATOIRE pour ces entités, pour que les appels à celles-ci donnent un résultat bien formé. Si les entités gt, apos ou quot sont déclarées, elles DOIVENT l'être comme entités internes dont le texte de remplacement est le seul caractère à échapper (ou un appel de caractère à ce caractère : dans ce cas, le double échappement est OPTIONNEL mais sans inconvénient). Par exemple :

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

4.7 Les déclarations de notation

[Définition : Les notations identifient, par leur nom, le format des entités non analysables, le format des éléments qui portent un attribut de notation ou l'application visée par une instruction de traitement.]

[Définition : Les déclarations de notation fournissent un nom de notation, à utiliser dans les déclarations d'entité et de liste d'attributs et dans les définitions d'attribut, ainsi qu'un identificateur externe de notation qui permet à un processeur XML, ou son application cliente, de localiser un module d'extension capable de traiter les données dans la notation en question.]

Les déclarations de notation
[82]   DéclNotation   ::=   '<!NOTATION' S Nom S (IdExterne | IDPublic) S? '>'[CV : Nom de notation unique]
[83]   IDPublic   ::=   'PUBLIC' S IdPubLittéral

Contrainte de validité : Nom de notation unique

Une valeur donnée de type Nom NE DOIT PAS être déclarée dans plusieurs déclarations de notation.

Les processeurs XML DOIVENT fournir aux applications le nom et l'identificateur externe (ou les identificateurs) de toute notation déclarée et appelée dans une valeur d'attribut, une définition d'attribut ou une déclaration d'entité. Ils PEUVENT, en outre, résoudre l'identificateur externe vers l'identificateur système, le nom de fichier ou d'autres informations nécessaires, permettant à l'application d'appeler un processeur pour les données dans la notation décrite. (Toutefois, ce n'est pas une erreur si les documents XML déclarent et appellent des notations pour lesquelles il n'existe pas d'applications spécifiques sur le système où le processeur XML ou l'application résident.)

4.8 L'entité document

[Définition : L'entité document tient lieu de racine pour l'arbre d'entité et de point de départ pour un processeur XML.] Cette spécification ne dit pas comment le proceseur XML doit trouver l'entité document ; au contraire des autres entités, l'entité document n'a pas de nom et pourrait très bien apparaître dans le flux alimentant un processeur sans identification du tout.

5 La conformité

5.1 Les processeurs validants et non validants

Les processeurs XML conformes se répartissent en deux catégories : les processeurs validants et ceux non validants.

Les processeurs validants comme non validants DOIVENT signaler les violations aux contraintes de forme de cette spécification survenant dans le contenu de l'entité document et dans n'importe quelle entité analysable lue.

[Définition : Les processeurs validants DOIVENT, au gré de l'utilisateur, signaler les violations aux contraintes exprimées par les déclarations dans le DTD et les manquements aux contraintes de validité données dans cette spécification.] Pour ce faire, les processeurs XML validants DOIVENT lire et traiter le DTD entier et toutes les entités analysables externes appelées dans le document.

Les processeurs non validants ont seulement OBLIGATION de vérifier la bonne forme de l'entité document, y compris le sous-ensemble de DTD interne en entier. [Définition : Bien qu'ils ne soient pas obligés de vérifier la validité du document, ils sont OBLIGÉs de traiter toutes les déclarations lues dans le sous-ensemble de DTD interne et dans toute entité paramètre reconnue, jusqu'au premier appel d'entité paramètre non reconnu ; c'est-à-dire, qu'ils DOIVENT utiliser les informations de ces déclarations pour normaliser les valeur d'attribut, inclure le texte de remplacement des entités internes et fournir les valeurs d'attribut implicites.] Hormis le cas d'une déclaration standalone='yes', ils NE DOIVENT PAS traiter les déclarations d'entité ou les déclarations de liste d'attributs rencontrées après un appel d'entité paramètre non lu, car l'entité pourrait contenir des déclarations d'annulation ; inversement, si standalone='yes', les processeurs DOIVENT traiter ces déclarations.

Remarquez que, lors du traitement de documents invalides par un processeur non validant, l'application est susceptible de recevoir des informations incohérentes. Plusieurs conditions d'unicité dans le document ne sont peut-être pas respectées, par exemple, un même id pour plusieurs éléments, des déclarations d'élément en double, ou des notations avec le même nom, etc. Auxquels cas, le comportement du processeur, en ce qui concerne la transmission de ces informations à l'application, n'est pas défini.

Les processeurs XML 1.1 DOIVENT être capables de traiter les documents XML 1.0 comme les documents XML 1.1. Les logiciels qui produisent du code XML DEVRAIENT générer des documents XML 1.0, à moins que des caractéristiques spécifiques à XML 1.1 ne soient nécessaires.

5.2 L'utilisation des processeurs XML

Le fonctionnement d'un processeur XML est très prévisible  il doit lire chaque partie d'un document et en signaler les violations de forme et de validité. La tâche est moindre pour un processeur non validant : il ne doit lire rien d'autre que l'entité document. Il en découle deux conséquences qui peuvent se révéler importantes pour les utilisateurs des processeurs XML :

  • Certaines erreurs de forme, notamment celles qui ont trait à la lecture des entités externes, peuvent ne pas être détectées par un processeur non validant. Par exemple, c'est le cas des contraintes intitulées Entité déclarée, Entité analysable et Pas de récursion, ainsi que certains des cas décrits comme Interdit au chapitre 4.4 Le traitement des entités et des appels par un processeur XML.

  • Les informations transmises par le processeur à l'application peuvent varier, selon que le processeur lise des entités paramètres et des entités externes. Par exemple, un validateur non validant peut échouer à normaliser des valeurs d'attribut, à inclure le texte de remplacement des entités internes ou à fournir des valeurs d'attribut implicites, lesquelles opérations sont dépendantes de la lecture des déclarations dans les entités externes ou les entités paramètres.

Pour une fiabilité maximum des échanges entre des processeurs XML différents, les applications utilisant des processeurs non validants NE DEVRAIENT PAS compter sur les comportements non obligatoires de ces processeurs. Les applications qui nécessitent des facilités de DTD non liées à la validation (telle que la déclaration des attributs implicites et des entités internes qui sont spécifiées, ou peuvent l'être, dans des entités externes) DEVRAIENT néanmoins utiliser des processeurs XML validants.

6 La notation

On donne la grammaire formelle de XML dans cette spécification au moyen d'une notation simple dans une forme Backus-Naur développée (EBNF). Chaque règle de la grammaire définit un seul symbole, suivant le modèle :

symbole ::= expression

Les symboles s'écrivent avec une lettre initiale en majuscule quand ils sont le symbole de départ d'un langage régulier, sinon avec une lettre initiale en minuscule. Les chaînes littérales sont entre guillemets.

Dans la partie de droite d'une règle, on emploie les expressions suivantes pour rechercher les chaînes composées d'un ou plusieurs caractères :

#xN

N représente un entier hexadécimal ; l'expression du caractère dont le numéro (point de code) dans ISO/IEC 10646 est N. Le nombre de zéros initiaux dans la forme #xN n'est pas significatif.

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

correspond à toute valeur Car dans l'intervalle (ou les intervalles) indiqué (inclusivement).

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

correspond à toute valeur Car parmi les caractères énumérés. On peut mélanger les énumérations et les intervalles dans un même jeu de crochets.

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

correspond à toute valeur Car en dehors de l'intervalle indiqué.

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

correspond à toute valeur Car ne faisant pas partie des caractères donnés. On peut mélanger les énumérations et les intervalles de valeurs interdites dans un même jeu de crochets.

"chaîne"

correspond à une chaîne littérale identique à celle donnée entre les guillemets doubles.

'chaîne'

correspond à une chaîne littérale identique à celle donnée entre les guillemets simples.

On peut combiner ces symboles pour filtrer des motifs plus complexes, comme suit, où A et B représentent des expressions simples :

(expression)

le paramètre expression est traité comme une unité et peut se combiner comme décrit dans cette liste.

A?

correspond à la valeur A ou à rien : A optionnel.

A B

correspond à A suivi de B. Cet opérateur a une priorité plus élevée que l'alternance ; ainsi A B | C D est identique à (A B) | (C D).

A | B

correspond à A ou B.

A - B

correspond à toute chaîne identique à A mais pas à B.

A+

correspond à une ou plusieurs occurrences de A. La concaténation a une priorité plus élevée que l'alternance ; ainsi A+ | B+ est identique à (A+) | (B+).

A*

correspond à zéro occurence ou plus de A. La concaténation a une priorité plus élevée que l'alternance ; ainsi A* | B* est identique à (A*) | (B*).

D'autres notations employées dans les productions :

/* ... */

un commentaire.

[ CF : ... ]

une contrainte de forme : elle identifie par son nom une contrainte sur les documents bien formés associés à une production.

[ CV : ... ]

une contrainte de validité : elle identifie par son nom une contrainte sur les documents valides associés à une production.

A Références

A.1 Références normatives

IANA-CHARSETS
(Internet Assigned Numbers Authority) Les noms officiels des jeux de caractères, ed. Keld Simonsen et al. (Voir http://www.iana.org/assignments/character-sets.)
IETF RFC 2119
IETF (Internet Engineering Task Force). RFC 2119 : Les mots-clés à utiliser dans les RFC pour indiquer les niveaux d'obligation. Scott Bradner, 1997. (Voir http://www.ietf.org/rfc/rfc2119.txt.)
IETF RFC 2396
IETF (Internet Engineering Task Force). RFC 2396 : Les identificateurs de ressource uniformes (URI) : syntaxe générique. T. Berners-Lee, R. Fielding, L. Masinter. 1998. (Voir http://www.ietf.org/rfc/rfc2396.txt.)
IETF RFC 2732
IETF (Internet Engineering Task Force). RFC 2732 : Le format des adresses IPv6 littérales dans les URL. R. Hinden, B. Carpenter, L. Masinter. 1999. (Voir http://www.ietf.org/rfc/rfc2732.txt.)
IETF RFC 3066
IETF (Internet Engineering Task Force). RFC 3066 : Les étiquettes d'identification des langues, ed. H. Alvestrand. 2001. (Voir http://www.ietf.org/rfc/rfc3066.txt.)
ISO/IEC 10646
ISO (International Organization for Standardization). ISO/IEC 10646-1:2000. Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 1: Architecture and Basic Multilingual Plane et ISO/IEC 10646-2:2001. Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 2: Supplementary Planes, tel que, de temps en temps, amendé, remplacé par une nouvelle édition ou augmenté par l'ajout de nouvelles parties. [Geneva]: International Organization for Standardization. (Voir http://www.iso.ch pour la dernière version.)
Unicode
The Unicode Consortium. The Unicode Standard, Version 4.0. Reading, Mass.: Addison-Wesley, 2003, tel que mis à jour de temps en temps par la publication de nouvelles versions. (Voir http://www.unicode.org/unicode/standard/versions pour la dernière version et des informations supplémentaires sur les versions du standard et de la base de données de caractère Unicode).
XML-1.0
W3C. Le langage de balisage extensible (XML) 1.0 (troisième édition). Tim Bray, Jean Paoli, C.M. Sperberg-McQueen, Eve Maler, François Yergeau (rédacteurs). (Voir http://www.w3.org/TR/REC-xml.)

A.2 Autres références

Aho/Ullman
Aho, Alfred V., Ravi Sethi, and Jeffrey D. Ullman. Compilers: Principles, Techniques, and Tools. Reading: Addison-Wesley, 1986, rpt. corr. 1988.
Brüggemann-Klein
Brüggemann-Klein, Anne. Formal Models in Document Processing. Habilitationsschrift. Faculty of Mathematics at the University of Freiburg, 1993. (See ftp://ftp.informatik.uni-freiburg.de/documents/papers/brueggem/habil.ps.)
Brüggemann-Klein and Wood
Brüggemann-Klein, Anne, and Derick Wood. Deterministic Regular Languages. Universität Freiburg, Institut für Informatik, Bericht 38, Oktober 1991. Extended abstract in A. Finkel, M. Jantzen, Hrsg., STACS 1992, S. 173-184. Springer-Verlag, Berlin 1992. Lecture Notes in Computer Science 577. Full version titled One-Unambiguous Regular Languages in Information and Computation 140 (2): 229-253, February 1998.
Charmod
Brouillon fonctionnel du W3C. Le modèle de caractère du World Wide Web 1.0. Martin J. Dürst, François Yergeau, Richard Ishida, Misha Wolf, Tex Texin. (Voir http://www.w3.org/TR/2003/WD-charmod-20030822/.)
Clark
James Clark. Une comparaison de SGML et de XML. (Voir http://www.w3.org/TR/NOTE-sgml-xml-971215.)
IANA-LANGCODES
(Internet Assigned Numbers Authority) Le registre des étiquettes de langue, ed. Keld Simonsen et al. (Voir http://www.iana.org/assignments/language-tags.)
IETF RFC 2141
IETF (Internet Engineering Task Force). RFC 2141 : La syntaxe URN, ed. R. Moats. 1997. (Voir http://www.ietf.org/rfc/rfc2141.txt.)
IETF RFC 3023
IETF (Internet Engineering Task Force). RFC 3023 : Les types de média XML. eds. M. Murata, S. St.Laurent, D. Kohn. 2001. (Voir http://www.ietf.org/rfc/rfc3023.txt.)
IETF RFC 2781
IETF (Internet Engineering Task Force). RFC 2781 : UTF-16, un codage de ISO 10646, ed. P. Hoffman, F. Yergeau. 2000. (Voir http://www.ietf.org/rfc/rfc2781.txt.)
ISO 639
(International Organization for Standardization). ISO 639:1988 (E). Code for the representation of names of languages. [Geneva]: International Organization for Standardization, 1988.
ISO 3166
(International Organization for Standardization). ISO 3166-1:1997 (E). Codes for the representation of names of countries and their subdivisions — Part 1: Country codes [Geneva]: International Organization for Standardization, 1997.
ISO 8879
ISO (International Organization for Standardization). ISO 8879:1986(E). Information processing — Text and Office Systems — Standard Generalized Markup Language (SGML). First edition — 1986-10-15. [Geneva]: International Organization for Standardization, 1986.
ISO/IEC 10744
ISO (International Organization for Standardization). ISO/IEC 10744-1992 (E). Information technology — Hypermedia/Time-based Structuring Language (HyTime). [Geneva]: International Organization for Standardization, 1992. Extended Facilities Annexe. [Geneva]: International Organization for Standardization, 1996.
WEBSGML
ISO (International Organization for Standardization). ISO 8879:1986 TC2. Information technology — Document Description and Processing Languages. [Geneva]: International Organization for Standardization, 1998. (Voir http://www.sgmlsource.com/8879/n0029.htm.)
XML Names
Tim Bray, Dave Hollander, et Andrew Layman, rédacteurs. Les espaces de nommage dans XML vf. Textuality, Hewlett-Packard et Microsoft. World Wide Web Consortium, 1999. (Voir http://www.w3.org/TR/REC-xml-names/.)

B Les définitions de la normalisation de caractère

Cette annexe contient les définitions nécessaires à la normalisation des caractères. Pour des informations détaillées et des exemples, voir [Charmod].

[Définition : Un texte est dit dans une forme de codage Unicode s'il est codé en UTF-8, UTF-16 ou UTF-32.]

[Définition : Un codage ancien désigne un codage de caractères qui ne dérive pas de Unicode.]

[Définition : Un transcodeur de normalisation est un programme qui effectue une conversion depuis un codage ancien vers une forme de codage Unicode et s'assure que le résultat est dans la forme de normalisation C de Unicode (voir UAX #15 [Unicode]).]

[Définition : Un caractère d'échappement est un dispositif syntaxique, défini dans un langage de balisage ou de programmation, qui permet l'une ou plusieurs des actions suivantes :]

  1. exprimer des caractères significatifs pour la syntaxe tout en ne tenant pas compte de leur signification dans la syntaxe du langage, ou

  2. exprimer des caractères non représentables dans le codage de caractères choisi pour une instance du langage, ou

  3. exprimer des caractères en général, sans utiliser les codes de caractère correspondants.

[Définition : Un texte certifié est un texte qui satisfait à au moins une des conditions suivantes :]

  1. une inspection a confirmé que le texte est dans une forme normalisée 

  2. le composant de traitement de texte source est identifié et connu pour ne produire que du texte normalisé.

[Définition : Pour les besoins de cette spécification, un texte est normalisé selon Unicode s'il est dans une forme de codage Unicode et s'il est dans la forme de normalisation C de Unicode, conformément à une version de l'annexe #15 du standard Unicode : cela correspond aux formes de normalisation Unicode [Unicode] au moins aussi récentes que la version la plus ancienne du standard Unicode contenant tous les caractères effectivement présents dans le texte, mais non antérieures à la version 3.2.]

[Définition : Un texte est une inclusion normalisée si :]

  1. le texte est normalisé selon Unicode et ne contient aucun caractère d'échappement ou d'inclusion dont le développement ferait que le texte ne serait plus normalisé selon Unicode, ou

  2. le texte est dans un codage ancien et, s'il devait être transcodé dans une forme de codage Unicode par un transcodeur de normalisation, le texte résultant satisferait la clause 1 précédente.

[Définition : Un caractère composant correspond à l'un ou aux deux caractères suivants :]

  1. le deuxième caractère dans la table de décomposition canonique d'un certain composite primaire (comme défini dans la section D3 de UAX #15 [Unicode])

  2. ou d'une classe combinatoire canonique avec chasse (comme défini dans Unicode [Unicode]).

[Définition : Un texte est complètement normalisé si :]

  1. le texte est dans une forme de codage Unicode, ou est une inclusion normalisée, et aucune des structures concernées composant le texte ne commence par un caractère composant, ou un caractère d'échappement représentant un caractère composant, ou

  2. le texte est dans un codage ancien et, s'il devait être transcodé dans une forme de codage Unicode par un transcodeur de normalisation, le texte résultant satisferait la clause 1 précédente.

C Le développement des appels d'entité et de caractère (non normatif)

Cette annexe contient quelques exemples illustrant la séquence de reconnaissance puis développement des appels d'entité et de caractère, comme défini au chapitre 4.4 Le traitement des entités et des appels par le processeur XML.

Si le DTD contient la déclaration suivante :

<!ENTITY exemple "<p>On peut échapper une esperluette (&#38;#38;)
numériquement (&#38;#38;#38;) ou au moyen d'une entité générale
(&amp;amp;).</p>" >

Alors le processeur XML reconnaîtra les appels de caractère, lors de l'analyse de la déclaration d'entité, et les résoudra avant d'enregistrer la chaîne suivante comme valeur de l'entité exemple :

<p>On peut échapper une esperluette (&#38;)
numériquement (&#38;#38;) ou au moyen d'une entité générale
(&amp;amp;).</p>

Dans le document, un appel &exemple; entraînera une réanalyse du texte, au cours de laquelle les balises ouvrante et fermante de l'élément p seront reconnues puis les trois appels reconnus et développés, aboutissant au contenu de l'élément p suivant (seulement des données, pas de délimiteurs ni de balisage) :

On peut échapper une esperluette (&)
numériquement (&#38;) ou au moyen d'une entité générale
(&amp;).

Un exemple plus complexe illustrera les règles et leurs plein effets. Dans l'exemple suivant, les numéros de ligne n'apparaissent que pour référence.

1 <?xml version='1.1'?>
2 <!DOCTYPE test [
3 <!ELEMENT test (#PCDATA) >
4 <!ENTITY % xx '&#37;zz;'>
5 <!ENTITY % zz '&#60;!ENTITY surprenante "pleine de surprises">' >
6 %xx;
7 ]>
8 <test>Cet exemple illustre une méthode &surprenante;.</test>

Voici le résultat produit :

D Les modèles de contenu déterministes (non normatif)

Comme remarqué au chapitre 3.2.1 Le contenu d'éléments, il est obligatoire que les modèles de contenu dans les déclarations de type d'élément soient déterministes. Cette obligation tient à des raisons de compatibilité avec SGML (qui dit des modèles de contenu déterministes qu'ils sont univoques) ; les processeurs XML inspirés de systèmes SGML peuvent étiqueter les modèles de contenu non déterministes comme erronnés.

Par exemple, le modèle de contenu ((b, c) | (b, d)) est non déterministe, parce que, pour un objet initial b donné, le processeur XML ne peut pas savoir quel b du modèle est retenu sans regarder au préalable quel élément suit le b en question. Auquel cas, les deux appels de b peuvent fusionner en un seul, transformant le modèle en (b, (c | d)). Un objet initial b correspond maintenant clairement à un seul nom dans le modèle de contenu. Le processeur n'a pas besoin d'effectuer une analyse préalable pour déterminer la suite, puisque soit l'objet c, soit d sera accepté.

D'une manière plus formelle : on peut construire un automate à états finis à partir du modèle de contenu au moyen des algorithmes standards, par exemple, l'algorithme 3.5 de la section 3.9 de Aho, Sethi et Ullman [Aho/Ullman]. Dans nombre d'algorithmes de ce genre, un ensemble successif est construit pour chaque position dans l'expression régulière (c'est-à-dire, chaque nœud terminal dans l'arbre syntaxique de l'expression régulière) ; si une position quelconque possède un ensemble successif dans lequel plusieurs positions suivantes sont étiquetées avec le même nom de type d'élément, alors le modèle de contenu est erronné et peut être signalé comme une erreur.

Il existe des algorithmes qui permettent la réduction automatique de beaucoup de modèles de contenu non déterministes, mais pas tous, en modèles déterministes équivalents ; voir Brüggemann-Klein 1991 [Brüggemann-Klein].

E L'autodétection des codages de caractères (non normatif)

La déclaration de codage XML fonctionne comme une étiquette interne sur chaque entité, indiquant quel codage de caractères est en vigueur. Toutefois, avant qu'un processeur XML puisse lire l'étiquette interne, il doit apparemment savoir le codage de caractères utilisé, ce que l'étiquette interne essaye justement de faire. Dans le cas général, c'est une situation sans issue. Mais elle n'est pas complètement désespérée en XML, dans la mesure où XML réduit le cas général de deux façons : chaque implémentation n'est censée gérer qu'un ensemble fini de codages de caractères et la déclaration de codage XML est limitée en position et en contenu afin de permettre l'autodétection du codage de caractères utilisé dans chaque entité dans les cas normaux. Dans de nombreuses situations, d'autres sources d'information sont également disponibles en plus du flux de données XML en question. On peut distinguer deux cas, selon que l'entité XML est présentée au processeur avec ou bien sans information complémentaire (externe). Nous considérons d'abord ce dernier cas.

E.1 La détection sans information de codage externe

Comme chaque entité XML non accompagnée d'information de codage externe et non codée en UTF-8 ou UTF-16 doit commencer par une déclaration de codage XML, dans laquelle les premiers caractères doivent être <?xml, tout processeur conforme peut détecter, au bout de deux ou quatre octets lus, lequel des cas suivants s'applique. Pour lire cette liste, il est peut-être utile de savoir que, dans UCS-4, le caractère < correspond à #x0000003C et ? à #x0000003F, et que la marque d'ordre des octets nécessaire pour les flux de données UTF-16 est #xFEFF. On utilise la notation ## pour indiquer une valeur d'octet quelconque, à part que deux ## consécutifs ne peuvent pas être tous deux égaux à 00.

Avec une marque d'ordre des octets (BOM):

00 00 FE FFUCS-4, machine gros-boutiste (ordre 1234)
FF FE 00 00UCS-4, machine petit-boutiste (ordre 4321)
00 00 FF FEUCS-4, ordre d'octet inhabituel (2143)
FE FF 00 00UCS-4, ordre d'octet inhabituel (3412)
FE FF ## ##UTF-16, gros-boutiste
FF FE ## ##UTF-16, petit-boutiste
EF BB BFUTF-8

Sans marque d'ordre des octets :

00 00 00 3C UCS-4 ou un autre codage avec une unité de code 32-bit et des caractères ASCII codés comme valeurs ASCII, ayant respectivement des ordres d'octet gros-boutiste (1234), petit-boutiste (4321) et deux ordres inhabituels (2143 et 3412). La déclaration de codage doit être lue afin de déterminer quel codage entre UCS-4 ou un autre codage 32-bit s'applique.
3C 00 00 00
00 00 3C 00
00 3C 00 00
00 3C 00 3F UTF-16BE, ou ISO-10646-UCS-2 gros-boutiste, ou un autre codage avec une unité de code de 16-bit en ordre gros-boutiste et des caractères ASCII codés comme valeurs ASCII (la déclaration de codage doit être lue afin de déterminer lequel s'applique)
3C 00 3F 00 UTF-16LE, ou ISO-10646-UCS-2 petit-boutiste, ou un autre codage avec une unité de code de 16-bit en ordre petit-boutiste et des caractères ASCII codés comme valeurs ASCII (la déclaration de codage doit être lue afin de déterminer lequel s'applique)
3C 3F 78 6D UTF-8, ISO 646, ASCII, une certaine partie de ISO 8859, Shift-JIS, EUC, ou tout autre codage de 7-bit, 8-bit ou mixte assurant la position, la chasse et la valeur normales des caractères ASCII ; la déclaration de codage réelle doit être lue afin de détecter lequel s'applique, mais étant donné que tous ces codages utilisent les mêmes modèles d'octet pour les caractères ASCII concernés, la déclaration de codage elle-même peut être lue avec fiabilité
4C 6F A7 94 EBCDIC (dans une certaine variété ; la déclaration de codage complète doit être lue pour dire quel code de page est en vigueur)
Autre UTF-8 sans déclaration de codage, ou sinon le flux de données peut être mal étiqueté (manquant d'une déclaration de codage obligatoire), corrompu, fragmentaire ou enfermé dans une enveloppe d'une certaine sorte

Remarque :

En ce qui concerne les cas précédents qui ne nécessitent pas la lecture de la déclaration de codage pour déterminer le codage, le chapitre 4.3.3 exige néanmoins que la déclaration de codage soit lue, si elle est présente, et que la correspondance du nom du codage avec le codage réel de l'entité soit vérifiée. Il est possible également que de nouveaux codages de caractères soient inventés et rendent obligatoire l'emploi de la déclaration de codage pour déterminer le codage dans les cas où, actuellement, ce n'est pas obligatoire.

Ce niveau d'autodétection est suffisant pour lire la déclaration de codage XML et analyser l'identificateur de codage de caractères, lequel est toujours nécessaire pour distinguer les membres individuels de chaque famille de codage (par exemple, pour distinguer UTF-8 de 8859 et les parties de 8859 les unes des autres, ou pour distinguer le code de page EBCDIC utilisé, et ainsi de suite).

Comme le contenu des déclarations de codage se restreint aux caractères du répertoire ASCII (néanmoins codés), un processeur peut lire la déclaration de codage en entier avec fiabilité dès qu'il a détecté la famille de codage utilisée. Puisque, en pratique, tous les codages de caractères d'usage courant tombent dans l'une des catégories précédentes, le déclaration de codage XML permet un étiquetage symétrique fiable des codages de caractères, même quand les sources d'information externes, au niveau du système d'exploitation ou du protocole de transport, ne sont pas fiables. Les codages de caractères comme UTF-7 qui surchargent les octets de valeur ASCII peuvent ne pas être détectés avec fiabilité.

Dès que le processeur a détecté le codage de caractères utilisé, il peut agir de manière appropriée, soit en invoquant une routine de lecture distincte pour chaque cas, soit en appelant la fonction de conversion adéquate pour chaque caractère en entrée.

Comme n'importe quel système d'autoétiquetage, la déclaration de codage XML ne fonctionnera pas si un quelconque logiciel change le jeu de caractères ou le codage de caractères d'une entité sans mettre à jour la déclaration de codage. Les développeurs de routines de codage de caractères devraient s'appliquer à vérifier l'exactitude des informations internes et externes utilisées pour étiqueter l'entité.

E.2 Les priorités en présence d'une information de codage externe

La seconde possibilité intervient lorsque l'entité XML est accompagnée d'une information de codage, ce qui se produit dans certains systèmes de fichier et certains protocoles de réseau. Quand plusieurs sources d'information de codage sont disponibles, leur priorité les unes par rapport aux autres et la méthode préférée pour la résolution de conflit devrait être définies par le protocole de niveau supérieur utilisé pour acheminer le document XML. En particulier, veuillez vous reporter au document [IETF RFC 3023], ou son successeur, qui définit les types MIME text/xml et application/xml et fournit des indications utiles. Toutefois, pour des raisons d'interopérabilité, on recommande la règle suivante :

  • Si l'entité XML se trouve dans un fichier, alors utiliser la marque d'ordre des octets et la déclaration de codage (le cas échéant) pour déterminer le codage de caractères.

F Le groupe de travail XML du W3C (non normatif)

Cette spécification a été préparée et agrée pour publication par le groupe de travail XML du W3C. L'approbation par le groupe de travail n'implique pas nécessairement un vote unanime des participants du groupe de travail dans ce sens. Les membres actuels et ex-membres du groupe de travail XML sont :

G Le groupe de travail XML Core du W3C (non normatif)

La présente édition de cette spécification a été préparée par le groupe de travail XML Core du W3C. Les participants à ce groupe de travail au moment de la publication de cette édition étaient :

H Les remarques de production (non normatif)

Cette édition a été codée dans une version légèrement modifiée de XMLspec DTD, 2.5. Les versions XHTML ont été produites au moyen d'une combinaison des feuilles de style XSLT xmlspec.xsl, diffspec.xsl et REC-xml-3e.xsl.

I Les suggestions de noms XML (non normatif)

Les suggestions suivantes définissent ce qui est considéré comme étant la meilleure façon de construire les noms XML employés comme noms d'élément, noms d'attributs, cibles d'instructions de traitement, noms d'entité, noms de notation et valeurs d'attribut de type ID. Elles se destinent aux auteurs de documents et aux concepteurs de schémas. Toutes les références à Unicode se comprennent par rapport à une version particulière du standard Unicode, supérieure ou égale à la version 3.0 ; le choix de la version est laissé à la discrétion de l'auteur de document ou du concepteur de schéma.

Les deux premières suggestions découlent directement des règles données pour les identificateurs dans le standard Unicode 3.0 ; elles excluent tous les caractères de contrôle, les marques englobantes sans chasse, les nombres non décimaux, les caractères réservés à un usage interne, les caractères de ponctuation (hormi ceux indiqués), les caractères de symbole, les points de code non assignés et les caractères blancs. Les autres suggestions proviennent principalement de l'annexe B de [XML-1.0].

  1. Le premier caractère d'un nom quelconque devrait appartenir à une des catégories générales Unicode Ll, Lu, Lo, Lm, Lt ou Nl, ou sinon être le caractère souligné #x5F (_).

  2. Les caractères suivants devraient appartenir à une des catégories générales Unicode Ll, Lu, Lo, Lm, Lt, Mc, Mn, Nl, Nd, Pc ou Cf, ou sinon être l'un des caractères suivants : trait d'union #x2D (-), point #x2E (.), deux-points #x3A (:) ou point médian #xB7 (·). Étant donné que les caractères de la catégorie Cf ne sont pas directement visibles, on devraient les employer prudemment et seulement si nécessaire, afin d'éviter la création de noms qui sont distincts pour les processeurs XML, mais qui semblent identiques pour les être humains.

  3. Les caractères idéographiques ayant une décomposition canonique (comprenant ceux dans les intervalles [#xF900-#xFAFF] et [#x2F800-#x2FFFD], avec 12 exceptions) ne devraient pas s'utiliser dans les noms.

  4. Les caractères ayant une décomposition de compatibilité (ceux avec une étiquette de formatage de compatibilité dans le champs 5 de la base de caractères Unicode, marqués avec un champs 5 commençant par un <) ne devraient pas s'utiliser dans les noms. Cette suggestion ne s'applique pas aux caractères #x0E33 LETTRE THAÏE SARA AM et #x0EB3 VOYELLE DIACRITIQUE LAOTIENNE AM qui, en dépit de leur décomposition de compatibilité, sont d'usage courant dans ces écritures.

  5. Les caractères combinatoires destinés à être utilisés seulement avec des symboles (comprenant ceux dans les intervalles [#x20D0-#x20EF] et [#x1D165-#x1D1AD]) ne devraient pas s'utiliser dans les noms.

  6. Les caractères d'annotation interlinéaires ([#xFFF9-#xFFFB]) ne devraient pas s'utiliser dans les noms.

  7. Les caractères sélecteurs de variation ne devraient pas s'utiliser dans les noms.

  8. Les noms incohérents, imprononçables, difficiles à lire ou confondus facilement avec d'autres ne devraient pas s'employer.