Ce document est une traduction de la recommandation Extensible Markup
Language (XML) 1.0 du W3C,
datée du 10 février 1998. Cette version traduite peut contenir des
erreurs absentes de l'original, dues à la traduction elle-même. La
version originale en anglais, seule normative, se trouve à l'adresse http://www.w3.org/TR/1998/REC-xml-19980210.
Copyright © 1998 W3C (MIT, INRIA, Keio), tous droits réservés. Les règles du W3C sur la responsabilité, les marques de commerce, les droits d'auteur et les licences de logiciels sont applicables.
|
Le langage de balisage extensible (Extensible Markup Language, XML) est un sous-ensemble de SGML qui est complètement décrit dans ce document. Son but est de permettre au SGML générique d'être transmis, reçu et traité sur le Web de la même manière que l'est HTML aujourd'hui. XML a été conçu pour être facile à mettre en œuvre et interopérable avec SGML et HTML.
Ce document a été examiné par les membres du W3C et d'autres parties intéressées et a été approuvé par le directeur comme Recommandation du W3C. Ce document est stable et peut servir de référence ou être cité comme standard dans un autre document. En promulgant cette recommandation, le W3C cherche à attirer l'attention sur la spécification et à promouvoir sa mise en œuvre. Cette action améliore la fonctionalité et l'interopérabilité du Web.
Ce document précise une syntaxe créée en extrayant un sous-ensemble d'une norme internationale de traitement de texte existante et largement utilisée (le langage normalisé de balisage généralisé, ISO 8879:1986(F) tel qu'amendé et corrigé), dans le but de l'utiliser sur le Web. C'est un produit de l'activité XML du W3C, sur laquelle on trouvera de l'information à l'adresse http://www.w3.org/XML. Une liste des recommandations en vigueur du W3C et d'autres documents techniques se trouve à l'adresse http://www.w3.org/TR.
Ce document utilise le terme URI, défini dans [Berners-Lee et al.], un travail en cours destiné à mettre à jour les documents [IETF RFC1738] et [IETF RFC1808].
La liste des erreurs connues de cette spécification est disponible à l'adresse http://www.w3.org/XML/xml-19980210-errata.
On est prié de signaler toute erreur dans ce document à xml-editor@w3.org.
Le Langage de balisage extensible [en anglais Extensible Markup Language] (abrégé XML) décrit une classe d'objets de données appelés documents XML et décrit partiellement le comportement des programmes qui les traitent. XML est un profil d'application ou une forme restreinte de SGML, le langage normalisé de balisage généralisé [ISO 8879]. Par construction, les documents XML sont des documents conformes à SGML.
Les documents XML se composent d'unités de stockage appelées entités, qui contiennent des données analysables ou non. Les données analysables se composent de caractères, certains formant les données textuelles, et le reste formant le balisage. Le balisage décrit les structures logique et de stockage du document. XML fournit un mécanisme pour imposer des contraintes à ces structures.
Un module logiciel appelé processeur XML est utilisé pour lire les documents XML et pour accéder à leur contenu et à leur structure. On suppose qu'un processeur XML effectue son travail pour le compte d'un autre module, appelé l'application. Cette spécification décrit le comportement requis d'un processeur XML, c'est à dire la manière 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 (GT) XML [XML Working Group] (initialement connu sous le nom de comité d'examen éditorial SGML [SGML Editorial Review Board]) constitué sous les auspices du Consortium du World Wide Web (W3C) en 1996. Le GT était présidé par Jon Bosak de Sun Microsystems avec la participation active d'un groupe d'intérêt XML [XML Special Interest Group] (auparavant connu sous le nom de groupe de travail de SGML [SGML Working Group]) également organisé par le W3C. La liste des membres du groupe de travail XML est donnée en annexe. Dan Connolly agissait comme contact du W3C auprès du GT.
Les objectifs de conception de XML sont les suivants :
Cette spécification, ainsi que certaines normes associées (Unicode et l'ISO/CEI 10646 pour les caractères, le RFC 1766 Internet pour les balises d'identification de langue, l'ISO 639 pour les codes de noms de langue et l'ISO 3166 pour les codes de noms de pays) fournissent toutes les informations nécessaires pour comprendre la version 1.0 de XML et pour construire des programmes pour la traiter.
Cette version de la spécification de XML peut être distribuée librement, à condition que tout le texte et les notices juridiques demeurent intacts.
La terminologie employée pour décrire les documents XML est définie dans cette spécification. Les termes définis dans la liste suivante sont utilisés pour établir ces définitions et pour décrire les actions d'un processeur XML :
Un objet de données est un document XML s'il est bien formé, tel que précisé dans cette spécification. De plus, un document XML bien formé peut être valide s'il obéit à certaines autres contraintes.
Chaque document XML a une structure logique et une structure physique. Physiquement, le document se compose d'unités appelées entités. Une entité peut appeler d'autres entités pour causer leur inclusion dans le document. Un document commence à la « racine » ou 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, qui sont indiqués dans le document par du balisage explicite. Les structures logiques et physiques doivent s'imbriquer correctement, tel que décrit dans « 4.3.2 Entités analysables bien formées ».
Un objet textuel est un document XML bien formé si :
document ;
| Document | ||||
|
La correspondance à la production document implique que :
En conséquence, pour chaque élément
F (autre que la racine) dans le document, il y a un autre
élément P dans le document tel que F est
dans le contenu de P, mais n'est dans le contenu d'aucun
autre élément qui est dans le contenu de
P. P est connu comme parent de
F, et F comme fils de
P.
Une entité analysable contient du texte, une suite de caractères qui peuvent représenter du balisage ou des données textuelles. Un caractère est une unité de texte tel que précisé par l'ISO/CEI 10646 [ISO/CEI 10646]. Les caractères admissibles sont la tabulation, le retour de chariot, le retour à la ligne, et les caractères d'Unicode et de l'ISO/CEI 10646 permis par la production [2] ci-dessous. L'utilisation des « caractères de compatibilité », tel que définis dans la section 6.8 de [Unicode], est déconseillée.
| Ensemble de caractères | ||||||
|
Le mécanisme de codage des positions de code de caractère en configurations binaires peut varier d'une entité à l'autre. Tous les processeurs XML doivent accepter les codages UTF-8 et UTF-16 de l'ISO/CEI 10646 ; les mécanismes pour signaler lequel des deux est utilisé ou pour introduire d'autres codages sont discutés ci-dessous dans « 4.3.3 Codage des caractères dans les entités ».
Ce paragraphe définit quelques symboles souvent utilisés dans la grammaire.
S (séparateurs, blanc) se compose
d'un ou plusieurs des caractères espace (#x20), retour de chariot,
retour à la ligne, ou tabulation.
| Séparateurs | ||||
|
Par commodité, les caractères sont classifiés en lettres, chiffres ou autres caractères. Une lettre est un caractère de base alphabétique ou syllabique ou encore un caractère idéographique. Des définitions complètes des classes de caractères sont données dans « B. Classes de caractères ».
Un nom est une unité lexicale
commençant par une lettre ou par un des caractères de ponctuation
d'une courte liste, suivi de lettres, de chiffres, de traits d'union,
de traits de soulignement, de deux points ou de points finals, tous
connus comme caractères constitutifs de nom. Les noms commençant par
la chaîne de caractères « xml », ou par
n'importe quelle chaîne de caractères correspondant à (('X'|'x')
('M'|'m') ('L'|'l')), sont réservés à des fins de normalisation dans
cette version ou dans des versions ultérieures de la spécification.
Note : Le caractère deux points dans les noms XML est réservé pour l'expérimentation avec les espaces de nom. On s'attend à ce que sa signification soit normalisée bientôt ; les documents utilisant les deux points dans un but expérimental pourront alors nécessiter une mise à jour. (Il n'y a aucune garantie que le mécanisme d'espace de nom éventuellement adopté pour XML utilise en fait les deux points comme séparateur.) Dans la pratique, ceci signifie que les auteurs ne devraient pas utiliser les deux points dans les noms XML, sauf en tant qu'élément expérimental d'espace de nom, mais que les processeurs XML devraient accepter les deux points comme caractère constitutif de nom.
Un AtomeNml (atome nominal)
est une suite de caractères constitutifs de nom.
| Noms et atomes nominaux | ||||||||||||||||||||
|
Une chaîne délimitée, ne contenant pas les guillemets (anglais,
" ou ') utilisés comme délimiteur, constitue ce que l'on appelle
« un littéral ». Des littéraux sont utilisés pour préciser le
contenu des entités internes (ValeurEntité), des valeurs des
attributs (ValeurAtt) et des
identificateurs externes (LittéralSystème). Notez qu'un
LittéralSystème peut être
analysé sans rechercher le balisage.
| Littéraux | ||||||||||||||||||||||||||||
|
Le texte se compose de données textuelles et de balisage. Le balisage prend la forme de balises ouvrantes, de balises fermantes, de balises d'éléments vides, d'appels d'entité, d'appels de caractère, de commentaires, de délimiteurs de section CDATA, de déclarations de type de document, et d'instructions de traitement.
Tout le texte qui n'est pas du balisage constitue les données textuelles du document. Il est à noter que du texte correspondant au non-terminal S (production [3]) est du balisage et non pas des données textuelles.
Les caractères esperluète (&) et crochet gauche (<)
peuvent apparaître sous leur forme littérale seulement quand
ils sont utilisés comme délimiteurs de balisage ou dans un commentaire, une instruction
de traitement, ou une section
CDATA. S'ils sont nécessaires ailleurs, ils doivent
être déguisés en utilisant des appels de caractères numériques ou en utilisant
les chaînes de caractères « & » et
« < » respectivement. Le crochet droit
(>) peut être représenté en utilisant la chaîne de caractères
« > » et doit, pour
compatibilité, être déguisé en utilisant
« > » ou un appel de caractère quand il
apparaît dans la chaîne de caractères
« ]]> » dans du contenu, quand cette chaîne
ne marque pas la fin d'une section
CDATA.
Dans le contenu des éléments, toute chaîne de caractères ne
contenant pas un délimiteur de début de balisage est considéré donnée
textuelle. Dans une section CDATA, toute chaîne de caractères ne
contenant pas le délimiteur de fin de section CDATA,
« ]]> », est considéré donnée textuelle.
L'apostrophe (') peut être représentée par
« ' », et le caractère guillemet
anglais (") par « " », afin de
permettre à des valeurs d'attribut de contenir ces caractères.
| Données textuelles | ||||
|
Les commentaires peuvent apparaître
n'importe où dans un document en dehors d'autre balisage ; de plus, ils peuvent apparaître
dans la déclaration de type de document aux endroits permis par la
grammaire. Ils ne font pas partie des données
textuelles du document ; un processeur XML peut permettre à
une application de récupérer le texte des commentaires. À des fins de compatibilité, la chaîne
« -- » (double trait d'union) ne doit pas
apparaître à l'intérieur de commentaires.
| Commentaires | ||||
|
Exemple de commentaire :
<!-- déclarations pour <en-tête> & <corps> --> |
Il est à noter que la grammaire ne permet pas qu'un commentaire se
termine par --->. L'exemple suivant est mal
formé :
<!-- B+, B ou B---> |
Les instructions de traitement (IT) permettent aux documents de contenir des instructions pour des applications.
| Instructions de traitement | ||||||||
|
Les IT ne font pas partie des données
textuelles des documents mais doivent être transmises à
l'application. Une IT commence par une cible (CibleIT) qui identifie l'application à
laquelle l'instruction est destinée. Les noms de cible
« XML », « xml » et
ainsi de suite sont réservés à des fins de standardisation dans cette
version ou des versions ultérieures de cette spécification. Le
mécanisme de Notation de XML peut être
utilisé pour la déclaration formelle des cibles d'IT.
Les sections CDATA peuvent se
trouver à n'importe quel endroit acceptable pour des données
textuelles ; elles sont employées pour déguiser des blocs de
texte contenant des caractères qui seraient autrement identifiés comme
balisage. Les sections CDATA commencent par la chaîne
« <![CDATA[ » et se terminent par la chaîne
« ]]> ».
| Sections CDATA | ||||||||||||||||
|
Dans une section CDATA, seule la chaîne de caractères FinDT est identifiée comme balisage, de
sorte que les crochets gauches et les esperluètes peuvent s'y trouver
littéralement ; ils n'ont pas besoin (et ne peuvent pas) être
déguisés en utilisant « < » et
« & ». Les sections CDATA ne peuvent
pas s'imbriquer.
Voici un exemple de section CDATA, dans lequel
« <accueil> » et
« </accueil> » sont reconnus comme données textuelles, et non comme balisage :
<![CDATA[<accueil>Bonjour!</accueil>]]> |
Les documents XML peuvent, et devraient, commencer par une déclaration XML qui indique la version de XML utilisée. L'exemple suivant est un document XML, bien formé mais non valide :
<?xml version="1.0"?> |
ainsi que celui-ci :
<accueil>Bonjour!</accueil> |
Le numéro de version « 1.0 » devrait être
employé pour indiquer la conformité à cette version de la
spécification ; un document utilisant la valeur
« 1.0 » mais ne se conformant pas à cette
version de la spécification est en erreur. Le Groupe de travail XML a
l'intention de produire des versions ultérieures à la version
« 1.0 », mais cette intention ne signifie
aucunement un engagement à produire de futures versions de XML ni, si
d'autres versions sont produites, à utiliser un plan de numérotation
particulier. Puisque de futures versions ne sont pas exclues,
cette construction est un moyen de permettre l'identification
automatique de la version, si celle-ci devient nécessaire. Les
processeurs peuvent signaler une erreur s'ils reçoivent des documents
étiquetés avec des versions qu'ils ne connaissent pas.
La fonction du balisage dans un document XML est de décrire sa structure de stockage et sa structure logique et d'associer des paires attributs-valeurs à ses structures logiques. XML fournit un mécanisme, la déclaration de type de document, pour définir des contraintes sur la structure logique et pour gérer l'utilisation des unités de stockage prédéfinies.Un document XML est valide si une déclaration de type de document y est associée et si le document est conforme aux contraintes qu'elle exprime.
La déclaration de type de document doit apparaître avant le premier élément dans le document.
| Prologue | ||||||||||||||||||||||||
|
La déclaration de type de document XML contient ou désigne des déclarations de balisage qui fournissent une grammaire pour une classe de documents. Cette grammaire est connue comme déclaration de type de document, ou DTD. La déclaration de type de document peut désigner un sous-ensemble externe (un genre spécial d'entités externes) contenant des déclarations de balisage, peut contenir des déclarations de balisage directement dans un sous-ensemble interne ou peut faire les deux. La DTD d'un document se compose des deux sous-ensembles regroupés.
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és ou une déclaration de notation. Ces déclarations peuvent être contenues entièrement ou partiellement dans des entités paramètres, tel que décrit ci-dessous dans les contraintes de forme et de validité. Pour plus d'informations, voir « 4. Structure physique ».
| Définition de type de document | ||||||||||||||||||||||||||||||
|
Les déclarations de balisage peuvent se composer entièrement ou
partiellement du texte de remplacement
d'entités paramètres. Les productions ultérieures
dans cette spécification pour différents non-terminaux (déclÉlément, DéclListeAtt, et ainsi de suite)
décrivent les déclarations après que toutes les entités
paramètres aient été développées.
Contrainte de validité : Type
de l'élément racine
Le Nom dans la déclaration de type
de document doit correspondre au type d'élément de l'élément racine.
Contrainte de forme :
Sous-ensemble externe bien formé
Le sous-ensemble externe, s'il y a lieu, doit correspondre à la
production [30] sousEnsembleExt.
Contrainte de forme :
Entités paramètre bien formées
Une entité paramètre appelée dans une déclTypeDoc doit correspondre soit à la
production [30] sousEnsembleExt (si
externe), soit à la production [31] déclSousEnsembleExt (si interne).
Contrainte de validité :
Imbrication stricte des déclarations et des EP
Le texte de remplacement des entités
paramètres doit être correctement imbriqué dans les déclarations de
balisage. Si le premier ou le 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, tous les deux doivent
être contenus dans le même texte de remplacement.
Contrainte de forme :
EP dans le sous-ensemble interne
Dans le sous-ensemble interne de la DTD, les appels
d'entité paramètre peuvent se produire seulement là où les
déclarations de balisage sont permises, pas à l'intérieur des
déclarations de balisage. (Ceci ne s'applique pas aux appels qui se
produisent dans les entités paramètres externes ou au sous-ensemble
externe.)
Tout comme le sous-ensemble interne, le sous-ensemble externe et
les entités paramètres externes mentionnés dans la DTD doivent se
composer d'une série de déclarations de balisage complètes des types
permis par le symbole non-terminal déclBalisage, parsemées d'espaces ou
d'appels d'entité paramètre. Cependant, des
parties du contenu du sous-ensemble externe ou des entités paramètres
externes peuvent conditionnellement être ignorées en utilisant le
mécanisme de section
conditionnelle ; ceci n'est pas permis dans le sous-ensemble
interne. Le sous-ensemble externe et toute entité paramètre externe
mentionnée dans la DTD doivent correspondre à la production entParExt. Cf. la section 4.3.2 Entités analysables bien formées.
| Sous-ensemble externe | ||||||||
|
Le sous-ensemble externe et les entités paramètres externes diffèrent également du sous-ensemble interne, les appels d'entité paramètre y étant autorisés à l'intérieur des déclarations de balisage, et non seulement entre les déclarations de balisage.
Exemple de document XML avec une déclaration de type de document :
<?xml version="1.0"?>
|
L'identificateur de système
« bonjour.dtd » donne l'URI d'une DTD pour le
document.
Les déclarations peuvent également être données localement, comme dans l'exemple suivant :
<?xml version="1.0" encoding="UTF-8" ?>
|
Si les sous-ensembles externes et internes sont utilisés, le sous-ensemble interne est considéré comme se produisant avant le sous-ensemble externe. Ceci a pour effet que les déclarations d'entités et de liste d'attributs du sous-ensemble interne ont priorité sur celles du sous-ensemble externe.
Les déclarations de balisage peuvent affecter le contenu du document, tel qu'il est transmis d'un processeur XML à une application ; des exemples sont des valeurs d'attribut implicites et des déclarations d'entité. La déclaration de document autonome, qui peut apparaître comme composante de la déclaration de XML, précise s'il y a de telles déclarations externes à l'entité document..
| Déclaration de document autonome | ||||||
|
Dans une déclaration de document autonome, la valeur
« yes » indique qu'il n'y a pas de déclarations
de balisage externes à l'entité document
(dans le sous-ensemble externe de DTD, ou dans une entité paramètre
externe appelée dans le sous-ensemble interne) qui affecterait
l'information transmise du processeur XML à l'application. La valeur
« no » indique qu'il y a ou peut y avoir de
telles déclarations de balisage externes. Notez que la déclaration de
document autonome précise seulement la présence de
déclarations externes ; la présence, dans un document,
d'appels à des entités externes ne change pas son caractère
d'autonomie, quand ces entités sont déclarées dans le sous-ensemble
interne.
S'il n'y a aucune déclaration de balisage externe, la déclaration
de document autonome n'a aucune signification. S'il y a des
déclarations de balisage externes mais pas de déclaration de document
autonome, la valeur « no » est présumée.
Tout document XML non-autonome (standalone="no") peut
être converti algorithmiquement en document autonome, ce qui peut
être souhaitable pour des applications diffusées en réseau.
Contrainte de validité :
déclaration de document autonome
La déclaration de document autonome doit avoir la valeur
« no » si des déclarations de balisage externes
contiennent les déclarations suivantes :
amp, lt,
gt, apos et quot), si des appels à ces entités apparaissent dans le
document, ou Exemple de déclaration XML avec une déclaration de document autonome :
<?xml version="1.0" standalone='yes'?> |
En éditant des documents XML, il est souvent commode d'employer « du blanc » (des espaces, tabulations et interlignes) pour distinguer le balisage pour une plus grande lisibilité. Du tel blanc n'est pas typiquement destiné à être inclus dans la version livrée du document. D'autre part, le blanc « significatif » qui devrait être préservé dans la version livrée est courant, par exemple en poésie et en code source.
Un processeur XML doit toujours transmettre à l'application tous les caractères d'un document qui ne sont pas du balisage. Un processeur XML validateur doit également informer l'application desquels de ces caractères constituent le blanc apparaissant dans du contenu élémentaire pur.
Un attribut spécial nommé
xml:space peut être associé à un élément pour signaler
l'intention que dans cet élément, le blanc soit préservé par
les applications. Dans les documents valides, cet attribut, comme tout
autre, doit être déclaré s'il est utilisé.
Si déclaré, il doit être donné comme type énuméré dont les seules valeurs
possibles sont « default » et
« preserve ». Par exemple :
<!ATTLIST poème xml:space (default|preserve) 'preserve'> |
La valeur « default » indique que les modes
implicites de traitement du blanc sont acceptables pour cet
élément ; la valeur « preserve » demande
que les applications préservent tout le blanc. Cette intention
déclarée s'applique à tous les éléments à l'intérieur du contenu de
l'élément porteur de la déclaration, à moins qu'elle ne soit annulée
par une autre apparition de l'attribut de xml:space.
L'élément racine de n'importe quel document est considéré comme n'avoir indiqué aucune intention en ce qui concerne le traitement du blanc, à moins qu'il ne fournisse une valeur pour cet attribut ou que l'attribut ne soit déclaré avec une valeur implicite.
Des entités XML analysables sont souvent enregistrées dans des fichiers qui, pour la commodité d'édition, sont organisés en lignes. Ces lignes sont typiquement séparées par une combinaison du caractère retour chariot (#xD) et retour à la ligne (#xA).
Pour simplifier la tâche des applications, quand une entité externe analysable ou une valeur littérale d'entité d'une entité analysable interne contient soit la séquence de deux caractères littéraux « #xD#xA » soit un littéral #xD, un processeur XML doit transmettre à l'application le seul caractère #xA. (Ce comportement peut simplement être produit en normalisant toutes les bris de ligne à #xA à l'entrée, avant l'analyse.)
Dans le traitement de document, il est souvent utile d'identifier
la langue naturelle ou formelle dans laquelle le contenu est écrit. Un
attribut nommé xml:lang peut être
inséré dans les documents pour indiquer la langue utilisée dans le
contenu et dans les valeurs d'attributs de tout élément d'un document
XML. Dans les documents valides, cet attribut, comme tout autre, doit
être declaré s'il est utilisé. Les valeurs
de l'attribut sont des identificateurs de langue tels que définis par [IETF RFC 1766], « Balises pour
l'identification des langues » :
| Identification de Langue | ||||||||||||||||||||||||
|
Les paragraphes qui suivent constituent un résumé non-normatif de la définition des codes de langue de [IETF RFC 1766].
Le CodeLang peut être :
i- » (ou
« I- ») ;x- » ou « X- » afin
de s'assurer qu'ils ne sont pas en conflit avec des noms normalisés
ultérieurement ou inscrits à l'IANA.Il peut y avoir n'importe quel nombre de segments SousCode ; si le CodeLang est un
CodeISO639 et si le premier existe et est formé de deux lettres, il doit
être un code de pays de [ISO 3166],
« Codes pour la représentation des noms des pays. » Si le
premier sous-code se compose de plus de deux lettres, ce
doit être un code inscrit à l'IANA pour la langue en
question, à moins que le CodeLang ne commence par le préfixe
« x- » ou « X- ».
Il est usuel de donner le code de langue en minuscules, et le code de pays (s'il y a lieu) en majuscules. Notez que ces valeurs, à la différence d'autres noms dans les documents XML, ne sont pas sensibles à la casse.
Exemples :
<p xml:lang="fr">Cachez ce sein que je ne saurais voir.</p>
|
L'intention déclarée avec xml:lang est considérée
s'appliquer à tous les attributs et au contenu de l'élément où on
l'indique, à moins qu'elle ne soit annulée par une apparition de
xml:lang sur un autre élément dans ce contenu.
Une déclaration simple pour xml:lang pourrait prendre
la forme
xml:lang NMTOKEN #IMPLIED |
mais des valeurs implicites spécifiques peuvent également être attribuées, si appropriées. Dans une collection de poésie française pour étudiants anglais, avec des gloses et des notes en anglais, l'attribut xml:lang pourrait être déclaré de cette façon :
<!ATTLIST poésie xml:lang NMTOKEN 'fr'>
|
Chaque document XML contient un ou plusieurs éléments, dont les limites sont marquées soit par des balises ouvrantes et fermantes, soit, pour les éléments vides, par une balise d'élément vide. Chaque élément a un type, identifié par un nom, parfois appelé son « identificateur générique » (IG), on peut y associer un jeu de spécifications d'attribut. Chaque spécification d'attribut comprend un nom et une valeur.
| Élément | ||||||||||||||||
|
Cette spécification ne contraint pas la sémantique,
l'utilisation ou (au-delà de la syntaxe) les noms des types
d'éléments ou d'attributs, hormis le fait que les noms qui
commencent par (('X'|'x')('M'|'m')('L'|'l')) sont
réservés à des fins de standardisation dans cette version ou
d'ultérieures versions de cette spécification.
Contrainte de forme : Correspondance de type d'élément
Le Nom dans une balise
fermante d'un élément doit correspondre au type d'élément de
la balise ouvrante.
Contrainte de validité : Élément valide
Un élément est valide s'il existe une déclaration
correspondant à déclÉlément
où le nom correspond à
un type d'élément, et l'une des conditions suivantes est
vraie :
EMPTY
et l'élément n'a pas de contenu.sousÉléments
et la suite de sous-éléments
appartient au langage engendré par l'expression
régulière du modèle de contenu, avec du blanc
optionnel (des caractères correspondant au non-terminal S) entre la balise ouvrante et
le premier sous-élément, entre les sous-éléments ou entre le dernier
sous-éléments et la balise fermante. Il est à noter qu'une section CDATA ne contenant que du
blanc ne correspond pas au non-terminal S et par conséquent ne peut
apparaître en ces positions.Mixte et le contenu est
constitué de données textuelles
et de sous-éléments dont
les types correspondent aux noms dans le modèle du
contenu.ANY
et le type de chaque sous-élément
a été déclaré. Le début de chaque élément XML non vide est marqué d'une balise ouvrante (ou balise de début).
| Balise ouvrante | ||||||||||||||||||||||||||||||
|
Le Nom des balises de début et
de fin spécifie le type de l'élément.
Les couples Nom-ValeurAtt constituent les
spécifications d'attribut de l'élément, avec pour chaque couple
le Nom
désigné par le nom de l'attribut, et le contenu de ValeurAtt (le texte compris entre
les délimiteurs « ' » ou
« " ») désigné par la valeur de
l'attribut. Il est à noter 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 unique de l'attribut
Aucun nom d'attribut ne peut apparaître plus d'une fois dans la
même balise de début ou d'élément vide.
Contrainte de validité : Type de valeur de l'attribut
L'attribut doit avoir été déclaré; la valeur doit
correspondre au type déclaré pour cet attribut. (Pour les types
d'attribut, voir « 3.3 Déclarations
des listes d'attributs ».)
Contrainte de forme : Pas d'appel d'entité externe
Les valeurs d'attribut ne peuvent contenir d'appels d'entité
directs ou indirects à des entités externes.
Contrainte de forme : Pas de <
dans les valeurs d'attribut
Le texte de remplacement de toute
entité appelée directement ou indirectement dans une valeur
d'attribut (autre que « < ») ne
peut contenir un <.
Contrainte de validité :
xml:lang valide
Si le Nom dans une spécification
d'attribut est xml:lang, la valeur, après normalisation
en tant que NMTOKEN, doit correspondre à la production [33].
Exemple de balise ouvrante:
<termdef id="dt-chien" terme="chien"> |
La fin de chaque élément qui commence par une balise de début doit être marqué d'une balise fermante (ou balise de fin) contenant un nom qui renvoie au type de l'élément spécifié dans la balise de début :
| Balise fermante | ||||
|
Exemple de balise fermante :
</termdef> |
On appelle le texte compris entre les balises de début et de fin le contenu de l'élément :
| Contenu des éléments | ||||
|
Si un élément est vide, il devrait être indiqué soit par une balise ouvrante suivie immédiatement d'une balise fermante, soit par une balise d'élément vide. Une balise d'élément vide se formule d'une manière particulière :
| Balises pour éléments vides | ||||||
|
Les balises d'élement vide peuvent être utilisées pour tout élément
qui n'a pas de contenu, qu'il ait été déclaré ou non avec le mot-clé
EMPTY. À des fins
d'interopérabilité, il est souhaitable d'utiliser la balise
d'élément vide pour les éléments qui ont été déclarés EMPTY et de ne pas
l'utiliser ailleurs.
Exemples d'éléments vides :
<IMG align="left" |
La structure des éléments d'un document XML peut, à des fins de validation, être contrainte à l'aide de déclarations de type d'élément et de liste d'attributs. La déclaration de type d'un élément contraint le contenu de cet élément.
Les déclarations de type d'un élément limitent habituellement les types d'élément qui peuvent apparaître comme sous-éléments de celui-ci. Au choix de l'utilisateur, un processeur XML peut émettre un avertissement quand une déclaration mentionne un type d'élément pour lequel aucune déclaration n'a été fournie, mais ceci ne constitue pas une erreur.
Une déclaration de type d'élément se formule de la façon suivante :
| Déclaration de type d'élément | ||||||||||
|
où le Nom fournit le type
d'élément que l'on déclare.
Contrainte de validité : Déclaration de type
d'élément unique
Aucun type d'élément ne peut être déclaré plus d'une fois.
Exemples de déclarations de type d'élément :
<!ELEMENT br EMPTY> |
Un type
d'élément a un contenu élémentaire pur quand des
éléments de ce type ne peuvent contenir que des sous-éléments, (pas de données
textuelles), séparés par du blanc (caractères correspondant au
non-terminal S) facultatif. Dans
ce cas, la contrainte comprend un modèle de contenu, une
grammaire simple régissant les types admis pour les
sous-éléments et l'ordre dans lequel ceux-ci peuvent
apparaître. Cette grammaire est construite à l'aide de
particules de contenu (pc),
constituées de noms, de listes de choix de particules de
contenu, ou de listes de suites de particules de contenu :
| Modèles de contenu élémentaire pur | ||||||||||||||||||||
|
où chaque Nom est le type
d'un élément qui peut apparaître comme sous-élément. Une particule de
contenu dans une liste de choix peut apparaître au sein d'un contenu élémentaire pur à l'endroit où
une liste de choix apparaît dans la grammaire; les particules de
contenu présentes dans une liste de suite doivent toutes
apparaître dans le contenu élémentaire pur
dans l'ordre précisé dans la liste. Les caractères
optionnels qui suivent un nom ou une liste déterminent si
l'élément ou les particules de contenu dans la liste peuvent
apparaître une fois ou plus (+), zéro fois ou plus
(*), ou bien au maximum 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. Leur
syntaxe et leur sens sont identiques à ceux qui sont utilisés
dans les productions de cette spécification.
Le contenu d'un élément correspond à un modèle de contenu si et seulement si l'on peut tracer un chemin à travers le modèle de contenu qui respecte les opérateurs de suite, de choix et de répétition et qui fait correspondre chaque élément du contenu à un type d'élément défini dans le modèle de contenu. À des fins de compatibilité, le fait qu'un élément dans le document puisse correspondre à plus d'une occurrence de ce type d'élément dans le modèle de contenu constitue une erreur. Pour de plus amples informations, voir « E. Modèles de contenu déterministes ».
Contrainte de validité : Imbrication stricte des
parenthèses dans EP
Les parenthèses des textes de remplacement d'une entité paramètre
doivent être strictement imbriqués. Ceci signifie que si la
parenthèse ouvrante ou fermante d'une production choix, séq ou Mixte se retrouve dans le texte de
remplacement d'une entité paramètre, ces deux
parenthèses doivent être contenues dans le même texte de
remplacement. À des fins d'interopérabilité,
si un appel d'entité paramètre apparaît dans une production choix, séq ou Mixte, son texte de remplacement
doit contenir au moins un caractère significatif (non blanc) ; de
plus, ni le premier ni le dernier caractère significatif (non blanc)
du texte de remplacement ne peuvent être un connecteur (|
ou ,).
Exemples de modèles de contenu élémentaire pur :
<!ELEMENT stipu (préface, corps, postface?)> |
Un type d'élément a un contenu mixte quand des éléments de ce type peuvent contenir des données textuelles, parsemées, le cas échéant, de sous-éléments. Dans ce cas, les types des sous-éléments peuvent être contraints mais pas leur ordre ni leur nombre.
| Déclaration de contenu mixte | ||||||||||||||||
|
où les Noms fournissent
les types des éléments qui peuvent apparaître comme
sous-éléments. L'étymologie du mot-clé PCDATA est l'anglais
« parsed character data », c'est à dire « données
textuelles analysables ».
Contrainte de validité : Type unique
Le même nom ne peut 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)*> |
On utilise des attributs pour associer des couples nom-valeur aux éléments. Les spécifications d'attribut ne peuvent apparaître qu'au sein de balises ouvrantes et de balises d'élément vide ; ainsi, les productions utilisées pour les reconnaître apparaissent dans « 3.1 Balises ouvrantes, balises fermantes et balises d'élément vide ». Les déclarations de liste d'attributs peuvent servir à :
Les déclarations de liste d'attributs précisent 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é :
| Déclaration de liste d'attributs | ||||||||
|
Le Nom dans la production DéclListeAtt correspond
au type d'un élément. Au choix de l'utilisateur, un processeur
XML peut émettre un avertissement si on déclare des attributs
pour un type d'élément qui lui-même n'est pas déclaré, mais ceci ne
constitue pas une erreur. Le Nom
que l'on retrouve dans la règle DéfAtt
correspond au nom de l'attribut.
Quand plus d'une DéclListeAtt existe pour un
type d'élément donné, le contenu de toutes les déclarations fournies
est fusionnée. Quand plus d'une définition existe pour un même
attribut d'un type d'élément donné, seule la première déclaration
compte, les déclarations subséquentes sont ignorées. À des fins d'interopérabilité, les rédacteurs
de DTD pourraient décider de fournir pas plus d'une déclaration de
liste d'attributs pour un type d'élément donné, pas plus d'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. De même, à des fins
d'interopérabilité, un processeur XML pourra au gré de l'utilisateur
émettre un avertissement quand il existe plus d'une déclaration de
liste d'attributs pour un type d'élément donné ou quand plus d'une
définition d'attribut existe pour un attribut donné, mais ceci ne
constitue pas une erreur.
Les types d'attribut XML sont de trois genres: un type chaîne, une série de types atomiques et des types énumérés. Le type chaîne peut prendre comme valeur toute chaîne littérale; les types atomiques subissent différentes contraintes lexicales et sémantiques précisées ci-dessous. Les contraintes de validité indiquées dans la grammaire s'appliquent après que la valeur d'attribut ait été normalisée de la façon précisée dans la section 3.3.3 Normalisation de valeur d'attribut.
| Types d'attribut | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Contrainte de validité : ID
Les valeurs de type ID doivent correspondre à la
production Nom. Un nom ne
peut apparaître plus d'une fois dans un document XML comme la
valeur de ce type, i.e. les valeurs ID doivent
identifier uniquement les éléments qu'elles désignent..
Contrainte de validité : Un seul ID par type
d'élément
Aucun type d'élément ne peut posséder plus d'un attribut ID.
Contrainte de validité : Valeur implicite de l'attribut ID
Un attribut ID doit avoir comme valeur implicite déclarée
soit #IMPLIED soit #REQUIRED.
Contrainte de validité : IDREF
Les valeurs de type IDREF doivent correspondre à la
production Nom, et les
valeurs de type IDREFS doivent correspondre à des Noms ; chaque Nom doit correspondre à la
valeur d'un attribut ID sur un élément quelconque du document
XML, en d'autres mots les valeurs IDREF doivent
correspondre à la valeur d'un attribut ID.
Contrainte de validité : Nom d'entité
Les valeurs de type ENTITY doivent correspondre à
la production Nom , les
valeurs de type ENTITIES doivent correspondre à des
Noms ; chaque Nom doit correspondre au nom
d'une entitée non-analysable déclarée
dans la DTD.
Contrainte de validité : Atome nomimal
Les valeurs de type NMTOKEN doivent correspondre à
la production AtomeNml ;
les valeurs de type NMTOKENS doivent correspondre à
des AtomeNmx.
Les attributs énumérés peuvent prendre une valeur parmi une liste de valeurs fournie dans la déclaration. Il existe deux sortes de types énumérés :
| Types d'attributs énumérés | ||||||||||||||||||||||
|
Un attribut NOTATION identifie une notation, déclarée dans la DTD
conjointement avec ses identificateurs systèmes et publics, que
l'on utilisera pour interpréter l'élément auquel l'attribut
est joint.
Contrainte de validité : Attributs de notation
Les valeurs de ce type doivent correspondre à 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
Nul élément ne peut avoir plus d'un attribut de type NOTATION.
Contrainte de validité : Énumération
Les valeurs de ce type doivent correspondre à un des atomes AtomeNml dans la
déclaration.
À des fins d'interopérabilité,
le même AtomeNml ne
devrait pas apparaître plus d'une fois dans les types d'attribut
énuméré d'un même type d'élément.
Une déclaration d'attribut précise si la présence de l'attribut est exigée et, si elle ne l'est pas, précise le comportement du processeur XML quand l'attribut déclaré est absent dans un document.
| Valeurs implicites des attributs | ||||||||||||||||||||||||||||
|
Dans une déclaration d'attribut, #REQUIRED
signifie que l'attribut doit toujours être fourni, #IMPLIED
qu'aucune valeur implicite n'est fournie. Si
la déclaration n'est ni #REQUIRED ni #IMPLIED
alors la valeur de ValeurAtt
précise la valeur implicite déclarée; le mot-clé #FIXED
indique que l'attribut doit toujours avoir la valeur implicite. Si
une valeur implicite est déclarée, le processeur XML doit se comporter comme
si l'attribut était présent et égal à la valeur implicite déclarée
lorsqu'il s'aperçoit de l'absence d'un attribut.
Contrainte de validité : Attribut obligatoire
Si la déclaration implicite est le mot-clé #REQUIRED
il faut alors préciser l'attribut pour tous les éléments du
type dans la déclaration de la liste d'attributs.
Contrainte de validité :
Valeur implicite de l'attribut permise
La valeur implicite déclarée doit satisfaire aux contraintes
lexicales du type d'attribut déclaré.
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 |
Avant que la valeur d'un attribut ne soit passée à l'application ou que l'on vérifie sa validité, mais après normalisation des fins de ligne selon la section 2.11 Traitement des fins de ligne, le processeur XML doit normaliser cette valeur de la façon suivante :
Si la valeur déclarée n'est pas CDATA alors le processeur XML devra poursuivre le traitement de la valeur normalisée de l'attribut en se défaisant des espaces (#x20) de tête et de queue et en replaçant les suites d'espaces (#x20) par un seul caractère espace (#x20).
On notera que si la valeur d'attribut avant normalisation contient un appel de caractère à un séparateur autre que l'espace (#x20), la valeur normalisée contient le séparateur lui-même (#xD, #xA ou #x9). Ce cas diffère du cas où la valeur avant normalisation contient un séparateur (et non un appel), qui est remplacé par un caractère espace (#x20) dans la valeur normalisée et diffère aussi du cas où la valeur avant normalisation contient un appel d'entité dont le texte de remplacement contient un séparateur ; à cause du traitement récursif, ce séparateur est remplacé par un caractère espace dans la valeur normalisée.
Tous les attributs pour lesquels on n'a lu aucune déclaration devraient
être considérés par un processeur non-validateur comme si on les avait
déclarés au moyen de CDATA.
Les sections conditionnelles sont des portions du sous-ensemble externe de la déclaration de type de document qui, selon la valeur d'un mot-clé, sont incluses dans la structure logique de la DTD ou excluses de celles-ci.
| Section conditionnelle | ||||||||||||||||||||
|
À l'instar des sous-ensembles internes et externes de DTD, une section conditionnelle peut contenir une ou plusieurs instances complètes de déclarations, de commentaires, d'instructions de traitement ou de sections conditionnelles imbriquées, le tout parsemé de séparateurs (du blanc).
Si le mot-clé d'une section conditionnelle est INCLUDE
alors le contenu de la section conditionnelle fait partie de la
DTD. Si le mot-clé de la section conditionnelle est IGNORE
alors le contenu de la section conditionnelle ne fait pas partie,
au niveau logique, de la DTD. Remarquons qu'afin de rendre
l'analyse robuste, il faut lire le contenu des sections
conditionnelles même ignorées afin de détecter les sections conditionnelles
imbriquées et de s'assurer que la fin de la section conditionnelle
(ignorée) la plus englobante est correctement décelée. Si une section conditionnelle
marquée du mot-clé INCLUDE se trouve au sein d'une
section conditionnelle plus importante qui elle est marqué d'un mot-clé IGNORE,
les sections intérieure et extérieure sont toutes deux
ignorées.
Si le mot-clé d'une section conditionnelle est un appel d'entité paramètre, on remplacera l'entité paramètre par son contenu avant que le processeur ne décide s'il doit inclure ou ignorer la section conditionnelle.
Exemple :