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 ::= '' 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 ::= '' 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]+ ';' | '&#x' [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 « &#x », 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 (&#38;) soit par un appel de caractere (&#38;#38;) soit par un appel d'entite generale (&amp;).

" > 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 (&#38;) soit par un appel d'entite generale (&amp;).

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 :