Ce document est une traduction de la recommandation Extensible Markup Language (XML)
1.0 du W3C, datee du 10 fevrier 1998. Cette version traduite peut contenir des
erreurs absentes de l'original, dues a la traduction elle-meme. La version
originale en anglais, seule normative, se trouve a l'adresse http://www.w3.org/TR/1998/REC-xml-19980210.
Traducteurs :
Patrick ANDRIES (CAFI)
Samira CUNY (Universite de Bristol)
Francois YERGEAU (Alis Technologies)
Copyright (c) 1998 W3C (MIT, INRIA, Keio), tous droits reserves. Les regles du W3C
sur la responsabilite, les marques de commerce, les droits d'auteur et les
licences de logiciels sont applicables.
REC-xml-19980210
Langage de balisage extensible (XML) 1.0
Recommandation du W3C, 10 fevrier 1998
Cette version :
http://www.w3.org/TR/1998/REC-xml-19980210
http://www.w3.org/TR/1998/REC-xml-19980210.xml
http://www.w3.org/TR/1998/REC-xml-19980210.html
http://www.w3.org/TR/1998/REC-xml-19980210.pdf
http://www.w3.org/TR/1998/REC-xml-19980210.ps
Version la plus recente :
http://www.w3.org/TR/REC-xml
Version precedente :
http://www.w3.org/TR/PR-xml-971208
Redacteurs :
Tim Bray (Textuality and Netscape)
Jean Paoli (Microsoft)
C. M. Sperberg-McQueen (University of Illinois at Chicago)
Sommaire
Le langage de balisage extensible (Extensible Markup Language, XML) est un sous-ensemble
de SGML qui est completement decrit dans ce document. Son but est de permettre
au SGML generique d'etre transmis, recu et traite sur le Web de la meme maniere
que l'est HTML aujourd'hui. XML a ete concu pour etre facile a mettre en ?uvre
et interoperable avec SGML et HTML.
Statut de ce document
Ce document a ete examine par les membres du W3C et d'autres parties interessees
et a ete approuve par le directeur comme Recommandation du W3C. Ce document est
stable et peut servir de reference ou etre cite comme standard dans un autre
document. En promulgant cette recommandation, le W3C cherche a attirer l'attention
sur la specification et a promouvoir sa mise en ?uvre. Cette action ameliore la
fonctionalite et l'interoperabilite du Web.
Ce document precise une syntaxe creee en extrayant un sous-ensemble d'une norme
internationale de traitement de texte existante et largement utilisee (le
langage normalise de balisage generalise, ISO 8879:1986(F) tel qu'amende et
corrige), dans le but de l'utiliser sur le Web. C'est un produit de l'activite
XML du W3C, sur laquelle on trouvera de l'information a l'adresse http://www.w3.org/XML.
Une liste des recommandations en vigueur du W3C et d'autres documents techniques
se trouve a l'adresse http://www.w3.org/TR.
Ce document utilise le terme URI, defini dans [Berners-Lee et al.], un travail
en cours destine a mettre a jour les documents [IETF RFC1738] et [IETF RFC1808].
La liste des erreurs connues de cette specification est disponible a l'adresse
http://www.w3.org/XML/xml-19980210-errata.
On est prie de signaler toute erreur dans ce document a xml-editor@w3.org.
Langage de balisage extensible (XML) 1.0
Table des matieres
1. Introduction
1.1 Origine et buts
1.2 Terminologie
2. Documents
2.1 Documents XML bien formes
2.2 Caracteres
2.3 Constructions syntaxiques communes
2.4 Donnees textuelles et balisage
2.5 Commentaires
2.6 Instructions de traitement
2.7 Sections CDATA
2.8 Prologue et declaration de type de document
2.9 Declaration de document autonome
2.10 Traitement du blanc
2.11 Traitement des fins de ligne
2.12 Identification de langue
3. Structures logiques
3.1 Balises ouvrantes, balises fermantes et balises d'element vide
3.2 Declarations de type d'element
3.2.1 Contenu elementaire pur
3.2.2 Contenu mixte
3.3 Declarations de liste d'attributs
3.3.1 Types d'attribut
3.3.2 Valeurs implicites des attributs
3.3.3 Normalisation de valeur d'attribut
3.4 Sections conditionnelles
4. Structures physiques
4.1 Appels de caractere et d'entite
4.2 Declarations d'entites
4.2.1 Entites internes
4.2.2 Entites externes
4.3 Entites analysables
4.3.1 La declaration de texte
4.3.2 Entites analysables bien formees
4.3.3 Codage des caracteres dans les entites
4.4 Traitement des entites et des appels par un processeur XML
4.4.1 Non reconnu
4.4.2 Inclus
4.4.3 Inclus si validation
4.4.4 Interdit
4.4.5 Inclus dans litteral
4.4.6 Signale
4.4.7 Non interprete
4.4.8 Inclus comme EP
4.5 Construction du texte de remplacement d'une entite interne
4.6 Entites predefinies
4.7 Declarations de notation
4.8 L'entite document
5. Conformite
5.1 Processeurs validateurs et non-validateurs
5.2 Utilisation des processeurs XML
6. Notation
Annexes
A. Bibliographie
A.1 Bibliographie normative
A.2 Autres ouvrages
B. Classes de caracteres
C. XML et SGML (annexe informative)
D. Developpement des appels d'entite et de caracteres (annexe informative)
E. Modeles de contenu deterministes (annexe informative)
F. Auto-detection du codage de caracteres (annexe informative)
G. Groupe de travail XML du W3C (annexe informative)
1. Introduction
Le Langage de balisage extensible [en anglais Extensible Markup Language] (abrege
XML) decrit une classe d'objets de donnees appeles documents XML et decrit
partiellement le comportement des programmes qui les traitent. XML est un profil
d'application ou une forme restreinte de SGML, le langage normalise de balisage
generalise [ISO 8879]. Par construction, les documents XML sont des documents
conformes a SGML.
Les documents XML se composent d'unites de stockage appelees entites, qui
contiennent des donnees analysables ou non. Les donnees analysables se composent
de caracteres, certains formant les donnees textuelles, et le reste formant le
balisage. Le balisage decrit les structures logique et de stockage du document.
XML fournit un mecanisme pour imposer des contraintes a ces structures.
Un module logiciel appele processeur XML est utilise pour lire les documents XML
et pour acceder a leur contenu et a leur structure. On suppose qu'un processeur
XML effectue son travail pour le compte d'un autre module, appele l'application.
Cette specification decrit le comportement requis d'un processeur XML, c'est a
dire la maniere dont il doit lire des donnees XML et les informations qu'il doit
fournir a l'application.
1.1 Origine et buts
XML a ete developpe par un groupe de travail (GT) XML [XML Working Group] (initialement
connu sous le nom de comite d'examen editorial SGML [SGML Editorial Review Board])
constitue sous les auspices du Consortium du World Wide Web (W3C) en 1996. Le GT
etait preside par Jon Bosak de Sun Microsystems avec la participation active d'un
groupe d'interet XML [XML Special Interest Group] (auparavant connu sous le nom
de groupe de travail de SGML [SGML Working Group]) egalement organise par le W3C.
La liste des membres du groupe de travail XML est donnee en annexe. Dan Connolly
agissait comme contact du W3C aupres du GT.
Les objectifs de conception de XML sont les suivants :
XML devrait pouvoir etre utilise sans difficulte sur Internet ;
XML devrait soutenir une grande variete d'applications ;
XML devra etre compatible avec SGML ;
Il devrait etre facile d'ecrire des programmes traitant les documents XML ;
Le nombre d'options dans XML doit etre reduit au minimum, idealement a aucune ;
Les documents XML devraient etre lisibles par l'homme et raisonnablement clairs
;
La conception de XML devrait etre preparee rapidement ;
La conception de XML sera formelle et concise ;
Il devrait etre facile de creer des documents XML ;
La concision dans le balisage de XML est de peu d'importance.
Cette specification, ainsi que certaines normes associees (Unicode et l'ISO/CEI
10646 pour les caracteres, 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 necessaires pour
comprendre la version 1.0 de XML et pour construire des programmes pour la
traiter.
Cette version de la specification de XML peut etre distribuee librement, a
condition que tout le texte et les notices juridiques demeurent intacts.
1.2 Terminologie
La terminologie employee pour decrire les documents XML est definie dans cette
specification. Les termes definis dans la liste suivante sont utilises pour
etablir ces definitions et pour decrire les actions d'un processeur XML :
pouvoir (verbe)
il n'y a pas obligation pour les documents conformes et les processeurs XML de
se comporter tel que decrit.
devoir (verbe)
il y a obligation pour les documents conformes et les processeurs XML de se
comporter tel que decrit ; tout manquement est une erreur.
erreur
une violation des regles de cette specification. Les resultats sont indetermines.
Un logiciel conforme peut detecter et signaler une erreur et peut s'en remettre.
erreur fatale
une erreur qu'un processeur XML conforme doit detecter et signaler a l'application.
A la suite d'une erreur fatale, le processeur peut continuer a traiter les
donnees pour rechercher d'autres erreurs et peut signaler de telles erreurs a l'application.
Afin d'aider la correction des erreurs, le processeur peut rendre disponibles a
l'application des donnees non-traitees (melange de donnees textuelles et de
balisage). Des qu'une erreur fatale est detectee, toutefois, le processeur ne
doit pas continuer le traitement normal (c'est a dire qu'il ne doit pas
continuer a transmettre a l'application d'une facon normale les donnees
textuelles et l'information sur la structure logique du document).
au gre de l'utilisateur
un logiciel conforme peut ou doit (selon le verbe dans la phrase) se comporter
tel que decrit ; s'il le fait, il doit fournir a l'utilisateur un moyen d'activer
ou de desactiver le comportement decrit.
contrainte de validite
une regle qui s'applique a tous les documents XML valides. Les violations des
contraintes de validite sont des erreurs ; elles doivent, au gre de l'utilisateur,
etre signalees par les processeurs XML validateurs.
contrainte de forme
une regle qui s'applique a tous les documents XML bien formes. Les violations
des contraintes de forme sont des erreurs fatales.
correspondance
(De chaînes de caracteres ou de noms :) Deux chaînes de caracteres ou deux noms
correspondent s'ils sont identiques. Les caracteres possedant des
representations multiples dans l'ISO/CEI 10646 (c-a-d les caracteres avec des
formes precomposee et base+diacritiques) correspondent seulement s'ils ont la
meme representation dans les deux chaînes de caracteres. Au gre de l'utilisateur,
les processeurs peuvent normaliser de tels caracteres a une certaine forme
canonique. Aucune transformation de casse n'est effectuee. (De chaînes de
caracteres et de regles de grammaire :) toute chaîne appartenant au langage
engendre par une production grammaticale est reputee correspondre a cette
production. (Du contenu et des modeles de contenu :) un element correspond a sa
declaration quand il se conforme a la forme decrite dans la contrainte « element
valide ».
a des fins de compatibilite
un dispositif de XML uniquement inclus pour s'assurer que XML demeure compatible
avec SGML.
a des fins d'interoperabilite
une recommandation non-contraignante incluse pour accroître les chances de
traitement de document XML par des processeurs SGML anterieurs a l'annexe «
WebSGML Adaptations » de l'ISO 8879.
2. Documents
Un objet de donnees est un document XML s'il est bien forme, tel que precise
dans cette specification. De plus, un document XML bien forme peut etre valide s'il
obeit a certaines autres contraintes.
Chaque document XML a une structure logique et une structure physique.
Physiquement, le document se compose d'unites appelees entites. Une entite peut
appeler d'autres entites pour causer leur inclusion dans le document. Un
document commence a la « racine » ou entite document. Logiquement, le document
se compose de declarations, d'elements, de commentaires, d'appels de caractere
et d'instructions de traitement, qui sont indiques dans le document par du
balisage explicite. Les structures logiques et physiques doivent s'imbriquer
correctement, tel que decrit dans « 4.3.2 Entites analysables bien formees ».
2.1 Documents XML bien formes
Un objet textuel est un document XML bien forme si :
pris dans son ensemble, il correspond a la production etiquetee document ;
il obeit a toutes les contraintes de forme donnees dans cette specification ;
chacune des entites analysables generales qui est appelee directement ou
indirectement dans le document est bien formee.
Document
[1] document ::= prologue element Divers*
La correspondance a la production document implique que :
le document contient un ou plusieurs elements ;
il y a un seul element, appele la racine, ou l'element document, dont aucune
partie n'apparaît dans le contenu d'un autre element. Pour tous les autres
elements, si la balise de debut est dans le contenu d'un autre element, la
balise de fin est dans le contenu du meme element. Autrement dit, les elements,
delimites par des balises de depart et de fin, s'imbriquent correctement les uns
dans les autres.
En consequence, pour chaque element F (autre que la racine) dans le document, il
y a un autre element P dans le document tel que F est dans le contenu de P, mais
n'est dans le contenu d'aucun autre element qui est dans le contenu de P. P est
connu comme parent de F, et F comme fils de P.
2.2 Caracteres
Une entite analysable contient du texte, une suite de caracteres qui peuvent
representer du balisage ou des donnees textuelles. Un caractere est une unite de
texte tel que precise par l'ISO/CEI 10646 [ISO/CEI 10646]. Les caracteres
admissibles sont la tabulation, le retour de chariot, le retour a la ligne, et
les caracteres d'Unicode et de l'ISO/CEI 10646 permis par la production [2] ci-dessous.
L'utilisation des « caracteres de compatibilite », tel que definis dans la
section 6.8 de [Unicode], est deconseillee.
Ensemble de caracteres
[2] Car ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]
/* tout caractere Unicode, sauf les seizets d'indirection, FFFE et FFFF. */
Le mecanisme de codage des positions de code de caractere en configurations
binaires peut varier d'une entite a l'autre. Tous les processeurs XML doivent
accepter les codages UTF-8 et UTF-16 de l'ISO/CEI 10646 ; les mecanismes pour
signaler lequel des deux est utilise ou pour introduire d'autres codages sont
discutes ci-dessous dans « 4.3.3 Codage des caracteres dans les entites ».
2.3 Constructions syntaxiques communes
Ce paragraphe definit quelques symboles souvent utilises dans la grammaire.
S (separateurs, blanc) se compose d'un ou plusieurs des caracteres espace (#x20),
retour de chariot, retour a la ligne, ou tabulation.
Separateurs
[3] S ::= (#x20 | #x9 | #xD | #xA)+
Par commodite, les caracteres sont classifies en lettres, chiffres ou autres
caracteres. Une lettre est un caractere de base alphabetique ou syllabique ou
encore un caractere ideographique. Des definitions completes des classes de
caracteres sont donnees dans « B. Classes de caracteres ».
Un nom est une unite lexicale commencant par une lettre ou par un des caracteres
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
caracteres constitutifs de nom. Les noms commencant par la chaîne de caracteres
« xml », ou par n'importe quelle chaîne de caracteres correspondant a (('X'|'x')
('M'|'m') ('L'|'l')), sont reserves a des fins de normalisation dans cette
version ou dans des versions ulterieures de la specification.
Note : Le caractere deux points dans les noms XML est reserve pour l'experimentation
avec les espaces de nom. On s'attend a ce que sa signification soit normalisee
bientôt ; les documents utilisant les deux points dans un but experimental
pourront alors necessiter une mise a jour. (Il n'y a aucune garantie que le
mecanisme d'espace de nom eventuellement adopte pour XML utilise en fait les
deux points comme separateur.) Dans la pratique, ceci signifie que les auteurs
ne devraient pas utiliser les deux points dans les noms XML, sauf en tant qu'element
experimental d'espace de nom, mais que les processeurs XML devraient accepter
les deux points comme caractere constitutif de nom.
Un AtomeNml (atome nominal) est une suite de caracteres constitutifs de nom.
Noms et atomes nominaux
[4] CarNom ::= Lettre | Chiffre | '.' | '-' | '_' | ':' | CarJonctif |
ModificateurLettre
[5] Nom ::= (Lettre | '_' | ':') (CarNom)*
[6] Noms ::= Nom (#x20 Nom)*
[7] AtomeNml ::= (CarNom)+
[8] AtomesNmx ::= AtomeNml (#x20 AtomeNml)*
Une chaîne delimitee, ne contenant pas les guillemets (anglais, " ou ') utilises
comme delimiteur, constitue ce que l'on appelle « un litteral ». Des litteraux
sont utilises pour preciser le contenu des entites internes (ValeurEntite), des
valeurs des attributs (ValeurAtt) et des identificateurs externes (LitteralSysteme).
Notez qu'un LitteralSysteme peut etre analyse sans rechercher le balisage.
Litteraux
[9] ValeurEntite ::= '"' ([^%&"] | AppelEP | Appel)* '"'
|"'" ([^%&'] | AppelEP | Appel)* "'"
[10] ValeurAtt ::= '"' ([^<&"] | Appel)* '"'
|"'" ([^<&'] | Appel)* "'"
[11] LitteralSysteme ::= ('"' [^"]* '"') |("'" [^']* "'")
[12] IdPubLitteral ::= '"' CarIdPub* '"' | "'" (CarIdPub - "'")* "'"
[13] CarIdPub ::= #x20 | #xD | #xA | [a-zA-Z0-9] | [-'()+,./:=?;!*#@$_%]
2.4 Donnees textuelles et balisage
Le texte se compose de donnees textuelles et de balisage. Le balisage prend la
forme de balises ouvrantes, de balises fermantes, de balises d'elements vides, d'appels
d'entite, d'appels de caractere, de commentaires, de delimiteurs de section
CDATA, de declarations de type de document, et d'instructions de traitement.
Tout le texte qui n'est pas du balisage constitue les donnees textuelles du
document. Il est a noter que du texte correspondant au non-terminal S (production
[3]) est du balisage et non pas des donnees textuelles.
Les caracteres esperluete (&) et crochet gauche (<) peuvent apparaître sous leur
forme litterale seulement quand ils sont utilises comme delimiteurs de balisage
ou dans un commentaire, une instruction de traitement, ou une section CDATA. S'ils
sont necessaires ailleurs, ils doivent etre deguises en utilisant des appels de
caracteres numeriques ou en utilisant les chaînes de caracteres « & » et « <
» respectivement. Le crochet droit (>) peut etre represente en utilisant la
chaîne de caracteres « > » et doit, pour compatibilite, etre deguise en
utilisant « > » ou un appel de caractere quand il apparaît dans la chaîne de
caracteres « ]]> » dans du contenu, quand cette chaîne ne marque pas la fin d'une
section CDATA.
Dans le contenu des elements, toute chaîne de caracteres ne contenant pas un
delimiteur de debut de balisage est considere donnee textuelle. Dans une section
CDATA, toute chaîne de caracteres ne contenant pas le delimiteur de fin de
section CDATA, « ]]> », est considere donnee textuelle.
L'apostrophe (') peut etre representee par « ' », et le caractere guillemet
anglais (") par « " », afin de permettre a des valeurs d'attribut de
contenir ces caracteres.
Donnees textuelles
[14] DonneesTextuelles ::= [^<&]* - ([^<&]* ']]>' [^<&]*)
2.5 Commentaires
Les commentaires peuvent apparaître n'importe où dans un document en dehors d'autre
balisage ; de plus, ils peuvent apparaître dans la declaration de type de
document aux endroits permis par la grammaire. Ils ne font pas partie des
donnees textuelles du document ; un processeur XML peut permettre a une
application de recuperer le texte des commentaires. A des fins de compatibilite,
la chaîne « -- » (double trait d'union) ne doit pas apparaître a l'interieur de
commentaires.
Commentaires
[15] Commentaire ::= ''
Exemple de commentaire :
Il est a noter que la grammaire ne permet pas qu'un commentaire se termine par --->.
L'exemple suivant est mal forme :
2.6 Instructions de traitement
Les instructions de traitement (IT) permettent aux documents de contenir des
instructions pour des applications.
Instructions de traitement
[16] IT ::= '' CibleIT (S (Car* - (Car* '?>' Car*)))? '?>'
[17] CibleIT ::= Nom - (('X' | 'x') ('M' | 'm') ('L' | 'l'))
Les IT ne font pas partie des donnees textuelles des documents mais doivent etre
transmises a l'application. Une IT commence par une cible (CibleIT) qui
identifie l'application a laquelle l'instruction est destinee. Les noms de cible
« XML », « xml » et ainsi de suite sont reserves a des fins de standardisation
dans cette version ou des versions ulterieures de cette specification. Le
mecanisme de Notation de XML peut etre utilise pour la declaration formelle des
cibles d'IT.
2.7 Sections CDATA
Les sections CDATA peuvent se trouver a n'importe quel endroit acceptable pour
des donnees textuelles ; elles sont employees pour deguiser des blocs de texte
contenant des caracteres qui seraient autrement identifies comme balisage. Les
sections CDATA commencent par la chaîne « ».
Sections CDATA
[18] SectionDT ::= DebutDT DonneesT FinDT
[19] DebutDT ::= '' Car*))
[21] FinDT ::= ']]>'
Dans une section CDATA, seule la chaîne de caracteres FinDT est identifiee comme
balisage, de sorte que les crochets gauches et les esperluetes peuvent s'y
trouver litteralement ; ils n'ont pas besoin (et ne peuvent pas) etre deguises
en utilisant « < » et « & ». Les sections CDATA ne peuvent pas s'imbriquer.
Voici un exemple de section CDATA, dans lequel « » et « »
sont reconnus comme donnees textuelles, et non comme balisage :
Bonjour!]]>
2.8 Prologue et declaration de type de document
Les documents XML peuvent, et devraient, commencer par une declaration XML qui
indique la version de XML utilisee. L'exemple suivant est un document XML, bien
forme mais non valide :
Bonjour!
ainsi que celui-ci :
Bonjour!
Le numero de version « 1.0 » devrait etre employe pour indiquer la conformite a
cette version de la specification ; un document utilisant la valeur « 1.0 » mais
ne se conformant pas a cette version de la specification est en erreur. Le
Groupe de travail XML a l'intention de produire des versions ulterieures a la
version « 1.0 », mais cette intention ne signifie aucunement un engagement a
produire de futures versions de XML ni, si d'autres versions sont produites, a
utiliser un plan de numerotation 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 necessaire. Les processeurs
peuvent signaler une erreur s'ils recoivent des documents etiquetes avec des
versions qu'ils ne connaissent pas.
La fonction du balisage dans un document XML est de decrire sa structure de
stockage et sa structure logique et d'associer des paires attributs-valeurs a
ses structures logiques. XML fournit un mecanisme, la declaration de type de
document, pour definir des contraintes sur la structure logique et pour gerer l'utilisation
des unites de stockage predefinies.Un document XML est valide si une declaration
de type de document y est associee et si le document est conforme aux
contraintes qu'elle exprime.
La declaration de type de document doit apparaître avant le premier element dans
le document.
Prologue
[22] prologue ::= DeclXML? Divers* (declTypeDoc Divers*)?
[23] DeclXML ::= ''
[24] InfoVersion ::= S 'version' Egal ("'" NumVersion "'" | '"' NumVersion
'"')
[25] Egal ::= S? '=' S?
[26] NumVersion ::= ([a-zA-Z0-9_.:] | '-')+
[27] Divers ::= Commentaire | IT | S
La declaration de type de document XML contient ou designe des declarations de
balisage qui fournissent une grammaire pour une classe de documents. Cette
grammaire est connue comme declaration de type de document, ou DTD. La
declaration de type de document peut designer un sous-ensemble externe (un genre
special d'entites externes) contenant des declarations de balisage, peut
contenir des declarations de balisage directement dans un sous-ensemble interne
ou peut faire les deux. La DTD d'un document se compose des deux sous-ensembles
regroupes.
Une declaration de balisage est une declaration de type d'element, une
declaration de liste d'attributs, une declaration d'entites ou une declaration
de notation. Ces declarations peuvent etre contenues entierement ou
partiellement dans des entites parametres, tel que decrit ci-dessous dans les
contraintes de forme et de validite. Pour plus d'informations, voir « 4.
Structure physique ».
Definition de type de document
[28] declTypeDoc ::= '' [ CV : Type de l'element racine ]
[ CF : Sous-ensemble externe bien forme ]
[ CF : Entites parametre bien formees ]
[29] declBalisage ::= declElement | DeclListeAtt | DeclEntite | DeclNotation |
IT | Commentaire [ CV : Imbrication stricte des declarations et des EP ]
[ CF : EP dans le sous-ensemble interne ]
Les declarations de balisage peuvent se composer entierement ou partiellement du
texte de remplacement d'entites parametres. Les productions ulterieures dans
cette specification pour differents non-terminaux (declElement, DeclListeAtt, et
ainsi de suite) decrivent les declarations apres que toutes les entites
parametres aient ete developpees.
Contrainte de validite : Type de l'element racine
Le Nom dans la declaration de type de document doit correspondre au type d'element
de l'element racine.
Contrainte de forme : Sous-ensemble externe bien forme
Le sous-ensemble externe, s'il y a lieu, doit correspondre a la production [30]
sousEnsembleExt.
Contrainte de forme : Entites parametre bien formees
Une entite parametre appelee dans une declTypeDoc doit correspondre soit a la
production [30] sousEnsembleExt (si externe), soit a la production [31]
declSousEnsembleExt (si interne).
Contrainte de validite : Imbrication stricte des declarations et des EP
Le texte de remplacement des entites parametres doit etre correctement imbrique
dans les declarations de balisage. Si le premier ou le dernier caractere d'une
declaration de balisage (declBalisage ci-dessus) est contenu dans le texte de
remplacement d'un appel d'entite parametre, tous les deux doivent etre contenus
dans le meme texte de remplacement.
Contrainte de forme : EP dans le sous-ensemble interne
Dans le sous-ensemble interne de la DTD, les appels d'entite parametre peuvent
se produire seulement la où les declarations de balisage sont permises, pas a l'interieur
des declarations de balisage. (Ceci ne s'applique pas aux appels qui se
produisent dans les entites parametres externes ou au sous-ensemble externe.)
Tout comme le sous-ensemble interne, le sous-ensemble externe et les entites
parametres externes mentionnes dans la DTD doivent se composer d'une serie de
declarations de balisage completes des types permis par le symbole non-terminal
declBalisage, parsemees d'espaces ou d'appels d'entite parametre. Cependant, des
parties du contenu du sous-ensemble externe ou des entites parametres externes
peuvent conditionnellement etre ignorees en utilisant le mecanisme de section
conditionnelle ; ceci n'est pas permis dans le sous-ensemble interne. Le sous-ensemble
externe et toute entite parametre externe mentionnee dans la DTD doivent
correspondre a la production entParExt. Cf. la section 4.3.2 Entites analysables
bien formees.
Sous-ensemble externe
[30] sousEnsembleExt ::= DeclTexte? declSousEnsembleExt
[31] declSousEnsembleExt ::= ( declBalisage | sectConditionnelle | AppelEP | S
)*
Le sous-ensemble externe et les entites parametres externes different egalement
du sous-ensemble interne, les appels d'entite parametre y etant autorises a l'interieur
des declarations de balisage, et non seulement entre les declarations de
balisage.
Exemple de document XML avec une declaration de type de document :
Bonjour!
L'identificateur de systeme « bonjour.dtd » donne l'URI d'une DTD pour le
document.
Les declarations peuvent egalement etre donnees localement, comme dans l'exemple
suivant :
]>
Bonjour!
Si les sous-ensembles externes et internes sont utilises, le sous-ensemble
interne est considere comme se produisant avant le sous-ensemble externe. Ceci a
pour effet que les declarations d'entites et de liste d'attributs du sous-ensemble
interne ont priorite sur celles du sous-ensemble externe.
2.9 Declaration de document autonome
Les declarations de balisage peuvent affecter le contenu du document, tel qu'il
est transmis d'un processeur XML a une application ; des exemples sont des
valeurs d'attribut implicites et des declarations d'entite. La declaration de
document autonome, qui peut apparaître comme composante de la declaration de XML,
precise s'il y a de telles declarations externes a l'entite document..
Declaration de document autonome
[32] DeclDocAuto ::= S 'standalone' Egal (("'" ('yes' | 'no') "'") | ('"' ('yes'
| 'no') '"')) [ CV : declaration de document autonome ]
Dans une declaration de document autonome, la valeur « yes » indique qu'il n'y a
pas de declarations de balisage externes a l'entite document (dans le sous-ensemble
externe de DTD, ou dans une entite parametre externe appelee dans le sous-ensemble
interne) qui affecterait l'information transmise du processeur XML a l'application.
La valeur « no » indique qu'il y a ou peut y avoir de telles declarations de
balisage externes. Notez que la declaration de document autonome precise
seulement la presence de declarations externes ; la presence, dans un document,
d'appels a des entites externes ne change pas son caractere d'autonomie, quand
ces entites sont declarees dans le sous-ensemble interne.
S'il n'y a aucune declaration de balisage externe, la declaration de document
autonome n'a aucune signification. S'il y a des declarations de balisage
externes mais pas de declaration de document autonome, la valeur « no » est
presumee.
Tout document XML non-autonome (standalone="no") peut etre converti
algorithmiquement en document autonome, ce qui peut etre souhaitable pour des
applications diffusees en reseau.
Contrainte de validite : declaration de document autonome
La declaration de document autonome doit avoir la valeur « no » si des
declarations de balisage externes contiennent les declarations suivantes :
d'attributs avec des valeurs implicites, si les element auxquels s'appliquent
ces attributs apparaissent dans le document sans specification de valeur pour
ces attributs, ou
d'entites (autres que amp, lt, gt, apos et quot), si des appels a ces entites
apparaissent dans le document, ou
des attributs avec des valeurs sujettes a normalisation, où l'attribut apparaît
dans le document avec une valeur qui va changer en raison de la normalisation,
ou
des types d'element avec contenu elementaire pur, si du blanc apparaît
directement dans toute instance de ce type.
Exemple de declaration XML avec une declaration de document autonome :
2.10 Traitement du blanc
En editant des documents XML, il est souvent commode d'employer « du blanc » (des
espaces, tabulations et interlignes) pour distinguer le balisage pour une plus
grande lisibilite. Du tel blanc n'est pas typiquement destine a etre inclus dans
la version livree du document. D'autre part, le blanc « significatif » qui
devrait etre preserve dans la version livree est courant, par exemple en poesie
et en code source.
Un processeur XML doit toujours transmettre a l'application tous les caracteres
d'un document qui ne sont pas du balisage. Un processeur XML validateur doit
egalement informer l'application desquels de ces caracteres constituent le blanc
apparaissant dans du contenu elementaire pur.
Un attribut special nomme xml:space peut etre associe a un element pour signaler
l'intention que dans cet element, le blanc soit preserve par les applications.
Dans les documents valides, cet attribut, comme tout autre, doit etre declare s'il
est utilise. Si declare, il doit etre donne comme type enumere dont les seules
valeurs possibles sont « default » et « preserve ». Par exemple :
La valeur « default » indique que les modes implicites de traitement du blanc
sont acceptables pour cet element ; la valeur « preserve » demande que les
applications preservent tout le blanc. Cette intention declaree s'applique a
tous les elements a l'interieur du contenu de l'element porteur de la
declaration, a moins qu'elle ne soit annulee par une autre apparition de l'attribut
de xml:space.
L'element racine de n'importe quel document est considere comme n'avoir indique
aucune intention en ce qui concerne le traitement du blanc, a moins qu'il ne
fournisse une valeur pour cet attribut ou que l'attribut ne soit declare avec
une valeur implicite.
2.11 Traitement des fins de ligne
Des entites XML analysables sont souvent enregistrees dans des fichiers qui,
pour la commodite d'edition, sont organises en lignes. Ces lignes sont
typiquement separees par une combinaison du caractere retour chariot (#xD) et
retour a la ligne (#xA).
Pour simplifier la tâche des applications, quand une entite externe analysable
ou une valeur litterale d'entite d'une entite analysable interne contient soit
la sequence de deux caracteres litteraux « #xD#xA » soit un litteral #xD, un
processeur XML doit transmettre a l'application le seul caractere #xA. (Ce
comportement peut simplement etre produit en normalisant toutes les bris de
ligne a #xA a l'entree, avant l'analyse.)
2.12 Identification de langue
Dans le traitement de document, il est souvent utile d'identifier la langue
naturelle ou formelle dans laquelle le contenu est ecrit. Un attribut nomme xml:lang
peut etre insere dans les documents pour indiquer la langue utilisee dans le
contenu et dans les valeurs d'attributs de tout element d'un document XML. Dans
les documents valides, cet attribut, comme tout autre, doit etre declare s'il
est utilise. Les valeurs de l'attribut sont des identificateurs de langue tels
que definis par [IETF RFC 1766], « Balises pour l'identification des langues » :
Identification de Langue
[33] IdLang ::= CodeLang ('-' SousCode)*
[34] CodeLang ::= CodeISO639 | CodeIana | CodeUtil
[35] CodeISO639 ::= ([a-z] | [A-Z]) ([a-z] | [A-Z])
[36] CodeIana ::= ('i' | 'I') '-' ([a-z] | [A-Z])+
[37] CodeUtil ::= ('x' | 'X') '-' ([a-z] | [A-Z])+
[38] SousCode ::= ([a-z] | [A-Z])+
Les paragraphes qui suivent constituent un resume non-normatif de la definition
des codes de langue de [IETF RFC 1766].
Le CodeLang peut etre :
un code de langue a deux lettres defini par [ISO 639], « Codes pour la
representation des noms des langues » ;
un code de langue inscrit a l'Internet Assigned Numbers Authority [IANA-LANGCODES]
; ceux-ci commencent par le prefixe « i- » (ou « I- ») ;
un code de langue choisi par l'utilisateur ou ayant fait l'objet d'un accord
entre toutes les parties pour une utilisation privee ; ceux-ci doivent commencer
par le prefixe « x- » ou « X- » afin de s'assurer qu'ils ne sont pas en conflit
avec des noms normalises ulterieurement ou inscrits a 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 forme de deux lettres, il doit etre
un code de pays de [ISO 3166], « Codes pour la representation des noms des pays.
» Si le premier sous-code se compose de plus de deux lettres, ce doit etre un
code inscrit a l'IANA pour la langue en question, a moins que le CodeLang ne
commence par le prefixe « 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, a la difference d'autres noms
dans les documents XML, ne sont pas sensibles a la casse.
Exemples :
Cachez ce sein que je ne saurais voir.
Ce programme a une bogue.
Ce programme a un bogue.
Habe nun, ach! Philosophie,
Juristerei, und Medizin
und leider auch Theologie
durchaus studiert mit heißem Bemüh'n.
L'intention declaree avec xml:lang est consideree s'appliquer a tous les
attributs et au contenu de l'element où on l'indique, a moins qu'elle ne soit
annulee par une apparition de xml:lang sur un autre element dans ce contenu.
Une declaration simple pour xml:lang pourrait prendre la forme
xml:lang NMTOKEN #IMPLIED
mais des valeurs implicites specifiques peuvent egalement etre attribuees, si
appropriees. Dans une collection de poesie francaise pour etudiants anglais,
avec des gloses et des notes en anglais, l'attribut xml:lang pourrait etre
declare de cette facon :
3. Structures logiques
Chaque document XML contient un ou plusieurs elements, dont les limites sont
marquees soit par des balises ouvrantes et fermantes, soit, pour les elements
vides, par une balise d'element vide. Chaque element a un type, identifie par un
nom, parfois appele son « identificateur generique » (IG), on peut y associer un
jeu de specifications d'attribut. Chaque specification d'attribut comprend un
nom et une valeur.
Element
[39] element ::= BaliseElemVide
| BaliseO contenu BaliseF [ CF : Correspondance de type d'element ]
[ CV : Element valide ]
Cette specification ne contraint pas la semantique, l'utilisation ou (au-dela de
la syntaxe) les noms des types d'elements ou d'attributs, hormis le fait que les
noms qui commencent par (('X'|'x')('M'|'m')('L'|'l')) sont reserves a des fins
de standardisation dans cette version ou d'ulterieures versions de cette
specification.
Contrainte de forme : Correspondance de type d'element
Le Nom dans une balise fermante d'un element doit correspondre au type d'element
de la balise ouvrante.
Contrainte de validite : Element valide
Un element est valide s'il existe une declaration correspondant a declElement où
le nom correspond a un type d'element, et l'une des conditions suivantes est
vraie :
La declaration correspond a EMPTY et l'element n'a pas de contenu.
La declaration correspond a sousElements et la suite de sous-elements appartient
au langage engendre par l'expression reguliere du modele de contenu, avec du
blanc optionnel (des caracteres correspondant au non-terminal S) entre la balise
ouvrante et le premier sous-element, entre les sous-elements ou entre le dernier
sous-elements et la balise fermante. Il est a noter qu'une section CDATA ne
contenant que du blanc ne correspond pas au non-terminal S et par consequent ne
peut apparaître en ces positions.
La declaration correspond a Mixte et le contenu est constitue de donnees
textuelles et de sous-elements dont les types correspondent aux noms dans le
modele du contenu.
La declaration correspond a ANY et le type de chaque sous-element a ete declare.
3.1 Balises ouvrantes, balises fermantes et balises d'element vide
Le debut de chaque element XML non vide est marque d'une balise ouvrante (ou
balise de debut).
Balise ouvrante
[40] BaliseO ::= '<' Nom (S Attribut)* S? '>' [ CF : Specif. unique de l'attribut
]
[41] Attribut ::= Nom Egal ValeurAtt [ CV : Type valeur de l'attribut ]
[ CF : Pas d'appel d'entite externe ]
[ CF : Pas de < dans les valeurs d'attribut ]
[ CV : xml:lang valide ]
Le Nom des balises de debut et de fin specifie le type de l'element. Les couples
Nom-ValeurAtt constituent les specifications d'attribut de l'element, avec pour
chaque couple le Nom designe par le nom de l'attribut, et le contenu de
ValeurAtt (le texte compris entre les delimiteurs « ' » ou « " ») designe par la
valeur de l'attribut. Il est a noter que l'ordre des specifications d'attribut
dans une balise ouvrante ou une balise d'element vide n'est pas significatif.
Contrainte de forme : Specification unique de l'attribut
Aucun nom d'attribut ne peut apparaître plus d'une fois dans la meme balise de
debut ou d'element vide.
Contrainte de validite : Type de valeur de l'attribut
L'attribut doit avoir ete declare; la valeur doit correspondre au type declare
pour cet attribut. (Pour les types d'attribut, voir « 3.3 Declarations des
listes d'attributs ».)
Contrainte de forme : Pas d'appel d'entite externe
Les valeurs d'attribut ne peuvent contenir d'appels d'entite directs ou
indirects a des entites externes.
Contrainte de forme : Pas de < dans les valeurs d'attribut
Le texte de remplacement de toute entite appelee directement ou indirectement
dans une valeur d'attribut (autre que « < ») ne peut contenir un <.
Contrainte de validite : xml:lang valide
Si le Nom dans une specification d'attribut est xml:lang, la valeur, apres
normalisation en tant que NMTOKEN, doit correspondre a la production [33].
Exemple de balise ouvrante:
La fin de chaque element qui commence par une balise de debut doit etre marque d'une
balise fermante (ou balise de fin) contenant un nom qui renvoie au type de l'element
specifie dans la balise de debut :
Balise fermante
[42] BaliseF ::= '' Nom S? '>'
Exemple de balise fermante :
On appelle le texte compris entre les balises de debut et de fin le contenu de l'element
:
Contenu des elements
[43] contenu ::= (element | DonneesTextuelles | Appel | SectionDT | IT |
Commentaire)*
Si un element est vide, il devrait etre indique soit par une balise ouvrante
suivie immediatement d'une balise fermante, soit par une balise d'element vide.
Une balise d'element vide se formule d'une maniere particuliere :
Balises pour elements vides
[44] BaliseElemVide ::= '<' Nom (S Attribut)* S? '/>' [ CF : Specif. unique
de l'attribut ]
Les balises d'element vide peuvent etre utilisees pour tout element qui n'a pas
de contenu, qu'il ait ete declare ou non avec le mot-cle EMPTY. A des fins d'interoperabilite,
il est souhaitable d'utiliser la balise d'element vide pour les elements qui ont
ete declares EMPTY et de ne pas l'utiliser ailleurs.
Exemples d'elements vides :
3.2 Declarations de type d'element
La structure des elements d'un document XML peut, a des fins de validation, etre
contrainte a l'aide de declarations de type d'element et de liste d'attributs.
La declaration de type d'un element contraint le contenu de cet element.
Les declarations de type d'un element limitent habituellement les types d'element
qui peuvent apparaître comme sous-elements de celui-ci. Au choix de l'utilisateur,
un processeur XML peut emettre un avertissement quand une declaration mentionne
un type d'element pour lequel aucune declaration n'a ete fournie, mais ceci ne
constitue pas une erreur.
Une declaration de type d'element se formule de la facon suivante :
Declaration de type d'element
[45] declElement ::= '' [ CV :
Declaration de type d'element unique ]
[46] specContenu ::= 'EMPTY' | 'ANY' | Mixte | sousElements
où le Nom fournit le type d'element que l'on declare.
Contrainte de validite : Declaration de type d'element unique
Aucun type d'element ne peut etre declare plus d'une fois.
Exemples de declarations de type d'element :
3.2.1 Contenu elementaire pur
Un type d'element a un contenu elementaire pur quand des elements de ce type ne
peuvent contenir que des sous-elements, (pas de donnees textuelles), separes par
du blanc (caracteres correspondant au non-terminal S) facultatif. Dans ce cas,
la contrainte comprend un modele de contenu, une grammaire simple regissant les
types admis pour les sous-elements et l'ordre dans lequel ceux-ci peuvent
apparaître. Cette grammaire est construite a l'aide de particules de contenu (pc),
constituees de noms, de listes de choix de particules de contenu, ou de listes
de suites de particules de contenu :
Modeles de contenu elementaire pur
[47] sousElements ::= (choix | seq) ('?' | '*' | '+')?
[48] pc ::= (Nom | choix | seq) ('?' | '*' | '+')?
[49] choix ::= '(' S? pc ( S? '|' S? pc )+ S? ')' [ CV : Imbrication stricte
des parentheses dans EP ]
[50] seq ::= '(' S? pc ( S? ',' S? pc )* S? ')' [ CV : Imbrication stricte
des parentheses dans EP ]
où chaque Nom est le type d'un element qui peut apparaître comme sous-element.
Une particule de contenu dans une liste de choix peut apparaître au sein d'un
contenu elementaire pur a l'endroit où une liste de choix apparaît dans la
grammaire; les particules de contenu presentes dans une liste de suite doivent
toutes apparaître dans le contenu elementaire pur dans l'ordre precise dans la
liste. Les caracteres optionnels qui suivent un nom ou une liste determinent si
l'element ou les particules de contenu dans la liste peuvent apparaître une fois
ou plus (+), zero fois ou plus (*), ou bien au maximum une fois(?). L'absence d'un
tel operateur signifie que l'element ou la particule de contenu doit apparaître
exactement une fois. Leur syntaxe et leur sens sont identiques a ceux qui sont
utilises dans les productions de cette specification.
Le contenu d'un element correspond a un modele de contenu si et seulement si l'on
peut tracer un chemin a travers le modele de contenu qui respecte les operateurs
de suite, de choix et de repetition et qui fait correspondre chaque element du
contenu a un type d'element defini dans le modele de contenu. A des fins de
compatibilite, le fait qu'un element dans le document puisse correspondre a plus
d'une occurrence de ce type d'element dans le modele de contenu constitue une
erreur. Pour de plus amples informations, voir « E. Modeles de contenu
deterministes ».
Contrainte de validite : Imbrication stricte des parentheses dans EP
Les parentheses des textes de remplacement d'une entite parametre doivent etre
strictement imbriques. Ceci signifie que si la parenthese ouvrante ou fermante d'une
production choix, seq ou Mixte se retrouve dans le texte de remplacement d'une
entite parametre, ces deux parentheses doivent etre contenues dans le meme texte
de remplacement. A des fins d'interoperabilite, si un appel d'entite parametre
apparaît dans une production choix, seq ou Mixte, son texte de remplacement doit
contenir au moins un caractere significatif (non blanc) ; de plus, ni le premier
ni le dernier caractere significatif (non blanc) du texte de remplacement ne
peuvent etre un connecteur (| ou ,).
Exemples de modeles de contenu elementaire pur :
3.2.2 Contenu mixte
Un type d'element a un contenu mixte quand des elements de ce type peuvent
contenir des donnees textuelles, parsemees, le cas echeant, de sous-elements.
Dans ce cas, les types des sous-elements peuvent etre contraints mais pas leur
ordre ni leur nombre.
Declaration de contenu mixte
[51] Mixte ::= '(' S? '#PCDATA' (S? '|' S? Nom)* S? ')*'
| '(' S? '#PCDATA' S? ')' [ CV : Imbrication stricte des parentheses dans EP ]
[ CV : Type unique ]
où les Noms fournissent les types des elements qui peuvent apparaître comme sous-elements.
L'etymologie du mot-cle PCDATA est l'anglais « parsed character data », c'est a
dire « donnees textuelles analysables ».
Contrainte de validite : Type unique
Le meme nom ne peut apparaître plus d'une fois dans une seule declaration de
contenu mixte.
Exemples de declarations de contenu mixte :
3.3 Declarations de liste d'attributs
On utilise des attributs pour associer des couples nom-valeur aux elements. Les
specifications d'attribut ne peuvent apparaître qu'au sein de balises ouvrantes
et de balises d'element vide ; ainsi, les productions utilisees pour les
reconnaître apparaissent dans « 3.1 Balises ouvrantes, balises fermantes et
balises d'element vide ». Les declarations de liste d'attributs peuvent servir a
:
definir un jeu d'attributs se rapportant a un type d'element donne;
etablir des contraintes de type pour ces attributs;
fournir des valeurs implicites pour des attributs.
Les declarations de liste d'attributs precisent le nom, le type de donnees et la
valeur implicite (le cas echeant) de chaque attribut associe a un type d'element
donne :
Declaration de liste d'attributs
[52] DeclListeAtt ::= ''
[53] DefAtt ::= S Nom S TypeAtt S DeclValImpl
Le Nom dans la production DeclListeAtt correspond au type d'un element. Au choix
de l'utilisateur, un processeur XML peut emettre un avertissement si on declare
des attributs pour un type d'element qui lui-meme n'est pas declare, mais ceci
ne constitue pas une erreur. Le Nom que l'on retrouve dans la regle DefAtt
correspond au nom de l'attribut.
Quand plus d'une DeclListeAtt existe pour un type d'element donne, le contenu de
toutes les declarations fournies est fusionnee. Quand plus d'une definition
existe pour un meme attribut d'un type d'element donne, seule la premiere
declaration compte, les declarations subsequentes sont ignorees. A des fins d'interoperabilite,
les redacteurs de DTD pourraient decider de fournir pas plus d'une declaration
de liste d'attributs pour un type d'element donne, pas plus d'une definition d'attribut
pour un nom d'attribut donne dans une declaration de liste d'attributs et au
moins une definition d'attribut dans chaque declaration de liste d'attributs. De
meme, a des fins d'interoperabilite, un processeur XML pourra au gre de l'utilisateur
emettre un avertissement quand il existe plus d'une declaration de liste d'attributs
pour un type d'element donne ou quand plus d'une definition d'attribut existe
pour un attribut donne, mais ceci ne constitue pas une erreur.
3.3.1 Types d'attribut
Les types d'attribut XML sont de trois genres: un type chaîne, une serie de
types atomiques et des types enumeres. Le type chaîne peut prendre comme valeur
toute chaîne litterale; les types atomiques subissent differentes contraintes
lexicales et semantiques precisees ci-dessous. Les contraintes de validite
indiquees dans la grammaire s'appliquent apres que la valeur d'attribut ait ete
normalisee de la facon precisee dans la section 3.3.3 Normalisation de valeur d'attribut.
Types d'attribut
[54] TypeAtt ::= TypeChaîne | TypeAtomique | TypeEnumere
[55] TypeChaîne ::= 'CDATA'
[56] TypeAtomique ::= 'ID' [ CV : ID ]
[ CV : Un seul ID par type d'element ]
[ CV : Valeur implicite de l'attribut ID ]
| 'IDREF' [ CV : IDREF ]
| 'IDREFS' [ CV : IDREF ]
| 'ENTITY' [ CV : Nom d'entite ]
| 'ENTITIES' [ CV : Nom d'entite ]
| 'NMTOKEN' [ CV : Atome nominal ]
| 'NMTOKENS' [ CV : Atome nominal ]
Contrainte de validite : ID
Les valeurs de type ID doivent correspondre a 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 elements qu'elles designent..
Contrainte de validite : Un seul ID par type d'element
Aucun type d'element ne peut posseder plus d'un attribut ID.
Contrainte de validite : Valeur implicite de l'attribut ID
Un attribut ID doit avoir comme valeur implicite declaree soit #IMPLIED soit #REQUIRED.
Contrainte de validite : IDREF
Les valeurs de type IDREF doivent correspondre a la production Nom, et les
valeurs de type IDREFS doivent correspondre a des Noms ; chaque Nom doit
correspondre a la valeur d'un attribut ID sur un element quelconque du document
XML, en d'autres mots les valeurs IDREF doivent correspondre a la valeur d'un
attribut ID.
Contrainte de validite : Nom d'entite
Les valeurs de type ENTITY doivent correspondre a la production Nom , les
valeurs de type ENTITIES doivent correspondre a des Noms ; chaque Nom doit
correspondre au nom d'une entitee non-analysable declaree dans la DTD.
Contrainte de validite : Atome nomimal
Les valeurs de type NMTOKEN doivent correspondre a la production AtomeNml ; les
valeurs de type NMTOKENS doivent correspondre a des AtomeNmx.
Les attributs enumeres peuvent prendre une valeur parmi une liste de valeurs
fournie dans la declaration. Il existe deux sortes de types enumeres :
Types d'attributs enumeres
[57] TypeEnumere ::= TypeNotation | Enumeration
[58] TypeNotation ::= 'NOTATION' S '(' S? Nom (S? '|' S? Nom)* S? ')' [ CV :
Attributs de notation ]
[ CV : Une seule notation par type d'element ]
[59] Enumeration ::= '(' S? AtomeNml (S? '|' S? AtomeNml)* S? ')' [ CV :
Enumeration ]
Un attribut NOTATION identifie une notation, declaree dans la DTD conjointement
avec ses identificateurs systemes et publics, que l'on utilisera pour
interpreter l'element auquel l'attribut est joint.
Contrainte de validite : Attributs de notation
Les valeurs de ce type doivent correspondre a un des noms de notation inclus
dans la declaration ; tous les noms de notation dans la declaration doivent etre
declares.
Contrainte de validite : Une seule notation par type d'element
Nul element ne peut avoir plus d'un attribut de type NOTATION.
Contrainte de validite : Enumeration
Les valeurs de ce type doivent correspondre a un des atomes AtomeNml dans la
declaration.
A des fins d'interoperabilite, le meme AtomeNml ne devrait pas apparaître plus d'une
fois dans les types d'attribut enumere d'un meme type d'element.
3.3.2 Valeurs implicites des attributs
Une declaration d'attribut precise si la presence de l'attribut est exigee et,
si elle ne l'est pas, precise le comportement du processeur XML quand l'attribut
declare est absent dans un document.
Valeurs implicites des attributs
[60] DeclValImpl ::= '#REQUIRED' | '#IMPLIED'
| (('#FIXED' S)? ValeurAtt) [ CV : Attribut obligatoire ]
[ CV : Valeur implicite de l'attribut permise ]
[ CF : Pas de < dans valeurs d'attribut ]
[ CV : Valeur implicite de l'attribut fixe ]
Dans une declaration d'attribut, #REQUIRED signifie que l'attribut doit toujours
etre fourni, #IMPLIED qu'aucune valeur implicite n'est fournie. Si la
declaration n'est ni #REQUIRED ni #IMPLIED alors la valeur de ValeurAtt precise
la valeur implicite declaree; le mot-cle #FIXED indique que l'attribut doit
toujours avoir la valeur implicite. Si une valeur implicite est declaree, le
processeur XML doit se comporter comme si l'attribut etait present et egal a la
valeur implicite declaree lorsqu'il s'apercoit de l'absence d'un attribut.
Contrainte de validite : Attribut obligatoire
Si la declaration implicite est le mot-cle #REQUIRED il faut alors preciser l'attribut
pour tous les elements du type dans la declaration de la liste d'attributs.
Contrainte de validite : Valeur implicite de l'attribut permise
La valeur implicite declaree doit satisfaire aux contraintes lexicales du type d'attribut
declare.
Contrainte de validite : Valeur implicite de l'attribut fixe
Si un attribut a une valeur implicite declaree avec le mot-cle #FIXED, les
instances de cet attribut doivent correspondre a la valeur implicite.
Exemples de declarations de liste d'attributs :
3.3.3 Normalisation de valeur d'attribut
Avant que la valeur d'un attribut ne soit passee a l'application ou que l'on
verifie sa validite, mais apres normalisation des fins de ligne selon la section
2.11 Traitement des fins de ligne, le processeur XML doit normaliser cette
valeur de la facon suivante :
on commence avec une chaîne vide comme valeur normalisee ;
pour chaque caractere, appel d'entite ou appel de caractere de la valeur d'attribut
non-normalisee, du debut a la fin, agir comme suit :
on traite un appel de caractere en ajoutant le caractere appele a la fin de la
valeur normalisee ;
on traite un appel d'entite en traitant recursivement le texte de remplacement
de l'entite ;
on traite une suite « #xD#xA » faisant partie d'une entite analysable externe ou
de la valeur litterale d'entite d'une entite analysable interne en ajoutant une
espace (#x20) a la fin de la valeur normalisee ;
on traite un separateur (#x20, #xD, #xA, #x9) en ajoutant une espace (#x20) a la
fin de la valeur normalisee ;
on traite les autres caracteres en les ajoutant a la fin de la valeur normalisee.
Si la valeur declaree n'est pas CDATA alors le processeur XML devra poursuivre
le traitement de la valeur normalisee de l'attribut en se defaisant des espaces
(#x20) de tete et de queue et en replacant les suites d'espaces (#x20) par un
seul caractere espace (#x20).
On notera que si la valeur d'attribut avant normalisation contient un appel de
caractere a un separateur autre que l'espace (#x20), la valeur normalisee
contient le separateur lui-meme (#xD, #xA ou #x9). Ce cas differe du cas où la
valeur avant normalisation contient un separateur (et non un appel), qui est
remplace par un caractere espace (#x20) dans la valeur normalisee et differe
aussi du cas où la valeur avant normalisation contient un appel d'entite dont le
texte de remplacement contient un separateur ; a cause du traitement recursif,
ce separateur est remplace par un caractere espace dans la valeur normalisee.
Tous les attributs pour lesquels on n'a lu aucune declaration devraient etre
consideres par un processeur non-validateur comme si on les avait declares au
moyen de CDATA.
3.4 Sections conditionnelles
Les sections conditionnelles sont des portions du sous-ensemble externe de la
declaration de type de document qui, selon la valeur d'un mot-cle, sont incluses
dans la structure logique de la DTD ou excluses de celles-ci.
Section conditionnelle
[61] sectConditionnelle ::= sectInclude | sectIgnore
[62] sectInclude ::= ''
[63] sectIgnore ::= ''
[64] contenuSectIgnore ::= Ignore ('' Ignore)*
[65] Ignore ::= Car* - (Car* ('') Car*)
A l'instar des sous-ensembles internes et externes de DTD, une section
conditionnelle peut contenir une ou plusieurs instances completes de
declarations, de commentaires, d'instructions de traitement ou de sections
conditionnelles imbriquees, le tout parseme de separateurs (du blanc).
Si le mot-cle d'une section conditionnelle est INCLUDE alors le contenu de la
section conditionnelle fait partie de la DTD. Si le mot-cle 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 meme ignorees afin
de detecter les sections conditionnelles imbriquees et de s'assurer que la fin
de la section conditionnelle (ignoree) la plus englobante est correctement
decelee. Si une section conditionnelle marquee du mot-cle INCLUDE se trouve au
sein d'une section conditionnelle plus importante qui elle est marque d'un mot-cle
IGNORE, les sections interieure et exterieure sont toutes deux ignorees.
Si le mot-cle d'une section conditionnelle est un appel d'entite parametre, on
remplacera l'entite parametre par son contenu avant que le processeur ne decide
s'il doit inclure ou ignorer la section conditionnelle.
Exemple :
]]>
]]>
4. Structures physiques
Un document XML peut etre constitue d'une ou plusieurs unites de stockage. Ces
unites sont appelees entites ; chacune a un contenu et toutes (a l'exception de
l'entite document et du sous-ensemble externe de la DTD) sont identifiees par un
nom d'entite. Chaque document XML possede une entite appelee entite document qui
sert de point de depart pour le processeur XML et qui peut contenir le document
au complet.
Une entite peut etre analysable ou non. On designe le contenu d'une entite
analysable sous le nom de texte de remplacement ; ce texte fait partie
integrante du document.
Une entite non-analysable est une ressource dont le contenu n'est pas
necessairement textuel (et pas necessairement du texte XML meme si textuel). On
associe a chaque entite non-analysable une notation, identifiee par un nom. XML
n'impose aucune contrainte au contenu des entites non-analysables, si ce n'est
que les noms des entites et des notations soient mis a la disposition de l'application.
Les entites analysables sont appelees par leur nom au moyen d'un appel d'entite
; le nom des entites non-analysables est fourni par la valeur d'un attribut de
type ENTITY ou ENTITIES.
Les entites generales sont destinees a etre utilisees dans le contenu du
document. Les entites parametres sont des entites analysables destinees a etre
utilisees dans la DTD. Les appels a ces deux types d'entites sont differents et
sont reconnus dans des contextes differents. De plus, les deux types occupent
des espaces de noms distincts ; une entite parametre et une entite generale de
meme nom sont deux entites distinctes. Dans ce texte, les entites generales sont
parfois appelees simplement entites quand il n'y a pas de risque d'ambiguïte.
4.1 Appels de caractere et d'entite
Un appel de caractere fait reference a un caractere particulier du jeu de
caracteres ISO/CEI 10646, par exemple un caractere inaccessible par le biais du
clavier.
Appel de caractere
[66] AppelCar ::= '' [0-9]+ ';'
| '' [0-9a-fA-F]+ ';' [ CF : Caractere admissible ]
Contrainte de forme : Caractere admissible
Le caractere faisant l'objet d'un appel de caractere doit respecter la
production Car.
Si un appel de caractere commence par « », les chiffres et lettres jusqu'au
terminateur « ; » constituent une representation hexadecimale de la position de
code du caractere dans l'ISO/CEI 10646. S'il commence seulement par « », les
chiffres jusqu'au terminateur « ; » constituent une representation decimale de
cette position de code.
Un appel d'entite fait reference au contenu d'une entite nommee. Les appels a
des entites generales analysables utilisent l'esperluette (&) et le point-virgule
(;) comme delimiteurs. Les appels d'entites parametres utilisent le symbole pour
cent (%) et le point-virgule (;) comme delimiteurs.
Appel d'entite
[67] Appel ::= AppelEntite | AppelCar
[68] AppelEntite ::= '&' Nom ';' [ CF : Entite declaree ]
[ CV : Entite declaree ]
[ CF : Entite analysable ]
[ CF : Pas de recursion ]
[69] AppelEP ::= '%' Nom ';' [ CV : Entite declaree ]
[ CF : Pas de recursion ]
[ CF : Dans la DTD ]
Contrainte de forme : Entite declaree
Dans un document sans DTD, un document avec seulement un sous-ensemble interne
de DTD sans appel d'entite parametre ou un document marque « standalone='yes' »,
le Nom donne dans un appel d'entite apparaissant ailleurs que dans le sous-ensemble
externe ou dans une entite parametre doit correspondre au nom d'une declaration
d'entite apparaissant ailleurs que dans le sous-ensemble externe ou dans une
entite parametre. Toutefois, dans les documents bien formes, les entites
suivantes n'ont pas a etre declarees : amp, lt, gt, apos, quot. La declaration d'une
entite generale doit preceder tout appel a celle-ci apparaissant dans une valeur
implicite dans une declaration de liste d'attributs. Note : si des entites sont
declarees dans le sous-ensemble externe de DTD ou dans des entites parametres
externes, un processeur non-validateur n'est pas oblige de lire et de traiter
leurs declarations ; pour de tels documents, la regle voulant qu'une entite soit
declaree n'est une contrainte de forme que si standalone='yes'.
Contrainte de validite : Entite declaree
Dans un document avec sous-ensemble externe de DTD ou des entites parametres
externes avec « standalone='no' », le Nom donne dans l'appel doit correspondre
au nom d'une declaration d'entite. A des fins d'interoperabilite, les documents
valides devraient declarer les entites amp, lt, gt, apos, quot, sous la forme
precisee en « 4.6 Entites predefinies ». La declaration d'une entite parametre
doit preceder tout appel a celle-ci. De meme, la declaration d'une entite
generale doit preceder tout appel a celle-ci apparaissant dans une valeur
implicite dans une declaration de liste d'attributs.
Contrainte de forme : Entite analysable
Un appel d'entite ne doit pas contenir le nom d'une entite non-analysable. On ne
peut faire reference a des entites non-analysables que par le biais de valeurs d'attribut
declarees de type ENTITY ou ENTITIES.
Contrainte de forme : Pas de recursion
Une entite analysable ne doit pas contenir d'appel recursif a elle-meme,
directement ou indirectement.
Contrainte de forme : Dans la DTD
Les appels d'entite parametre ne peuvent se trouver que dans la DTD.
Exemples d'appels de caractere et d'entite :
Tapez plus-petit-que (<) pour sauvegarder les options.
Ce document a ete redige le &datedoc; et
est classe &niveau-de-securite;.
Exemple d'appel d'entite parametre :
%ISOLat2;
4.2 Declarations d'entites
On declare des entites de la facon suivante :
Declaration d'entite
[70] DeclEntite ::= DeclEG | DeclEP
[71] DeclEG ::= ''
[72] DeclEP ::= ''
[73] DefEntite ::= ValeurEntite | (IdExterne DeclNdata?)
[74] DefEP ::= ValeurEntite | IdExterne
Le Nom identifie l'entite dans un appel d'entite ou, dans le cas d'une entite
non-analysable, dans la valeur d'un attribut de type ENTITY ou ENTITIES. Si une
meme entite est declaree plus d'une fois, seule la premiere declaration compte ;
un processeur XML peut alors emettre, au gre de l'utilisateur, un avertissement
de declarations multiples.
4.2.1 Entites internes
Si la definition de l'entite est une ValeurEntite, l'entite ainsi definie est
appelee entite interne. Il n'y a pas d'objet stocke separement et le contenu de
l'entite est precise dans la declaration. Remarquons que la production du texte
de remplacement peut necessiter le traitement d'appels de caractere et d'entite
dans la valeur litterale d'entite : cf. « 4.5 Construction du texte de
remplacement d'une entite interne ».
Une entite interne est une entite analysable.
Exemple de declaration d'entite interne :
4.2.2 Entites externes
Si l'entite n'est pas interne, il s'agit d'une entite externe, declaree comme
suit :
Declaration d'entite externe
[75] IdExterne ::= 'SYSTEM' S LitteralSysteme
| 'PUBLIC' S IdPubLitteral S LitteralSysteme
[76] DeclNdata ::= S 'NDATA' S Nom [ CV : Notation declaree ]
Si la production DeclNdata est presente, il s'agit d'une entite non-analysable
generale ; autrement il s'agit d'une entite analysable.
Contrainte de validite : Notation declaree
Le Nom doit correspondre au nom d'une notation declaree.
La production LitteralSysteme est appelee identificateur systeme de l'entite. Il
s'agit d'un URI, destine a etre utilise pour recuperer des donnees que le
processeur XML utilisera pour construire le texte de remplacement de l'entite.
Il est a noter que le croisillon (#) et l'identificateur de fragment, qui sont
frequemment utilises avec des URI, ne font pas formellement partie de l'URI. Un
processeur XML peut signaler une erreur si un identificateur de systeme contient
un identificateur de fragment. Les URI relatifs doivent etre interpretes par
rapport a l'emplacement de la ressource au sein de laquelle la declaration d'entite
se trouve, sauf en cas d'information de provenance externe et qui ne releve pas
de ce standard, comme un element XML special defini dans une DTD particuliere ou
une instruction de traitement definie par une application particuliere. Un URI
peut donc etre relatif a l'entite document, a l'entite contenant le sous-ensemble
externe de DTD ou a une quelconque entite parametre externe.
Certains URI peuvent contenir des caracteres qui sont soit reserves (cf. [IETF
RFC2396], section 2.2) soit hors du domaine ASCII. Un processeur XML devrait
traiter un tel caractere dans un URI en le representant sous forme d'un ou
plusieurs octets en UTF-8, puis en transformant chacun de ces octets selon le
mecanisme de transformation URI (c'est a dire en convertissant chaque octet en %HH,
où HH est la notation hexadecimale de la valeur de l'octet).
En plus d'un identificateur systeme, un identificateur externe peut contenir un
identificateur public. Un processeur XML qui essaie de recuperer le contenu d'une
entite peut utiliser l'identificateur public pour en tirer un URI de
remplacement. Si le processeur en est incapable, il doit utiliser l'URI precise
par l'identificateur systeme. L'identificateur public doit etre normalise en
transformant toute suite de separateurs (du blanc) en un seul caractere espace (#x20)
et en eliminant tout blanc de tete et de queue.
Exemples de declaration d'entite externe :
4.3 Entites analysables
4.3.1 La declaration de texte
Les entites analysables externes peuvent commencer par une declaration de texte.
Declaration de texte
[77] DeclTexte ::= ''
La declaration de texte doit etre fournie litteralement et non pas par appel d'une
entite analysable. Elle ne peut se trouver qu'au debut d'une entite analysable
externe.
4.3.2 Entites analysables bien formees
On dit d'une entite document qu'elle est bien formee si elle correspond a la
production document. Une entite generale analysable externe est bien formee si
elle correspond a la production entAnalExt. Une entite parametre externe est
bien formee si elle correspond a la production entParExt.
Entite analysable externe bien formee
[78] entAnalExt ::= DeclTexte? contenu
[79] entParExt ::= DeclTexte? declSousEnsembleExt
Une entite generale analysable interne est bien formee si son texte de
remplacement correspond a la production contenu. Toute entite parametre interne
est bien formee par definition.
Il decoule du caractere bien forme des entites que les structures logique et
physique d'un document XML s'imbriquent proprement ; aucun element, commentaire,
balise ouvrante, balise fermante, balise d'element vide, instruction de
traitement, appel de caractere ou appel d'entite ne peut commencer dans une
entite et se terminer dans une autre.
4.3.3 Codage des caracteres dans les entites
Chaque entite analysable externe d'un document XML peut utiliser un codage
different pour ses caracteres. Tous les processeurs XML doivent etre a meme de
lire les entites en UTF-8 et en UTF-16.
Les entites codees en UTF-16 doivent commencer par une marque d'ordre d'octets
telle que decrite par l'annexe F de l'ISO/CEI 10646 ou par la section 2.4 d'Unicode
(le caractere ESPACE INSECABLE SANS CHASSE, #xFEFF). La marque est une signature
de codage et ne fait partie ni du balisage ni des donnees textuelles du document
XML. Les processeurs XML doivent etre capables d'utiliser ce caractere pour
distinguer les documents codes en UTF-8 et en UTF-16.
Bien que seul le soutien des codages UTF-8 et UTF-16 ne soit requis des
processeurs XML, il est clair que d'autres codages sont couramment utilises et
qu'il peut etre souhaitable que les processeurs XML puissent lire les entites
qui les emploient. En absence d'information de codage de caracteres externe (comme
des en-tetes MIME), les entites analysables stockees dans un codage autre qu'UTF-8
ou UTF-16 doivent commencer par une declaration de texte contenant une
declaration de codage :
Declaration de codage
[80] DeclCodage ::= S 'encoding' Egal ('"' NomCodage '"' | "'" NomCodage "'" )
[81] NomCodage ::= [A-Za-z] ([A-Za-z0-9._] | '-')* /* Nom de codage ne
contenant que des caracteres latins */
Dans l'entite document, la declaration de codage se trouve dans la declaration
XML. NomCodage est le nom du codage utilise.
Dans une declaration de codage, les valeurs « UTF-8 », « UTF-16 », « ISO-10646-UCS-2
» et « ISO-10646-UCS-4 » devraient etre utilisees pour les divers codages et
transformation d'Unicode / ISO/CEI 10646, les valeurs « ISO-8859-1 », « ISO-8859-2
», ... « ISO-8859-9 » pour les parties de l'ISO 8859 et les valeurs « ISO-2022-JP
», « Shift_JIS » et « EUC-JP » pour les diverses formes de codage de JIS X-0208-1997.
Il est recommande d'utiliser, pour les codages de caracteres repertories (comme
charset) par l'Internet Assigned Numbers Authority [IANA-CHARSETS] autres que
ceux ci-dessus, les noms du repertoire de l'IANA; les autres codages devraient
etre designes par des noms commencant par un prefixe « x- ». Les processeurs XML
doivent evaluer les correspondances de noms de codages sans egard a la casse et
doivent interpreter un nom de codage repertorie par l'IANA soit comme le codage
correspondant a ce nom dans le registre de l'IANA, soit comme inconnu (les
processeurs ne sont bien sûr pas tenu de reconnaître tous les codages
repertories par l'IANA).
En l'absence d'information donnee par un protocole de transport externe (p. ex.
HTTP ou MIME), une entite comportant une declaration de codage mais codee
autrement est une erreur, de meme qu'une entite codee autrement qu'en UTF-8 qui
ne commence pas par une marque d'ordre d'octets ni ne contient une declaration
de codage. L'ASCII etant un sous-ensemble d'UTF-8, les entites codees en ASCII n'ont
pas absolument besoin de declaration de codage.
Une DeclTexte se trouvant ailleurs qu'au debut d'une entite externe est une
erreur fatale.
Une erreur fatale doit etre signalee quand un processeur XML se trouve en
presence d'une entite utilisant un codage que le processeur est incapable de
traiter. A noter le cas d'erreur subtil suivant : lorsqu'un caractere represente
par une paire de seizets d'indirection (Unicode #xD800 a #xDFFF) est presente a
un transcodeur ne connaissant pas UTF-16, il est possible que ce dernier
produisent une suite UTF-8 de 6 octets (3 pour chaque seizet d'indirection).
Lorsque decodee, une telle suite donnera 2 « caracteres » entre #xD800 et #xDFFF
; ce domaine etant exclu par la production [2], il s'agit d'une erreur fatale.
Exemples de declarations de texte contenant une declaration de codage :
4.4 Traitement des entites et des appels par un processeur XML
Le tableau ci-dessous resume dans quels contextes les appels de caractere, les
appels d'entite et les references a des entites non-analysables peuvent se
produire ainsi que le comportement exige d'un processeur XML dans chaque cas.
Les etiquettes de la colonne de gauche indiquent le contexte :
Appel dans le contenu
Un appel n'importe où entre la balise ouvrante et la balise fermante d'un
element ; correspond au non-terminal contenu.
Appel dans une valeur d'attribut
Un appel soit dans la valeur d'un attribut dans une balise ouvrante, soit dans
une valeur implicite dans une declaration d'attribut ; correspond au non-terminal
ValeurAtt.
Valeur d'attribut
Un Nom, et non pas un appel, apparaissant soit comme valeur d'un attribut
declare de type ENTITY, soit comme un des membres (delimites par des espaces) de
la valeur d'un attribut declare de type ENTITIES.
Appel dans une valeur d'entite
Un appel dans la valeur litterale d'entite d'une entite parametre ou interne
dans la declaration d'entite ; correspond au non-terminal ValeurEntite.
Appel dans la DTD
Un appel dans le sous-ensemble interne ou externe de la DTD, mais ailleurs que
dans une ValeurEntite, une ValeurAtt, une IT, un Commentaire, un LitteralSysteme
ou un IdPubLitteral.
Type d'entite Caractere
parametre interne
generale externe analysable
generale non-analysable
Appel dans
le contenu Non reconnu Inclus Inclus si validation Interdit Inclus
Appel dans une
valeur d'attribut Non reconnu Inclus dans litteral Interdit Interdit Inclus
Valeur d'attribut Non reconnu Interdit Interdit Signale Non reconnu
Appel dans une
valeur d'entite Inclus dans litteral Non interprete Non interprete Interdit
Inclus
Appel dans la DTD Inclus comme EP Interdit Interdit Interdit Interdit
4.4.1 Non reconnu
Hors de la DTD, le caractere % n'a aucune signification particuliere ; pour
cette raison, ce qui serait un appel d'entite parametre dans la DTD n'est pas
reconnu comme balisage dans le contenu. De meme, les noms des entites non-analysables
ne sont pas reconnus sauf dans les valeurs d'attributs de type approprie.
4.4.2 Inclus
Une entite est incluse quand son texte de remplacement est recupere et traite, a
la place de l'appel lui-meme, comme s'il se trouvait dans le document a l'endroit
où l'appel est reconnu. Le texte de remplacement peut contenir des donnees
textuelles et du balisage (sauf des entites parametres) qui doit etre reconnu de
la maniere habituelle, sauf que le texte de remplacement des entites utilisees
pour deguiser des delimiteurs de balisage (les entites amp, lt, gt, apos, quot)
est toujours traite comme des donnees. (La chaîne « AT&T; » devient « AT&T;
» et l'esperluette restante n'est pas reconnue comme un delimiteur d'appel d'entite).
Un appel de caractere est inclus quand le caractere en question est traite a la
place de l'appel lui-meme.
4.4.3 Inclus si validation
Pour valider un document, un processeur XML doit inclure le texte de
remplacement des entites analysables qu'il reconnaît. Toutefois, si une entite
est externe et si le processeur ne cherche pas a valider le document, il peut ne
pas inclure le texte de remplacement. Un tel processeur non-validateur doit
signaler a l'application, le cas echeant, qu'il a reconnu mais n'a pas lu une
entite.
Cette regle est motivee par le fait que l'inclusion automatique prevue par le
mecanisme d'entite de SGML et XML, concu avant tout pour faciliter la modularite
lors de la redaction, n'est pas necessairement approprie pour d'autres
applications. En feuilletant des documents, par exemple, on pourra choisir de
donner une indication visuelle de la presence d'une entite externe et de ne la
recuperer pour affichage que sur demande.
4.4.4 Interdit
Les formes suivantes sont interdites et constituent des erreurs fatales :
un appel a une entite non-analysable ;
un appel de caractere ou un appel d'entite generale dans la DTD, sauf dans une
ValeurEntite ou une ValeurAtt ;
un appel d'entite externe dans une valeur d'attribut.
4.4.5 Inclus dans litteral
Lorsqu'un appel d'entite apparaît dans une valeur d'attribut ou lorsqu'un appel
d'entite parametre apparaît dans une valeur litterale d'entite, son texte de
remplacement est traite a la place de l'appel comme s'il se trouvait dans le
document au lieu où l'appel est reconnu, sauf que les caracteres guillemet
simple et double dans le texte de remplacement sont toujours traites comme
donnees et ne terminent pas le litteral. L'exemple qui suit est bien forme :
alors que celui-ci ne l'est pas :
le texte de remplacement de l'entite « livre » est :
La Peste : Albert Camus,
(c) 1947 Editions Gallimard. &droits;
L'appel d'entite generale « &droits; » sera remplace si l'appel « &livre; »
venait a apparaître dans le contenu du document ou dans une valeur d'attribut.
Ces regles simples peuvent avoir des interactions complexes ; on trouvera un
exemple difficile explique en details en « D. Remplacement des appels d'entite
et de caractere ».
4.6 Entites predefinies
On peut employer des appels d'entite ou de caractere pour deguiser le signe
inferieur-a, l'esperluette et d'autres delimiteurs. Un jeu d'entites generales (amp,
lt, gt, apos, quot) est defini a cette fin. On peut aussi employer des appels
numeriques de caractere ; ils sont remplaces des que reconnus et doivent etre
traites comme donnees textuelles, de sorte que les appels numeriques de
caractere « < » et « & » peuvent etre utilises pour deguiser < et & dans
des donnees textuelles.
Tous les processeurs XML doivent reconnaître ces entites, qu'elles soient
declarees ou non. A des fins d'interoperabilite, les documents XML valides
devraient declarer ces entites, comme n'importe quelles autres, avant tout appel.
S'il y a lieu, les entites en question devraient etre declarees comme entites
internes dont le texte de remplacement est le caractere a deguiser ou un appel
de caractere a ce caractere, comme ci-dessous :
Remarquons que les caracteres < et & dans les declarations de « lt » et « amp »sont
deguises doublement, de maniere a satisfaire l'exigence que le remplacement d'entite
soit bien forme.
4.7 Declarations de notation
Une notation designe par un nom le format d'une entite non-analysable, le format
d'un element muni d'un attribut notation ou l'application cible d'une
instruction de traitement.
Une declaration de notation donne un nom a la notation, nom servant dans les
declarations d'entite et de liste d'attributs et dans les stipulations d'attribut,
ainsi qu'un identificateur externe qui peut permettre a un processeur XML ou a
son application cliente de reperer un assistant capable de traiter des donnees
en cette notation.
Declaration de notation
[82] DeclNotation ::= '' [
CV : Nom de notation unique ]
[83] IdPublic ::= 'PUBLIC' S IdPubLitteral
Contrainte de validite : Nom de notation unique
Le Nom de notation ne doit pas apparaître dans plus d'une DeclNotation.
Les processeurs XML doivent fournir aux applications les nom et identificateur
externe de toute notation declaree et mentionnee dans une valeur d'attribut, une
definition d'attribut ou une declaration d'entite. Le processeur XML peut aussi
transformer l'identificateur externe en un identificateur systeme, un nom de
fichier ou toute autre information utile a l'application pour appeler un
processeur propre a la notation. (Il n'y a pas erreur, toutefois, lorsqu'un
document XML declare et mentionne des notations pour lesquelles des processeurs
idoines ne sont pas disponibles sur le systeme où tourne le processeur XML ou l'application).
4.8 L'entite document
L'entite document sert de racine a l'arbre des entites et de point de depart au
processeur XML. Ce standard ne precise pas comment un processeur XML peut
localiser l'entite document. Contrairement aux autres entites, l'entite document
n'a pas de nom et peut fort bien apparaître a l'entree d'un processeur sans la
moindre identification.
5. Conformite
5.1 Processeurs validateurs et non-validateurs
Les processeurs XML conformes sont de deux classes : validateur et non-validateur.
Les processeurs des deux classes doivent signaler les violations de contraintes
de forme de ce standard dans le contenu de l'entite document et de toute autre
entite analysable qu'ils lisent.
Les processeurs validateurs peuvent en outre, au gre de l'utilisateur, signaler
les violations de contraintes exprimees par les declarations de la DTD et les
violations des contraintes de validite precisees par ce standard. Pour ce faire,
les processeurs XML validateurs doivent lire et traiter la DTD au complet ainsi
que toutes les entites analysables externes mentionnees dans le document.
Les processeurs non-validateurs ne sont tenus que de verifier la forme de l'entite
document, y compris le sous-ensemble interne de la DTD au complet. Bien qu'ils
ne soient pas tenus de verifier la validite du document, ils doivent traiter
toutes les declarations lues dans le sous-ensemble interne de la DTD ainsi que
dans toute entite parametre lue, jusqu'au premier appel d'entite parametre qui n'est
pas lu ; traiter signifie qu'ils doivent utiliser ces declarations pour
normaliser les valeurs d'attribut, inclure le texte de remplacement des entites
internes et fournir les valeurs implicites d'attribut. Sauf si « standalone='yes'
», ils ne doivent pas traiter les declarations d'entite ni les declarations de
liste d'attributs qui suivent un appel d'entite parametre qui n'a pas ete lu,
puisque cette entite pourrait contenir des declarations contradictoires.
5.2 Utilisation des processeurs XML
Le comportement d'un processeur XML validateur est eminemment previsible : il
doit lire toutes les parties d'un document et signaler toute violation des
contraintes de forme et de validite. On est moins exigeant des processeurs non-validateurs,
qui ne sont tenus de lire que l'entite document. Il en resulte deux effets qui
peuvent etre d'importance pour les utilisateurs de processeurs XML :
Certaines erreurs de forme, notamment celles dont la detection exige de lire les
entites externes, peuvent echapper a un processeur non-validateur. Des exemples
de contraintes pouvant etre violees sans avertissement sont celles appelees
Entite declaree, Entite analysable et Pas de recursion, ainsi que certains cas
decrits comme Interdit dans « 4.4 Traitement des entites et des appels par un
processeur XML ».
L'information transmise du processeur a l'application peut varier, selon que le
processeur lit ou non les entites parametres et externes. Ainsi, un processeur
non-validateur peut ne pas normaliser des valeurs d'attribut, ne pas inclure le
texte de remplacement d'entites internes ou ne pas fournir des valeurs
implicites d'attribut, lorsque ces actions impliquent la lecture prealable de
declarations situees dans des entites parametres ou externes.
Afin d'optimiser l'interoperabilite entre differents processeurs XML, les
applications utilisant des processeurs non-validateurs ne devraient pas se fier
a des comportements facultatifs de la part de ces processeurs. Les applications
qui necessitent des fonctions comme les valeurs implicites d'attribut ou des
entites internes declarees dans des entites externes devraient utiliser des
processeurs validateurs.
6. Notation
La grammaire formelle de XML est precisee dans ce standard en utilisant une
notation simple de forme Backus-Naur etendue (EBNF). Chaque regle de la
grammaire definit un symbole, sous la forme :
symbole ::= expression
Un symbole prend une majuscule initiale s'il est le symbole initial d'un langage
regulier, une minuscule initiale autrement. Les chaînes litterales sont entre
guillemets anglais simples ou doubles ('chaîne litterale', "chaîne litterale").
On utilisera, du côte droit d'une regle, les expressions suivantes qui
correspondront a un ou plusieurs caracteres :
#xN
où N est un entier hexadecimal. L'expression equivaut au caractere de l'ISO/CEI
10646 dont le point de code (UCS-4) a la valeur N, sans egard au nombre de zeros
de tete de la forme #xN ; le nombre de zeros de ce point de code depend en effet
du codage utilise.
[abc], [#xN#xN#xN]
equivaut a n'importe quel caractere parmi ceux mentionnes.
[a-zA-Z], [#xN-#xN]
equivaut a n'importe quel caractere dont la valeur appartient a l'intervalle
indique (inclusivement).
[a-zABC], [#xN-#xN#xN#xN#xN]
equivaut a n'importe quel caractere dont la valeur appartient a l'intervalle
indique (inclusivement) ou correspondant a ceux mentionnes.
[^a-z], [^#xN-#xN]
equivaut a n'importe quel caractere dont la valeur n'appartient pas a l'intervalle
indique.
[^abc], [^#xN#xN#xN]
equivaut a n'importe quel caractere autre que ceux mentionnes.
"chaîne"
equivaut a une chaîne litterale correspondant a celle indiquee entre guillemets
anglais doubles.
'chaîne'
equivaut a une chaîne litterale correspondant a celle indiquee entre guillemets
anglais simples.
Ces symboles peuvent s'assembler pour construire des expressions plus complexes
comme suit, où A et B representent des expressions simples :
(expression)
l'expression est traitee comme une unite et peut etre agencee selon la
description de la liste.
A?
equivaut a A ou a rien ; A facultatif.
A B
equivaut a A suivi de B. La concatenation a priorite sur l'alternation. Ainsi, A
B | C D est equivalent a (A B)|(C D).
A | B
equivaut a A ou a B mais pas aux deux.
A - B
equivaut a n'importe quelle chaîne qui correspond a A mais ne correspond pas a B.
A+
equivaut a une ou plusieurs apparitions de A. Cet operateur a priorite sur la
concatenation. Ainsi, A+ B est equivalent a (A+) B.
A*
equivaut a zero, une ou plusieurs apparitions de A. Cet operateur a priorite sur
la concatenation. Ainsi, A* B est equivalent a (A*) B.
On trouvera aussi les notations suivantes dans les productions :
/* ... */
commentaire.
[ cf: ... ]
contrainte de forme ; identifie par un nom une contrainte associee a une
production et imposee aux documents bien formes.
[ cv: ... ]
contrainte de validite ; identifie par un nom une contrainte associee a une
production et imposee aux documents valides.
Annexes
A. Bibliographie
A.1 Bibliographie normative
IANA-CHARSETS
(Internet Assigned Numbers Authority) Official Names for Character Sets, ed.
Keld Simonsen et al.
Cf. ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets.
IETF RFC 1766
IETF (Internet Engineering Task Force). RFC 1766 : Tags for the Identification
of Languages, ed. H. Alvestrand. 1995.
ISO/CEI 10646
ISO (Organisation internationale de normalisation). ISO/CEI 10646-1993 (F).
Technologies de l'information -- Jeu universel de caracteres codes a plusieurs
octets -- Partie 1: Architecture et table multilingue. [Geneve] : Organisation
internationale de normalisation, 1993 (ainsi que les amendements AM 1 a AM 7).
Texte provisoire de la traduction francaise disponible sur .
Unicode
The Unicode Consortium. The Unicode Standard, version 2.0. Reading,
Massachusetts : Addison-Wesley Developers Press, 1996.
A.2 Autres ouvrages
Aho/Ullman
Aho, Alfred V., Ravi Sethi et Jeffrey D. Ullman. Compilateurs: Principes,
techniques et outils. InterEditions, Paris, 1994.
Berners-Lee et al.
Berners-Lee, T., R. Fielding, and L. Masinter. Uniform Resource Identifiers (URI):
Generic Syntax and Semantics. 1997. (En cours de redaction, voir les mises a
jour au RFC1738.)
Brüggemann-Klein
Brüggemann-Klein, Anne. Formal Models in Document Processing.
Habilitationsschrift. Faculte de mathematiques de l'Universite de Fribourg, 1993,
disponible a ftp://ftp.informatik.uni-freiburg.de/documents/papers/brueggem/habil.ps.
Brüggemann-Klein and Wood
Brüggemann-Klein, Anne und D. Wood. Deterministic Regular Languages. Resume
etoffe dans A. Finkel, M. Jantzen, Hrsg., STACS 1992, S. 173-184. Springer-Verlag,
Berlin 1992. Notes de conference dans Computer Science 577. Version complete
intitulee One-Unambiguous Regular Languages dans Information and Computation 140
(2): 229--253, February 1998.
Clark
James Clark. Comparison of SGML and XML. Cf. http://www.w3.org/TR/NOTE-sgml-xml-971215.
IANA-LANGCODES
(Internet Assigned Numbers Authority) Registry of language tags. See http://www.isi.edu/in-notes/iana/assignments/languages/.
IETF RFC1738
IETF (Internet Engineering Task Force). RFC 1738 : Uniform Resource Locators (URL),
ed. T. Berners-Lee, L. Masinter, M. McCahill. 1994.
IETF RFC1808
IETF (Internet Engineering Task Force). RFC 1808 : Relative Uniform Resource
Locators, ed. R. Fielding. 1995.
IETF RFC2141
IETF (Internet Engineering Task Force). RFC 2141 : URN Syntax, ed. R. Moats.
1997.
IETF RFC2376
IETF (Internet Engineering Task Force). RFC 2376 : XML Media Types, ed. E.
Whitehead, M. Murata, 1998.
IETF RFC2396
IETF (Internet Engineering Task Force). RFC 2396 : Uniform Resource Identifiers
(URI): Generic Syntax, ed. T. Berners-Lee, R. Fielding, L. Masinter, 1998.
ISO 639
(Organisation internationale de normalisation). ISO 639:1988 (F). Codes pour la
representation des noms de langue. [Geneve] : Organisation internationale de
normalisation, 1988.
ISO 3166
(Organisation internationale de normalisation). ISO 3166-1:1997 (F). Codes pour
la representation des noms de pays et de leurs subdivisions -- Partie 1: Codes
pays. [Geneve] : Organisation internationale de normalisation, 1997.
ISO 8879
ISO (Organisation internationale de normalisation). ISO 8879:1986 (F).
Traitement de l'information -- Systemes bureautiques -- Langage normalise de
balisage generalise (SGML) (Incorpore l'amendement 1:1988 et l'amendement
WebSGML (ajout de l'annexe K)). [Geneve] : Organisation internationale de
normalisation, 1986.
ISO/IEC 10744
ISO (Organisation internationale de normalisation). ISO/IEC 10744-1992 (E).
Technologies de l'information -- Langage de structuration temporelle/hypermedia
(HyTime) (Publiee actuellement en anglais seulement) [Geneve] : Organisation
internationale de normalisation, 1992. Extended Facilities Annexe. [Geneve] :
Organisation internationale de normalisation, 1996.
B. Classes de caracteres
Conformement aux caracteristiques definies dans le standard Unicode, les
caracteres sont classes en caracteres de base (parmi lesquels on retrouve les
lettres de l'alphabet latin sans diacritiques), en caracteres ideographiques et
en caracteres jonctifs (on y retrouve notamment la plupart des diacritiques). On
distingue aussi les chiffres et les modificateurs de lettre.
Les caracteres
[84] Lettre ::= CarBase | Ideogramme
[85] CarBase ::= [#x0041-#x005A] | [#x0061-#x007A] | [#x00C0-#x00D6] | [#x00D8-#x00F6]
| [#x00F8-#x00FF] | [#x0100-#x0131] | [#x0134-#x013E] | [#x0141-#x0148] | [#x014A-#x017E]
| [#x0180-#x01C3] | [#x01CD-#x01F0] | [#x01F4-#x01F5] | [#x01FA-#x0217] | [#x0250-#x02A8]
| [#x02BB-#x02C1] | #x0386 | [#x0388-#x038A] | #x038C | [#x038E-#x03A1] | [#x03A3-#x03CE]
| [#x03D0-#x03D6] | #x03DA | #x03DC | #x03DE | #x03E0 | [#x03E2-#x03F3] | [#x0401-#x040C]
| [#x040E-#x044F] | [#x0451-#x045C] | [#x045E-#x0481] | [#x0490-#x04C4] | [#x04C7-#x04C8]
| [#x04CB-#x04CC] | [#x04D0-#x04EB] | [#x04EE-#x04F5] | [#x04F8-#x04F9] | [#x0531-#x0556]
| #x0559 | [#x0561-#x0586] | [#x05D0-#x05EA] | [#x05F0-#x05F2] | [#x0621-#x063A]
| [#x0641-#x064A] | [#x0671-#x06B7] | [#x06BA-#x06BE] | [#x06C0-#x06CE] | [#x06D0-#x06D3]
| #x06D5 | [#x06E5-#x06E6] | [#x0905-#x0939] | #x093D | [#x0958-#x0961] | [#x0985-#x098C]
| [#x098F-#x0990] | [#x0993-#x09A8] | [#x09AA-#x09B0] | #x09B2 | [#x09B6-#x09B9]
| [#x09DC-#x09DD] | [#x09DF-#x09E1] | [#x09F0-#x09F1] | [#x0A05-#x0A0A] | [#x0A0F-#x0A10]
| [#x0A13-#x0A28] | [#x0A2A-#x0A30] | [#x0A32-#x0A33] | [#x0A35-#x0A36] | [#x0A38-#x0A39]
| [#x0A59-#x0A5C] | #x0A5E | [#x0A72-#x0A74] | [#x0A85-#x0A8B] | #x0A8D | [#x0A8F-#x0A91]
| [#x0A93-#x0AA8] | [#x0AAA-#x0AB0] | [#x0AB2-#x0AB3] | [#x0AB5-#x0AB9] | #x0ABD
| #x0AE0 | [#x0B05-#x0B0C] | [#x0B0F-#x0B10] | [#x0B13-#x0B28] | [#x0B2A-#x0B30]
| [#x0B32-#x0B33] | [#x0B36-#x0B39] | #x0B3D | [#x0B5C-#x0B5D] | [#x0B5F-#x0B61]
| [#x0B85-#x0B8A] | [#x0B8E-#x0B90] | [#x0B92-#x0B95] | [#x0B99-#x0B9A] | #x0B9C
| [#x0B9E-#x0B9F] | [#x0BA3-#x0BA4] | [#x0BA8-#x0BAA] | [#x0BAE-#x0BB5] | [#x0BB7-#x0BB9]
| [#x0C05-#x0C0C] | [#x0C0E-#x0C10] | [#x0C12-#x0C28] | [#x0C2A-#x0C33] | [#x0C35-#x0C39]
| [#x0C60-#x0C61] | [#x0C85-#x0C8C] | [#x0C8E-#x0C90] | [#x0C92-#x0CA8] | [#x0CAA-#x0CB3]
| [#x0CB5-#x0CB9] | #x0CDE | [#x0CE0-#x0CE1] | [#x0D05-#x0D0C] | [#x0D0E-#x0D10]
| [#x0D12-#x0D28] | [#x0D2A-#x0D39] | [#x0D60-#x0D61] | [#x0E01-#x0E2E] | #x0E30
| [#x0E32-#x0E33] | [#x0E40-#x0E45] | [#x0E81-#x0E82] | #x0E84 | [#x0E87-#x0E88]
| #x0E8A | #x0E8D | [#x0E94-#x0E97] | [#x0E99-#x0E9F] | [#x0EA1-#x0EA3] | #x0EA5
| #x0EA7 | [#x0EAA-#x0EAB] | [#x0EAD-#x0EAE] | #x0EB0 | [#x0EB2-#x0EB3] | #x0EBD
| [#x0EC0-#x0EC4] | [#x0F40-#x0F47] | [#x0F49-#x0F69] | [#x10A0-#x10C5] | [#x10D0-#x10F6]
| #x1100 | [#x1102-#x1103] | [#x1105-#x1107] | #x1109 | [#x110B-#x110C] | [#x110E-#x1112]
| #x113C | #x113E | #x1140 | #x114C | #x114E | #x1150 | [#x1154-#x1155] | #x1159
| [#x115F-#x1161] | #x1163 | #x1165 | #x1167 | #x1169 | [#x116D-#x116E] | [#x1172-#x1173]
| #x1175 | #x119E | #x11A8 | #x11AB | [#x11AE-#x11AF] | [#x11B7-#x11B8] | #x11BA
| [#x11BC-#x11C2] | #x11EB | #x11F0 | #x11F9 | [#x1E00-#x1E9B] | [#x1EA0-#x1EF9]
| [#x1F00-#x1F15] | [#x1F18-#x1F1D] | [#x1F20-#x1F45] | [#x1F48-#x1F4D] | [#x1F50-#x1F57]
| #x1F59 | #x1F5B | #x1F5D | [#x1F5F-#x1F7D] | [#x1F80-#x1FB4] | [#x1FB6-#x1FBC]
| #x1FBE | [#x1FC2-#x1FC4] | [#x1FC6-#x1FCC] | [#x1FD0-#x1FD3] | [#x1FD6-#x1FDB]
| [#x1FE0-#x1FEC] | [#x1FF2-#x1FF4] | [#x1FF6-#x1FFC] | #x2126 | [#x212A-#x212B]
| #x212E | [#x2180-#x2182] | [#x3041-#x3094] | [#x30A1-#x30FA] | [#x3105-#x312C]
| [#xAC00-#xD7A3]
[86] Ideogramme ::= [#x4E00-#x9FA5] | #x3007 | [#x3021-#x3029]
[87] CarJonctif ::= [#x0300-#x0345] | [#x0360-#x0361] | [#x0483-#x0486] | [#x0591-#x05A1]
| [#x05A3-#x05B9] | [#x05BB-#x05BD] | #x05BF | [#x05C1-#x05C2] | #x05C4 | [#x064B-#x0652]
| #x0670 | [#x06D6-#x06DC] | [#x06DD-#x06DF] | [#x06E0-#x06E4] | [#x06E7-#x06E8]
| [#x06EA-#x06ED] | [#x0901-#x0903] | #x093C | [#x093E-#x094C] | #x094D | [#x0951-#x0954]
| [#x0962-#x0963] | [#x0981-#x0983] | #x09BC | #x09BE | #x09BF | [#x09C0-#x09C4]
| [#x09C7-#x09C8] | [#x09CB-#x09CD] | #x09D7 | [#x09E2-#x09E3] | #x0A02 | #x0A3C
| #x0A3E | #x0A3F | [#x0A40-#x0A42] | [#x0A47-#x0A48] | [#x0A4B-#x0A4D] | [#x0A70-#x0A71]
| [#x0A81-#x0A83] | #x0ABC | [#x0ABE-#x0AC5] | [#x0AC7-#x0AC9] | [#x0ACB-#x0ACD]
| [#x0B01-#x0B03] | #x0B3C | [#x0B3E-#x0B43] | [#x0B47-#x0B48] | [#x0B4B-#x0B4D]
| [#x0B56-#x0B57] | [#x0B82-#x0B83] | [#x0BBE-#x0BC2] | [#x0BC6-#x0BC8] | [#x0BCA-#x0BCD]
| #x0BD7 | [#x0C01-#x0C03] | [#x0C3E-#x0C44] | [#x0C46-#x0C48] | [#x0C4A-#x0C4D]
| [#x0C55-#x0C56] | [#x0C82-#x0C83] | [#x0CBE-#x0CC4] | [#x0CC6-#x0CC8] | [#x0CCA-#x0CCD]
| [#x0CD5-#x0CD6] | [#x0D02-#x0D03] | [#x0D3E-#x0D43] | [#x0D46-#x0D48] | [#x0D4A-#x0D4D]
| #x0D57 | #x0E31 | [#x0E34-#x0E3A] | [#x0E47-#x0E4E] | #x0EB1 | [#x0EB4-#x0EB9]
| [#x0EBB-#x0EBC] | [#x0EC8-#x0ECD] | [#x0F18-#x0F19] | #x0F35 | #x0F37 | #x0F39
| #x0F3E | #x0F3F | [#x0F71-#x0F84] | [#x0F86-#x0F8B] | [#x0F90-#x0F95] | #x0F97
| [#x0F99-#x0FAD] | [#x0FB1-#x0FB7] | #x0FB9 | [#x20D0-#x20DC] | #x20E1 | [#x302A-#x302F]
| #x3099 | #x309A
[88] Chiffre ::= [#x0030-#x0039] | [#x0660-#x0669] | [#x06F0-#x06F9] | [#x0966-#x096F]
| [#x09E6-#x09EF] | [#x0A66-#x0A6F] | [#x0AE6-#x0AEF] | [#x0B66-#x0B6F] | [#x0BE7-#x0BEF]
| [#x0C66-#x0C6F] | [#x0CE6-#x0CEF] | [#x0D66-#x0D6F] | [#x0E50-#x0E59] | [#x0ED0-#x0ED9]
| [#x0F20-#x0F29]
[89] ModificateurLettre ::= #x00B7 | #x02D0 | #x02D1 | #x0387 | #x0640 | #x0E46
| #x0EC6 | #x3005 | [#x3031-#x3035] | [#x309D-#x309E] | [#x30FC-#x30FE]
Les classes de caracteres definies ci-dessus peuvent etre derivees de la base de
donnees des caracteres d'Unicode de la facon suivante :
Les caracteres initiaux de nom doivent appartenir a une des categories suivantes
: Ll, Lu, Lo, Lt, Nl.
Les autres caracteres constitutifs de nom doivent appartenir a une des
categories Mc, Me, Mn, Lm, ou Nd.
Les caracteres dans la zone de compatibilite (c-a-d ceux dont la valeur est
superieure a #xF900 et inferieure a #xFFFE) ne sont pas admis dans les noms XML.
Les caracteres qui connaissent une decomposition de compatibilite (c-a-d ceux
dont le champ 5 dans la base de donnees contient une « balise de formatage de
compatibilite », indique par un champ 5 commencant par un « < ») ne sont pas
permis.
Les caracteres suivants sont consideres des caracteres initiaux de nom, car le
fichier de proprietes les classe parmi les caracteres alphabetiques : [#x02BB-#x02C1],
#x0559, #x06E5, #x06E6.
Les caracteres #x20DD-#x20E0 sont exclus (conformement a la section 5.14 d'Unicode).
Le caractere #x00B7 est classe parmi les modificateurs de lettre, le fichier de
proprietes le classant de la sorte.
Le caractere #x0387 est considere comme un caractere constitutif de nom car #x00B7
est son equivalent canonique.
Les caracteres « : » et « _ » sont permis comme caracteres initiaux de nom.
Les caracteres « - » et « . » sont permis comme caracteres constitutifs de nom.
C. XML et SGML (annexe informative)
XML a ete concu de telle sorte qu'il soit un sous-ensemble de SGML, ce qui
signifie que tout document XML devrait egalement etre un document SGML conforme.
Pour une comparaison detaillee des restrictions que XML impose aux documents au-dela
de celles imposees par SGML, voir [Clark].
D. Developpement des appels d'entite et de caracteres (annexe informative)
Cette annexe illustre par quelques exemples la suite des operations de
reconnaissance et de developpement qui ont lieu lors du traitement des appels d'entite
et de caracteres, tel que decrit dans « 4.4 Traitement des entites et des appels
par un processeur XML ».
Si la DTD contient la declaration suivante :
On peut deguiser une esperluette (&)
soit par un appel de caractere (&#38;)
soit par un appel d'entite generale (&).
" >
alors le processeur XML reconnaîtra les appels de caracteres lors de l'analyse
de la declaration d'entite et les resoudra avant de stocker la chaîne suivante
comme valeur de l'entite « exemple » :
On peut deguiser une esperluette (&)
soit par un appel de caractere (&)
soit par un appel d'entite generale (&).
Un appel a « &exemple; » au sein du document enclenchera une nouvelle analyse du
texte, lors de laquelle on reconnaîtra les balises ouvrante et fermante de l'element
« p » ainsi que les trois appels qui seront developpes. On aura donc comme
resultat un element « p » avec le contenu suivant (rien que des donnees, pas de
delimiteur ni de balisage) :
On peut representer une esperluette (&)
soit par un appel de caractere (&)
soit par un appel d'entite generale (&).
Un exemple plus complexe illustrera completement les regles en question et leurs
effets. Dans l'exemple ci-dessous, les numeros de ligne ne servent que de
reference.
1
2
4
5 ' >
6 %xx;
7 ]>
8 Cet exemple illustre une methode &risquee;.
Ce qui a pour resultat :
a la ligne 4, de developper d'emblee l'appel au caractere 37, et de stocker l'entite
parametre « xx » dans la table des symboles avec comme valeur « %zz; ». Puisqu'on
ne reanalyse pas le texte de remplacement, il n'y a pas reconnaissance de l'appel
a l'entite parametre « zz » par le processur (reconnaissance qui aurait cause
une erreur, « zz » n'etant pas encore declaree.)
a la ligne 5, de developper sur le champ l'appel de caractere « < » et de
stocker l'entite parametre « zz » avec comme texte de remplacement « », une declaration d'entite bien formee.
a la ligne 6, de reconnaître l'appel a « xx » et d'analyser le texte de
remplacement de « xx » (a savoir « %zz; »). Le processeur reconnaît alors l'appel
a « zz » et analyse son texte de remplacement (« »). L'entite generale « risquee » est donc maintenant declaree avec
comme texte de remplacement « sujet a erreurs ».
a la ligne 8, de reconnaître l'appel a l'entite generale « risquee » et de la
developper de telle sorte que le contenu de l'element « essai » est la chaîne
auto-descriptive (et agrammaticale) Cet exemple illustre une methode sujet a
erreurs.
E. Modeles de contenu deterministes (annexe informative)
Pour favoriser la compatibilite, il est necessaire que les modeles de contenu
des declarations de type d'elements soient deterministes.
SGML exige des modeles de contenu deterministes (appeles « non-ambiguës ») ; les
processeurs XML construits sur la base de systemes SGML peuvent signaler comme
erreurs les modeles de contenu non-deterministes.
Par exemple, le modele de contenu ((b, c) | (b, d)) est non-deterministe, car
etant donne un b initial, l'analyseur ne peut determiner a quel b du modele il
correspond sans savoir d'avance quel element suit le b. Dans ce cas-ci, les deux
references ab peuvent etre fusionnes en une seule reference, le modele devenant
(b, (c | d)). Un b initial correspond maintenant clairement a un seul nom dans
le modele de contenu. L'analyseur n'a plus besoin de prevoir ce qui suit ; c ou
d serait accepte.
Formellement : un automate a etats finis peut etre construit, a partir du modele
de contenu, en utilisant les algorithmes standards comme l'algorithme 3.5 dans
la section 3.9 de Aho, Sethi et Ullman [Aho/Ullman]. Dans plusieurs de ces
algorithmes, un ensemble des suivants est construit pour chaque position dans l'expression
reguliere (c-a-d chaque feuille dans l'arbre syntaxique de l'expression
reguliere) ; si une des positions a un ensemble des suivants dans lequel plus d'une
des positions suivantes a le meme nom de type d'element, alors le modele de
contenu est errone et peut etre signale comme tel.
Il existe des algorithmes permettant de reduire automatiquement beaucoup de
modeles de contenu non-deterministes (mais pas tous) a des modeles deterministes
equivalents ; cf. Brüggemann-Klein 1991 [Brüggemann-Klein].
F. Auto-detection du codage de caracteres (annexe informative)
La declaration de codage XML tient le rôle d'etiquette interne a chaque entite,
indiquant quel codage de caracteres y est utilise. Pour qu'un processeur XML
puisse lire l'etiquette interne, toutefois, il semble devoir connaître le codage
utilise, ce qui est precisement ce que l'etiquette cherche a annoncer. En
general, la situation est sans issue. Le cas est neanmoins meilleur en XML,
puisque XML limite le cas general de deux facons : un processeur donne ne gere
qu'un nombre fini de codages de caracteres ; il y a des restrictions sur la
position et le contenu de la declaration de codage XML, restrictions telles qu'il
est faisable de detecter automatiquement le codage de chaque entite dans les cas
normaux. De plus, dans bien des cas d'autres sources d'information sont
disponibles en sus des donnees XML elles-memes. Deux cas sont a distinguer,
selon qu'une entite XML est presentee au processeur avec ou sans information
externe sur le codage. Nous considerons d'abord le dernier cas.
Etant donne que toute entite XML codee autrement qu'en UTF-8 ou UTF-16 doit
commencer par une declaration de codage, dont les premiers caracteres doivent
etre ',
Nicolas Lesbats et Philippe Deschamp .
Traduction
Le document original a ete divise en sections (matiere liminaire, chapitres et
annexes) que se sont partages les traducteurs. Une fois les traductions faites,
le document traduit fut reassemble au moyen d'un script perl ad hoc qui s'est
revele fort utile pendant l'etape de revision.
Revision
Dans un premier temps, chaque traducteur a revise certaines des sections
traduites par les autres traducteurs ; toutes les sections ont ainsi ete
revisees au moins une fois. Cette etape a conduit a un affinement de la
terminologie, a son uniformisation et a la correction de nombreuses erreurs.
Quelques erreurs de l'original ont aussi ete decouvertes, qui ont ete soumises
au groupe de travail idoine du W3C.
Le document entier a ensuite ete relu attentivement par Alain LaBonte
et Richard Parent qui ont releve quelques erreurs et
suggere quelques ameliorations a la terminologie. L'ebauche etant en permanence
sur le Web et une certaine publicite ayant ete faite de sa presence, quelques
personnes nous ont contacte pour signaler des erreurs ou ameliorations
souhaitables.
Finalement, le document traduit et revise plusieurs fois a ete valide au moyen
du validateur HTML du W3C. Quelques ajustements du balisage l'ont rendu valide :