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 :
- erreur
[Définition : Une violation des règles de cette spécification ;
les résultats ne sont pas définis. Sauf indiqué autrement, le non respect d'une prescription de cette spécification, signalée par l'un
des mots-clés DOIT, OBLIGATOIRE,
NE DOIT PAS, DEVRA et
NE DEVRA PAS, constitue une erreur. Un logiciel conforme
PEUT détecter et signaler une erreur, et PEUT
récupérer de celle-ci.]
- erreur fatale
[Définition : Une erreur qu'un processeur XML
DOIT détecter et signaler à l'application. Face à une erreur fatale, le processeur
PEUT continuer le traitement des données à la recherche d'autres erreurs et
PEUT signaler celles-ci à l'application. Pour une prise en charge de la correction des erreurs,
le processeur PEUT mettre à la disposition de l'application des données non traitées issues du
document (données textuelles et balisage entremêlés). Toutefois, dès qu'une erreur fatale est détectée, le processeur
NE DOIT PAS poursuivre le traitement normal (c'est-à-dire, qu'il
NE DOIT PAS continuer à passer des données textuelles et des informations concernant la structure
logique du document à l'application de façon normale).]
- au gré de l'utilisateur
[Définition : Un logiciel conforme
PEUT ou DOIT (selon le verbe modal dans la phrase)
se comporter comme indiqué ; s'il le fait, alors il DOIT fournir à l'utilisateur le moyen
d'activer ou de désactiver le comportement décrit.]
- contrainte de validité (CV)
[Définition : Une règle qui s'applique à tous les documents XML
valides. Les violation des contraintes de validité constituent des erreurs ; elles
DOIVENT, au gré de l'utilisateur, être signalées par les
processeurs XML validants.]
- contrainte de forme (CF)
[Définition : Une règle qui s'applique à tous les documents XML
bien formés. Les violations des contraintes de bonne forme constituent des
erreurs fatales.]
- correspondance
[Définition : (... de chaînes ou de noms :) Deux chaînes de caractères ou deux noms soumis à comparaison
DOIVENT être identiques. Les caractères avec plusieurs représentations possibles dans Unicode
(par exemple, les caractères ayant à la fois une forme précomposée et une forme de base plus diacritique) ne correspondent que s'ils ont la même représentation
dans les deux chaînes. Aucun changement de casse n'intervient. (... de chaînes et de règles dans la grammaire :) Une chaîne correspond à une production
grammaticale si elle appartient au langage généré par cette production. (... de contenu et de modèles de contenu :) Un élément correspond à
sa déclaration lorsqu'il est conforme, selon les conditions décrites dans la contrainte [CV : Validité de l'élément].]
- pour des raisons de compatibilité
[Définition : Marque une phrase décrivant une caractéristique de XML incluse
seulement pour faire en sorte que XML reste compatible avec SGML.]
- pour des raisons d'interopérabilité
[Définition : Marque une phrase décrivant
une recommandation non imposée, incluse afin d'augmenter la probabilité que les documents XML puissent être traités par les moteurs SGML
existants antérieurs à l'annexe des adaptations WebSGML de ISO 8879.]
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.]
errata-E16
Chaque document XML possède à la fois une structure logique et physique. Physiquement, le document se compose d'unités appelées
entités. Une entité PEUT
appeler d'autres entités afin de provoquer leur inclusion dans le document. Un document commence
par une racine
ou une entité document. Logiquement, le document se compose de déclarations,
d'éléments, de commentaires, d'appels de caractère et d'instructions de traitement, lesquels sont tous indiqués par un balisage explicite dans le document.
Les structures physique et logique DOIVENT s'imbriquer correctement, comme décrit dans le chapitre
4.3.2 Les entités analysables bien formées.
[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.
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 E
dans le document, il existe un seul autre élément P
dans le document, tel que E
se trouve dans le contenu de P
,
mais pas dans le contenu d'un quelconque autre élément dans le contenu de P
. L'élément P
est dit parent de
E
, et E
est dit enfant de P
.]
[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 xml
,
ou par toute chaîne qui correspondrait à (('X'|'x') ('M'|'m') ('L'|'l'))
, sont réservés à la standardisation dans cette spécification
ou dans les versions futures de celle-ci.
Remarque :
La recommandation des espaces de nommage dans XML [XML Names] confère un sens particulier aux noms contenant des caractères deux-points (:).
De ce fait, les auteurs, sauf pour les besoins des espaces de nommage, ne devraient pas employer le caractère deux-points dans les noms XML,
au contraire des processeurs XML qui doivent l'accepter comme caractère de nom.
Un type AtomeNml
(nom d'unité lexicale) se compose d'un mélange quelconque de caractères de nom.
Le premier caractère d'une valeur de type Nom
DOIT être du type CarNomInit
et tous les
autres caractères DOIVENT être du type CarNom
. Ce mécanisme est destiné à prévenir
les noms commençant par un chiffre (ASCII)
ou par des caractères combinants de base. Presque tous les caractères sont autorisés dans les noms, sauf ceux qui font (ou pourraient faire) office de délimiteurs.
On veut rester inclusif plutôt qu'exclusif, de sorte que les systèmes d'écriture qui ne sont pas encore codés dans Unicode puissent être utilisés dans les
noms XML. Voir l'annexe I Les suggestions de noms XML qui donne des pistes pour la création des noms.
Les auteurs de documents sont invités, en ce qui concerne les noms, à employer des mots ou combinaisons de mots dans la langue naturelle qui soient significatifs
et à éviter les caractères symboliques ou blancs. Remarquez que les caractères DEUX-POINTS
,
TRAIT D'UNION-SIGNE MOINS
, POINT
,
SOULIGNÉ
et POINT MÉDIAN
sont explicitement autorisés.
Les symboles et marques de ponctuation ASCII, ainsi qu'un groupe conséquent de caractères symboliques Unicode, sont exclus de la composition des noms parce
qu'ils sont plus utiles comme délimiteurs quand les noms XML sont employés hors des documents XML ; ce groupe apporte, dans ces contextes, une
garantie solide concernant ce qui ne peut pas faire partie d'un nom XML. Le caractère POINT D'INTERROGATION GREC (érotimatiko) #x037E
est
aussi exclus parce que, une fois normalisé, il devient un point-virgule, ce qui pourrait changer la signification d'un appel d'entité.
| [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)* |
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, <!ENTITY monlt "<">
), on déconseille vivement cette pratique
dans la mesure où tout appel de cette entité provoquera une erreur de forme.
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 | ::= | [^<&]* - ([^<&]* ']]>' [^<&]*) |
[ : 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.
| 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é.
[Définition : Les instructions de traitement (IT)
permettent aux documents de contenir des instructions destinées aux applications.]
Les instructions de traitement ne font pas partie des données textuelles du document, mais elles
DOIVENT être transmises à l'application. L'instruction de traitement commence par une cible
(CibleIT
) qui identifie l'application visée par l'instruction. Les noms de cible XML
,
xml
et similaires sont réservés à la standardisation dans cette spécification ou dans les versions futures de celle-ci.
On PEUT utiliser le mécanisme XML Notation
pour la déclaration formelles des cibles des instructions de traitement. Les appels d'entité paramètre
NE DOIVENT PAS être interprétés au sein des instructions de traitement.
[Définition : Les sections de type CDATA
PEUVENT apparaître partout où les données textuelles le peuvent. On les utilise pour échapper des
blocs de texte contenant des caractères qui, sinon, serait interprétés comme du balisage. Les sections de type CDATA
commencent par la chaîne
<![CDATA[
et se terminent par la chaîne ]]>
:]
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 <salutation>
et </salutation>
sont reconnues comme données textuelles, non comme balisage :
<![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.
[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.
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.
Comme pour le sous-ensemble interne, le sous-ensemble externe et toutes les entités paramètres externes appelés dans une valeur de type
SépDécl
DOIVENT se composer d'une suite de déclarations de balisage complètes
dans les types admis par le symbole non-terminal déclBalisage
, entrecoupées de caractères blancs ou
d'appels d'entité paramètre. Toutefois, des parties des contenus du sous-ensemble externe
ou de ces entités paramètres externes PEUVENT être éventuellement ignorées en utilisant une
structure de section conditionnelle. Ce n'est pas permis dans le sous-ensemble interne, ça l'est
par contre dans les entités paramètres externes appelées dans le sous-ensemble interne.
Le sous-ensemble externe et les entités paramètres externes diffèrent également du sous-ensemble interne par le fait que les
appels d'entité paramètres sont permis au sein des déclarations de balisage, et
pas seulement entre celles-ci.
Voici un exemple de document XML avec une déclaration de type de document :
<?xml version="1.1"?>
<!DOCTYPE salutation SYSTEM "salut.dtd">
<salutation>Salut à tous !</salutation>
L'identificateur de système salut.dtd
comporte l'adresse (une adresse URI)
d'un DTD pour le document.
Les déclarations peuvent aussi être locales, comme dans cet exemple :
<?xml version="1.1" encoding="UTF-8" ?>
<!DOCTYPE salutation [
<!ELEMENT salutation (#PCDATA)>
]>
<salutation>Salut à tous !</salutation>
Si les deux sous-ensembles interne et externe sont utilisés, alors on DOIT considérer
le sous-ensemble interne comme survenant avant le sous-ensemble externe. Cela a pour effet que les déclarations d'entité et de liste d'attributs dans le
sous-ensemble interne ont préséance sur ceux du sous-ensemble externe.
Les processeurs XML 1.1 DEVRAIENT également accepter les documents XML 1.0. Si un
document est bien formé ou valide selon XML 1.0, et pourvu qu'il ne contienne pas de caractères de contrôle dans l'intervalle [#x7F-#x9F] autres que
sous forme d'échappements de caractères, alors il peut être rendu, respectivement, bien formé ou valide selon XML 1.1 en changeant le numéro de version.
errata-E15
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).]
Dans une déclaration de document autonome, la valeur "yes" indique l'absence d'une
déclaration de balisage externe susceptible d'affecter les informations transmises
du processeur XML à l'application. La valeur "no" indique la présence ou une probabilité de présence de telles déclarations de balisage externes. Remarquez que la
déclaration de document autonome indique seulement la présence de déclarations. Dans un document, la présence d'appels d'entités
externes, quand la déclaration de ces entités est interne, ne change pas son statut autonome.
S'il n'existe pas de déclaration de balisage externe, la déclaration de document autonome est sans objet. S'il existe des déclarations de balisage externes
en l'absence de déclaration de document autonome, alors la valeur "no" est supposée.
Tout document XML pour lequel on a standalone="no"
peut être converti par des moyens algorithmiques en un document autonome, ce qui
peut être souhaitable pour certaines applications de distribution via un réseau.
Contrainte de validité : Déclaration de document autonome
La déclaration de document autonome DOIT avoir la valeur "no"
si une quelconque déclaration de balisage externe contient :
des déclarations d'attributs avec des valeurs implicites, si les éléments auxquels ces attributs
s'appliquent apparaissent dans le document sans spécification de valeur pour ces attributs, ou
des déclarations d'entité (autres que amp
, lt
, gt
, apos
, quot
),
si des appels de ces entités apparaissent dans le document, ou
des déclarations d'attribut avec des types lexicalisés, où les attributs apparaissent dans le document
avec une valeur pour laquelle la normalisation
produira une valeur différente de celle qui aurait été produite en
l'absence de la déclaration, ou
des déclarations de types d'élément avec un contenu d'éléments, si des caractères blancs apparaissent
directement dans une quelconque instance de ces types.
Un exemple de déclaration XML avec une déclaration de document autonome :
<?xml version="1.1" standalone='yes'?>
Lors de l'édition de documents XML, il est souvent commode d'utiliser des caractères blancs
(espace, tabulation et saut de ligne) afin de distinguer
le balisage pour une meilleure lisibilité. En général, ces caractères blancs ne sont pas destinés à être inclus dans la version distribuée du document.
Au contraire, il n'est pas rare que des caractères blancs significatifs
doivent être conservés dans la version distribuée, par exemple pour de la poésie
ou du code source.
Un processeur XML DOIT toujours transmettre
à l'application tous les caractères du document qui ne font pas partie du balisage. Un processeur XML validant
DOIT également informer l'application des caractères blancs qui apparaissent dans un
contenu d'éléments.
L'attribut spécial xml:space
PEUT
être attaché à un élément pour signaler que les caractères blancs dans cet élément devraient être préservés par les applications. Dans les documents valides,
cet attribut, comme n'importe quel autre, DOIT être
déclaré si on l'utilise. Auquel cas, on
DOIT le déclarer comme étant d'un type énuméré
qui peut prendre la valeur "default", ou "preserve" ou les deux. Par exemple :
<!ATTLIST poeme xml:space (default|preserve) 'preserve'>
<!ATTLIST pre xml:space (preserve) #FIXED 'preserve'>
La valeur "default" indique que les modes de traitement par défaut des caractères blancs des applications sont acceptables pour l'élément en question.
La valeur "preserve" exprime le fait que les applications doivent préserver tous les caractères blancs. Cette intention est censée s'appliquer à tous les
éléments dans le contenu de l'élément sur lequel elle est spécifiée, à moins qu'elle ne soit surchargée par une autre instance de l'attribut xml:space
.
Cette spécification ne confère aucune signification à une valeur de l'attribut xml:space
autre que "default" ou "preserve".
La spécification d'une autre valeur constitue une erreur ; le processeur XML PEUT signaler
l'erreur ou PEUT récupérer en ignorant la spécification de l'attribut ou en signalant la valeur
(erronnée) à l'application. Les applications peuvent ignorer ou rejeter les valeurs erronnées.
L'élément racine d'un document est censé n'avoir signalé aucune intention en ce qui concerne l'interprétation
des caractères blancs par l'application, à moins qu'il ne fournisse une valeur pour cet attribut ou que l'attribut soit déclaré avec une valeur implicite.
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 xml:lang
PEUT
être inséré dans les documents pour spécifier la langue employée pour le contenu et les valeurs d'attribut de n'importe quel élément d'un document XML.
Dans les documents valides, cet attribut, comme n'importe quel autre, DOIT être
déclaré si on l'utilise. Les valeurs de l'attribut sont les identificateurs de langue tels
que définis par le document [IETF RFC 3066], Les étiquettes d'identification des langues, ou par son successeur ;
on PEUT, en outre, spécifier la chaîne vide.
(Les productions 33 à 38 ont été supprimées.)
Par exemple :
<p xml:lang="en">The quick brown fox jumps over the lazy dog.</p>
<p xml:lang="en-GB">What colour is it?</p>
<p xml:lang="en-US">What color is it?</p>
<sp who="Faust" desc='leise' xml:lang="de">
<l>Habe nun, ach! Philosophie,</l>
<l>Juristerei, und Medizin</l>
<l>und leider auch Theologie</l>
<l>durchaus studiert mit heißem Bemüh'n.</l>
</sp>
L'intention déclarée par l'attribut xml:lang
est censée s'appliquer à tous les attributs et le contenu de l'élément sur lequel il
est spécifié, à moins qu'elle ne soit surchargée par une instance de l'attribut xml:lang
sur un autre élément dans l'élément en question.
En particulier, la valeur vide de l'attribut xml:lang
s'utilise sur un élément B
pour annuler une spécification sur un élément
englobant A
, sans spécifier d'autre langue. Aucune information de langue n'est censée exister à l'intérieur de B
, tout comme si on n'avait pas
attaché d'attribut xml:lang
à B
ou à un de ses ancêtres.
errata-E03
Remarque :
L'information de langue peut également être apportée par des protocoles de transport externes (par exemple,
HTTP ou MIME.
Cette information, le cas échéant, peut être mise à profit par les applications XML, toutefois, l'information plus locale fournie par l'attribut
xml:lang
la supplantera.
Une déclaration simple pour l'attribut xml:lang
prendrait la forme :
Mais on PEUT aussi donner des valeurs d'attribut spécifiques, si nécessaire.
Dans un recueil de poèmes français pour des étudiants anglais, comportant des gloses et des notes en anglais, l'attribut xml:lang
pourrait s'employer de cette façon :
<!ATTLIST poeme xml:lang CDATA 'fr'>
<!ATTLIST glose xml:lang CDATA 'en'>
<!ATTLIST note xml:lang CDATA 'en'>
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 :
DonnéesDT
DonnéesTextuelles
contenu
Nom
AtomeNml
Toutefois, un document reste toujours bien formé même s'il n'est pas complètement normalisé.
Les processeurs XML DEVRAIENT fournir une possibilité à l'utilisateur de vérifier que le document en
cours de traitement est dans une forme complètement normalisée et signaler à l'application s'il l'est
ou non. La possibilité de ne pas vérifier DEVRAIT seulement être retenue lorsque le texte en entrée est
certifié, comme défini dans l'annexe B Les définitions pour la normalisation des caractères.
La vérification de normalisation complète DOIT être menée de sorte à d'abord vérifier que l'entité
est dans une forme d'inclusion normalisée, comme défini
dans l'annexe B Les définitions pour la normalisation des caractères, puis qu'aucune des structures listées précédemment
ne commence (après développement des appels de caractère) par un caractère composant, comme défini
dans l'annexe B Les définitions pour la normalisation des caractères. Les processeurs non validants
DOIVENT ignorer les possibles dénormalisations qui pourraient survenir à la suite de l'inclusion
d'entités externes qu'ils ne savent pas lire.
Remarque :
Les caractères composants comprennent tous les caractères Unicode de la
classe des caractères combinatoires avec chasse, plus certains caractères de la
classe des caractères sans chasse participant à certaines décompositions canoniques Unicode
en tant que caractères non initiaux. Puisque ces caractères doivent suivre les caractères de base, empêcher les structures concernées
(dont le contenu) de commencer par un caractère composant ne diminue pas significativement la capacité
d'expression de XML.
Si, au cours d'une vérification de normalisation complète, un processeur rencontre des caractères pour lesquels il est incapable de déterminer les
propriétés de normalisation (c'est-à-dire, des caractères introduit par une version de Unicode [Unicode] postérieure à celle utilisée
dans la mise en œuvre du processeur), alors le processeur PEUT, au gré de l'utilisateur,
ignorer les éventuelles dénormalisations provoquées par ces caractères. Cette option consistant à ignorer les dénormalisations
NE DEVRAIENT PAS être retenue par les applications lorsque la fiabilité ou la sécurité revêtent une importance critique.
Les processeurs XML NE DOIVENT PAS transformer un document en entrée pour l'amener à une
forme complètement normalisée. Les applications XML qui produisent du code XML 1.1 en sortie, à
partir d'une entrée soit XML 1.1, soit XML 1.0, DEVRAIENT s'assurer que la sortie est
complètement normalisée ; il n'est pas nécessaire que les structures de traitement internes
soient complètement normalisées.
L'objectif de ce chapitre est d'encourager vigoureusement les processeurs XML à vérifier que les créateurs de documents XML les aient correctement
normalisés au préalable, de sorte que les applications XML puissent effectuer des tests, comme des comparaisons d'identité de chaînes,
sans devoir se soucier des différentes orthographes
de chaînes permises par Unicode.
Quand les entités ont un codage non-Unicode, si le processeur les transcode vers Unicode, alors il
DEVRAIT utiliser un transcodeur normalisant.
[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.
Cette spécification ne contraint pas la sémantique, l'usage ou les noms (hormi la syntaxe) des types et attributs des éléments, sauf les noms
commençant par (('X'|'x')('M'|'m')('L'|'l'))
qui sont réservés à la standardisation dans cette version ou les versions futures de
cette spécification.
Contrainte de 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.
errata-E11
La déclaration correspond à la valeur "ANY" et le contenu (après substitution des éventuels appels d'entité par leur
texte de remplacement) se compose de données textuelles et d'éléments enfants dont les types sont déclarés.
errata-E11
[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.
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 :]
Exemple de balise fermante :
[Définition : Le texte entre la balise ouvrante et la
balise fermante est appelé contenu de l'élément :]
[Définition : Un élément sans contenu est dit vide.]
Un élément vide est représenté soit par une balise ouvrante suivie immédiatement de la balise fermante, soit par une balise d'élément vide.
[Définition : Une balise d'élément vide prend une forme spéciale :]
Les balises 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 :]
La valeur de type Nom
donne le type de l'élément déclaré.
Exemples de déclarations de type d'élément :
<!ELEMENT br EMPTY>
<!ELEMENT p (#PCDATA|emph)* >
<!ELEMENT %name.para; %content.para; >
<!ELEMENT container ANY>
[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 :
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.
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 :
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].
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é :]
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.
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é : 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.
[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 :
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é.
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.
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é : Syntaxe de la valeur implicite de l'attribut correcte
La valeur implicite déclarée DOIT satisfaire aux contraintes syntaxiques du type d'attribut déclaré.
Remarquez que seules les contraintes syntaxiques du type sont requises ici ; d'autres contraintes (par exemple, que la valeur soit le nom d'une
entité non analysable déclarée, pour un attribut de type ENTITY
) peuvent entrer en ligne de compte si la valeur déclarée implicite est réellement
utilisée (un élément apparaît sans spécification pour cet attribut).
errata-E12
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 a
était déclaré comme étant du type CDATA
.
| Spécification d'attribut | a est du type NMTOKENS | a est du type CDATA |
|---|
| | |
a="&d;&d;A&a; &a;B&da;" | |
#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 a
est déclaré de type 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.]
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.]
Si l'appel de caractère commence par la chaîne &#x
, alors les chiffres et lettres jusqu'au caractère de terminaison
;
composent une représentation hexadécimale du point de code du caractère dans ISO/IEC 10646. S'il commence simplement par
&#
, alors les chiffres jusqu'au caractère de terminaison ;
composent une représentation décimale du point de code
du caractère.
[Définition : Un appel d'entité désigne le contenu d'une entité nommée.]
[Définition : Les appels d'entités générales analysables utilisent les
caractères esperluette (&) et point-virgule (;) comme délimiteurs.]
[Définition : Les appels d'entité paramètre utilisent les caractères
symbole pour cent (%) et point-virgule (;) comme délimiteurs.]
Contrainte de forme : Entité déclarée
Dans un document sans DTD, ou dans un document avec seulement un sous-ensemble de DTD interne ne contenant aucun appel d'entité paramètre,
ou dans un document avec l'attribut standalone='yes'
, pour un appel d'entité qui n'apparaît pas dans le sous-ensemble externe ou dans
une entité paramètre, alors la valeur de type Nom
donnée dans l'appel d'entité
DOIT correspondre à celle dans une
déclaration d'entité qui n'apparaît pas dans le sous-ensemble externe ou dans une entité paramètre, à l'exception
des documents bien formés qui ne sont pas tenus de déclarer les entités suivantes : amp
, lt
, gt
,
apos
, quot
. La déclaration d'une entité générale DOIT
précéder tout appel de celle-ci apparaissant dans une valeur implicite dans une déclaration de liste d'attributs.
Remarquez que les processeurs non validant ne sont pas obligés de lire et traiter les déclarations d'entité qui apparaissent
dans les entités paramètres ou dans le sous-ensemble externe ; dans ces cas, la règle selon laquelle une entité doit être déclarée n'est une contrainte de forme
que si on a standalone='yes'
.
Contrainte de validité : Entité déclarée
Dans un document avec un sous-ensemble externe ou des entités paramètres externes, avec standalone='no'
, la valeur de type
Nom
donnée dans l'appel d'entité DOIT
correspondre à celle dans une déclaration d'entité. Pour des raisons d'interopérabilité,
les documents valides DEVRAIENT déclarer les entités amp
, lt
,
gt
, apos
, quot
, selon la forme spécifiée au chapitre
4.6 Les entités prédéfinies. La déclaration d'une entité paramètre
DOIT précéder tout appel de celle-ci. De même, la déclaration d'une entité générale
DOIT précéder toute déclaration de liste d'attributs contenant une valeur implicite en rapport
direct ou indirect avec cette entité générale.
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 :]
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 l'entité n'est pas interne, alors c'est une entité externe
déclarée comme suit :]
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.
[Définition : La valeur LittéralSystème
est appelée l'identificateur système de l'entité. Celui-ci doit être converti en un appel d'adresse URI (comme défini dans le document
[IETF RFC 2396], mis à jour par [IETF RFC 2732]), lors de sa résolution afin d'alimenter le processeur XML
pour qu'il construise le texte de remplacement de l'entité.] Un identificateur de fragment (commençant par un caractère #
) qui ferait
partie d'un identificateur système constituerait une erreur. À moins d'informations hors du propos de cette spécification (par exemple, un type
d'élément XML spécial défini par un DTD particulier, ou une instruction de traitement définie par une spécification d'application particulière), les
adresses URI relatives ne le sont que par rapport à l'emplacement de la ressource au sein de laquelle la déclaration d'entité apparaît. Cet emplacement est
défini comme étant l'entité externe contenant le caractère <
qui marque le commencement de la déclaration, au moment où celle-ci est interprétée
en tant que déclaration. Une adresse URI peut ainsi être relative à l'entité document,
à l'entité contenant le sous-ensemble de DTD externe, ou à une autre
entité paramètre externe. Les tentatives pour rechercher la ressource identifiée par une adresse URI
PEUVENT être redirigées au niveau de l'analyseur (par exemple, dans un module de résolution d'entité)
ou à un niveau inférieur (au niveau du protocole, par exemple via une en-tête HTTP Location:
). En l'absence d'autres informations au sein
de la ressource (hors du propos de cette spécification), l'adresse URI de base d'une ressource est toujours l'adresse de la ressource réelle retournée.
En d'autres termes, c'est l'adresse URI de la ressource recherchée après que toute la redirection a eu lieu.
Les identificateurs systèmes (et les autres chaînes XML destinées à une utilisation comme appels d'adresse URI)
PEUVENT contenir des caractères qui, selon les documents [IETF RFC 2396] et
[IETF RFC 2732], doivent être échappés avant que l'adresse URI puisse être exploitée pour rechercher la ressource référencée.
Les caractères à échapper sont les caractères de contrôle de #x0
à #x1F
, et #x7F
(la plupart d'entre eux ne peuvent apparaître dans XML),
le caractères espace #x20 ( )
, les délimiteurs #x3C (<)
, #x3E (>)
et #x22 (")
, les caractères spéciaux
#x7B ({)
, #x7D (})
, #x7C (|)
, #x5C (\)
, #x5E (^)
et #x60 (`)
, ainsi que tous les caractères au-delà de #x7F
.
Comme l'échappement n'est pas toujours une opération complètement réversible, on DOIT l'effectuer
seulement quand c'est absolument nécessaire et aussi tard que possible au cours du traitement. En particulier, ni l'opération de conversion d'une
adresse URI relative en une adresse absolue ni l'opération de transmission d'un appel d'adresse URI vers un traitement ou vers un composant logiciel chargés
de le résoudre ne DEVRAIENT initier d'échappement. Lorsque l'opération d'échappement a effectivement lieu,
elle DOIT se dérouler comme suit :
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 %HH
,
dans laquelle HH
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
.
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.
errata-E14
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 :
- Appel dans un contenu
c'est un appel n'importe où après la balise ouvrante et avant la
balise fermante d'un élément ; cela correspond au non-terminal contenu
.
- Appel dans une valeur d'attribut
c'est un appel depuis l'intérieur soit de la valeur d'un attribut dans une balise ouvrante, soit d'une
valeur implicite dans une déclaration d'attribut ; cela correspond au non-terminal
ValeurAtt
.
- Comme valeur d'attribut
c'est une valeur de type Nom
, et non un appel, qui apparaît soit comme valeur d'un attribut déclaré du type
ENTITY
, soit comme l'une des unités lexicales, séparées par des espaces, dans la valeur d'un attribut déclaré du type ENTITIES
.
- Appel dans une valeur d'entité
c'est un appel à l'intérieur de la valeur d'entité littérale d'un paramètre ou d'une
entité interne, dans la déclaration d'entité ; cela correspond au non-terminal ValeurEntité
.
- Appel dans un DTD
c'est un appel soit à l'intérieur des sous-ensembles interne ou externe du DTD,
mais hors des types ValeurEntité
, ValeurAtt
, IT
,
Commentaires
, LittéralSystème
et IdPubLittéral
,
soit dans le contenu d'une section conditionnelle ignorée (voir le chapitre 3.4 Les sections conditionnelles).
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 AT&T;
se développe en AT&T;
et le caractère esperluette (&) restant n'est pas reconnu comme délimiteur
d'appel d'entité.) Un appel de caractère est inclus lorsque le caractère désigné est traité à la place de l'appel en question.
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é ouvrage
est :
La Peste : Albert Camus,
© 1947 Éditions Gallimard. &droits;
L'appel d'entité générale &droits;
serait développé, si l'appel &ouvrage;
apparaissait dans
le contenu du document ou dans une valeur d'attribut.
Ces règles simples peuvent s'imbriquer de manière complexe ; voir l'explication détaillée d'un exemple difficile dans l'annexe
C Le développement des appels d'entité et de caractère.
[Définition : Les appels d'entité et de caractère
PEUVENT tous deux s'utiliser pour échapper les caractères inférieur à (<), esperluette (&)
et d'autres délimiteurs. Un jeu d'entités générales (amp
, lt
, gt
, apos
, quot
)
est défini dans ce but. On PEUT aussi employer des appels numériques de caractère ;
sitôt reconnues, ces entités sont immédiatement développées et DOIVENT être traitées
comme des données textuelles, on PEUT donc employer les appels numériques de caractère
<
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 lt
ou amp
sont déclarées, elles DOIVENT
l'être comme entités internes dont le texte de remplacement est un appel de caractère vers le caractère à échapper respectif (caractère inférieur à (<) ou esperluette (&) ;
le double échappement est OBLIGATOIRE pour ces entités, pour que les appels à celles-ci
donnent un résultat bien formé. Si les entités gt
, apos
ou quot
sont déclarées,
elles DOIVENT l'être comme entités internes dont le texte de remplacement est le seul caractère à
échapper (ou un appel de caractère à ce caractère : dans ce cas, le double échappement est
OPTIONNEL mais sans inconvénient). Par exemple :
<!ENTITY lt "&#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.]
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.
