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/.
Des erreurs ont pu survenir malgré le soin apporté à ce travail.
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.
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.
On peut consulter les traductions en français d'autres documents du W3C à
http://www.w3.org/2003/03/Translations/byLanguage?language=fr
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.
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.
Copyright ©2004 W3C® (MIT, ERCIM, Keio), tous droits réservés. Les règles de responsabilité, de marque de commerce, d'utilisation des documents et d'octroi de licences logicielles du W3C s'appliquent.
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.
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.
CDATA
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.
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 :
XML devra être directement utilisable sur l'internet.
XML devra reconnaître une grande variété d'applications.
XML devra être compatible avec SGML.
L'écriture des programmes de traitement des documents XML devra être aisée.
Le nombre des caractéristiques optionnelles dans XML devra être tenu au strict minimum, idéalement à zéro.
Les documents XML devraient être lisibles par un humain et raisonnablement clairs.
La conception de XML devrait être préparée rapidement.
La conception de XML devra être formelle et concise.
Les documents XML devront être faciles à créer.
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.
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 :
[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.]
[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).]
[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.]
[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.]
[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.]
[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].]
[Définition : Marque une phrase décrivant une caractéristique de XML incluse seulement pour faire en sorte que XML reste compatible avec SGML.]
[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.]
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.
[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.]
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.
[Définition : Un objet textuel est un document XML bien formé si :]
Considéré globalement, il correspond à la production document
.
Il satisfait à toutes les contraintes de bonne forme données dans cette spécification.
Chacune des entités analysables appelées directement ou indirectement dans le document est bien formée.
[1] | document | ::= | (prologue élément Divers)* - (Car* CarRestreint Car*) |
Une correspondance avec la production document
implique que :
L'objet contient un ou plusieurs éléments.
[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
dans le document, il existe un seul autre élément E
dans le document, tel que P
se trouve dans le contenu de E
,
mais pas dans le contenu d'un quelconque autre élément dans le contenu de P
. L'élément P
est dit parent de
P
, et E
est dit enfant de E
.]P
[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
.]
[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].
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.
[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
,
ou par toute chaîne qui correspondrait à xml
, sont réservés à la standardisation dans cette spécification
ou dans les versions futures de celle-ci.(('X'|'x') ('M'|'m') ('L'|'l'))
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é.
[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.
[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, <
), on déconseille vivement cette pratique
dans la mesure où tout appel de cette entité provoquera une erreur de forme.<!ENTITY monlt "<">
Le texte est un mélange composé de données textuelles et de balisage.
[Définition : Le balisage se compose de balises ouvrantes,
de balises fermantes, de balises d'élément vide,
d'appels d'entité, d'appels de caractère,
de commentaires, de délimiteurs de section de type CDATA
,
de déclarations de type de document, d'instructions de traitement,
de déclarations XML, de déclarations de texte et de tout blanc se trouvant au niveau supérieur de
l'entité document (c'est-à-dire, en dehors de l'élément document et à l'extérieur de tout autre balisage).]
[Définition : Tout le texte qui n'est pas du balisage constitue les données textuelles du document.]
Les caractères esperluette (&) et inférieur à (<) NE DOIVENT PAS
apparaître dans leur forme littérale, sauf comme délimiteurs de balisage ou à l'intérieur d'un commentaire,
d'une instruction de traitement ou d'une section de type CDATA
.
Si leur présence est requise ailleurs, ils DOIVENT être échappés
en utilisant soit des appels de caractère numériques, soit, respectivement, les chaînes
et &
. Le caractère supérieur à (>) PEUT
être représenté par la chaîne <
, et DOIT,
pour des raisons de compatibilité, être échappé en utilisant soit la chaîne >
, soit un
appel de caractère, quand il apparaît dans la chaîne >
dans un contenu, si cette chaîne ne marque pas la fin d'une
section de type ]]>
CDATA
.
Dans le contenu des éléments, toute chaîne de caractères ne contenant pas le délimiteur d'ouverture d'un balisage quelconque ni le
délimiteur de clôture de section CDATA
est une donnée textuelle.
Dans une section de type ]]>
CDATA
, toute chaîne de caractères ne contenant pas le délimiteur de clôture de section CDATA
est une donnée textuelle.
Afin de permettre aux valeurs d'attribut de contenir des guillemets simples et doubles, on PEUT
représenter le caractère apostrophe ou guillemet simple (') par la chaîne
et le caractère guillemet double (")
par '
."
[14] | DonnéesTextuelles | ::= | [^<&]* - ([^<&]* ']]>' [^<&]*) |
[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.--
[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--->
[Définition : Les instructions de traitement (IT) permettent aux documents de contenir des instructions destinées aux applications.]
[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
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 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.
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
et se terminent par la chaîne <![CDATA[
:]]]>
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
et <
. Les sections de type &
CDATA
ne peuvent pas s'imbriquer.
Voici un exemple de section de type CDATA
, dans lequel les chaînes
et <salutation>
sont reconnues comme données textuelles, non comme balisage :</salutation>
<![CDATA[<salutation>Salut à tous !</salutation>]]>
[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.
[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.
[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.
[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
comporte l'adresse (une adresse URI)
d'un DTD pour le document.salut.dtd
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.
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).]
[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
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.standalone="no"
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
),
si des appels de ces entités apparaissent dans le document, ouquot
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'?>
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
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 :xml:space
<!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
.
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.xml:space
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.
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
:
La séquence de deux caractères #xD #xA
La séquence de deux caractères #xD #x85
Le caractère seul #x85
Le caractère seul #x2028
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.
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
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.xml:lang
(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ßem Bemüh'n.</l> </sp>
L'intention déclarée par l'attribut
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 xml:lang
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.
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
la supplantera.xml:lang
Une déclaration simple pour l'attribut
prendrait la forme :xml:lang
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
pourrait s'employer de cette façon :xml:lang
<!ATTLIST poeme xml:lang CDATA 'fr'> <!ATTLIST glose xml:lang CDATA 'en'> <!ATTLIST note xml:lang CDATA 'en'>
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 :
Le texte de remplacement de toutes les entités analysables
Tout le texte correspondant, selon le contexte, à l'une des productions suivantes :
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.
[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.
[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
qui sont réservés à la standardisation dans cette version ou les versions futures de
cette spécification.(('X'|'x')('M'|'m')('L'|'l'))
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 :
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).
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.
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.
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.
[Définition : Chaque élément XML non vide commence par une balise ouvrante.]
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 :]
[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 :]
[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 :]
[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/>
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 :]
[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>
[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 :
[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;)*>
[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 :
[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)>
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é :]
[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.
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.
[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 :
[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.
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.
[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).
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">
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.
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é.
Commencer avec une valeur normalisée consistant en la chaîne vide.
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 "
"> <!ENTITY a "
"> <!ENTITY da "
">
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
était déclaré comme étant du type a
CDATA
.
Spécification d'attribut | aest du type NMTOKENS | aest du type CDATA |
---|---|---|
a="xyz" | x y z | #x20 #x20 x y z |
a="&d;&d;A&a; &a;B&da;" | A #x20 B | #x20 #x20 A #x20 #x20 #x20 B #x20 #x20 |
a="

A

B
" | #xD #xD A #xA #xA B #xD #xA | #xD #xD A #xA #xA B #xD #xA |
Remarquez que le dernier exemple est invalide (mais bien formé), si
est déclaré de type a
NMTOKENS
.
[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.]
[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?)> ]]>
[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.
[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.]
[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
, alors les chiffres et lettres jusqu'au caractère de terminaison
&#x
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.]
[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
, 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 standalone='yes'
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
. 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.quot
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
, la valeur de type
standalone='no'
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
, 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.quot
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> (<) 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;
[Définition : Les entités se déclarent ainsi :]
[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.
[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.">
[Définition : Si l'entité n'est pas interne, alors c'est une entité externe déclarée comme suit :]
[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
). 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.Location:
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 :
Chaque caractère à échapper est représenté dans le codage UTF-8 [Unicode] par un ou plusieurs octets.
Les octets obtenus sont échappés selon le mécanisme d'échappement des adresses URI (c'est-à-dire, convertis en une expression
,
dans laquelle %
HHHH
est la notation hexadécimale de la valeur d'octet).
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 >
Les entités analysables externes DEVRAIENT toutes commencer par une 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.
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.
[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.
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 :
[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'?>
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.
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 :
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
.
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
.
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
.
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é
.
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ètre | Entité générale interne | Entité générale analysable externe | Entité non analysable | ||
Appel dans un contenu | Non reconnu | Inclus | Inclus si validation | Interdit | Inclus |
Appel dans une valeur d'attribut | Non reconnu | Inclus en littéral | Interdit | Interdit | Inclus |
Comme valeur d'attribut | Non reconnu | Interdit | Interdit | Notifier | Non reconnu |
Appel dans une valeur d'entité | Inclus en littéral | Non interprété | Non interprété | Erreur | Inclus |
Appel dans un DTD | Inclus comme entité paramètre | Interdit | Interdit | Interdit | Interdit |
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é.%
[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
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.AT&T;
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.
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.
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;>
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.
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.
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.
L'apparition d'un appel d'entité non analysable dans une valeur de type ValeurEntité
dans une déclaration d'entité
constitue une erreur.
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 "Éditions Gallimard" > <!ENTITY droits "Tous droits réservés" > <!ENTITY ouvrage "La Peste : Albert Camus, © 1947 %editeur;. &droits;" >
En ce cas, le texte de remplacement de l'entité
est :ouvrage
La Peste : Albert Camus, © 1947 Éditions Gallimard. &droits;
L'appel d'entité générale
serait développé, si l'appel &droits;
apparaissait dans
le contenu du document ou dans une valeur d'attribut.&ouvrage;
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.
[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
)
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
quot
et <
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
ou lt
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 amp
, gt
ou apos
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 :quot
<!ENTITY lt "&#60;"> <!ENTITY gt ">"> <!ENTITY amp "&#38;"> <!ENTITY apos "'"> <!ENTITY quot """>
[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.]
[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.)
[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.
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
, 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.standalone='yes'
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.
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.
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
où
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 N
n'est pas significatif.#xN
[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ù
et A
représentent des expressions simples :B
expression
)le paramètre
est traité comme une unité et peut se combiner comme décrit dans cette liste.expression
A?
correspond à la valeur
ou à rien : A
optionnel.A
A B
correspond à
suivi de A
. Cet opérateur a une priorité plus élevée que l'alternance ; ainsi
B
est identique à A B | C D
.(A B) | (C D)
A | B
correspond à
ou A
.B
A - B
correspond à toute chaîne identique à
mais pas à A
.B
A+
correspond à une ou plusieurs occurrences de
. La concaténation a une priorité plus élevée que l'alternance ; ainsi
A
est identique à A+ | B+
.(A+) | (B+)
A*
correspond à zéro occurence ou plus de
. La concaténation a une priorité plus élevée que l'alternance ; ainsi
A
est identique à A* | B*
.(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.
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 :]
exprimer des caractères significatifs pour la syntaxe tout en ne tenant pas compte de leur signification dans la syntaxe du langage, ou
exprimer des caractères non représentables dans le codage de caractères choisi pour une instance du langage, ou
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 :]
une inspection a confirmé que le texte est dans une forme normalisée
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 :]
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
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 :]
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])
ou d'une classe combinatoire canonique avec chasse (comme défini dans Unicode [Unicode]).
[Définition : Un texte est complètement normalisé si :]
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
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.
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;) numériquement (&#38;#38;) ou au moyen d'une entité générale (&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 (&) numériquement (&#38;) ou au moyen d'une entité générale (&amp;).</p>
Dans le document, un appel
entraînera une réanalyse du texte, au cours de laquelle les balises ouvrante et fermante
de l'élément &exemple;
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) :p
On peut échapper une esperluette (&) numériquement (&) ou au moyen d'une entité générale (&).
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 '%zz;'> 5 <!ENTITY % zz '<!ENTITY surprenante "pleine de surprises">' > 6 %xx; 7 ]> 8 <test>Cet exemple illustre une méthode &surprenante;.</test>
Voici le résultat produit :
à la ligne 4, l'appel du caractère 37
est immédiatement développé et l'entité paramètre
est enregistrée dans la
table des symboles avec une valeur de xx
. Comme le texte de remplacement n'est pas relu, l'appel d'entité paramètre
%zz;
n'est pas reconnu. (Et il s'agirait d'une erreur si celui-ci l'était, puisque l'entité zz
n'est pas encore déclarée.)zz
à la ligne 5, l'appel de caractère
est développé immédiatement et l'entité paramètre <
est enregistrée avec le texte de remplacement zz
,
laquelle est une déclaration d'entité bien formée.<!ENTITY surprenante "pleine de surprises">
à la ligne 6, l'appel d'entité
est reconnu et le texte de remplacement de xx
(à savoir xx
) est analysé. L'appel d'entité %zz;
est reconnu à son tour et son texte de remplacement
(zz
) est analysé. L'entité générale <!ENTITY surprenante "pleine de surprises">
est maintenant déclarée
avec le texte de remplacement surprenante
.pleine de surprises
à la ligne 8, l'appel d'entité générale
est reconnu puis développé, de sorte que le contenu complet de
l'élément surprenante
est la chaîne autodescriptive (et non grammaticale) test
Cet exemple illustre une méthode pleine de surprises.
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
est non déterministe, parce que, pour un objet initial ((b, c) | (b, d))
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
.
Un objet initial (b, (c | d))
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 b
, soit c
sera accepté.d
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].
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.
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
, 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 <?xml
<
correspond à
et #x0000003C
?
à
, et que la marque d'ordre des octets nécessaire pour les flux de données UTF-16
est #x0000003F
. On utilise la notation ## pour indiquer une valeur d'octet quelconque, à part que deux ## consécutifs
ne peuvent pas être tous deux égaux à 00.#xFEFF
Avec une marque d'ordre des octets (BOM):
00 00 FE FF | UCS-4, machine gros-boutiste (ordre 1234) |
FF FE 00 00 | UCS-4, machine petit-boutiste (ordre 4321) |
00 00 FF FE | UCS-4, ordre d'octet inhabituel (2143) |
FE FF 00 00 | UCS-4, ordre d'octet inhabituel (3412) |
FE FF ## ## | UTF-16, gros-boutiste |
FF FE ## ## | UTF-16, petit-boutiste |
EF BB BF | UTF-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é.
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
et text/xml
et fournit des indications utiles. Toutefois, pour des raisons d'interopérabilité, on recommande la règle suivante :application/xml
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.
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 :
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 :
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.
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].
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 (_)
.
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.
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.
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.
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.
Les caractères d'annotation interlinéaires ([#xFFF9-#xFFFB]) ne devraient pas s'utiliser dans les noms.
Les caractères sélecteurs de variation ne devraient pas s'utiliser dans les noms.
Les noms incohérents, imprononçables, difficiles à lire ou confondus facilement avec d'autres ne devraient pas s'employer.