Recommandation XML canonique (XML-C14N) du W3C en version française

Statut du document traduit

Ceci est une traduction de la recommandation du W3C portant sur la canonisation XML.

Cependant ce n'est pas la version officielle en français de la recommandation. Seul le document original en anglais a valeur de norme. On peut l'obtenir à : http://www.w3.org/TR/xml-c14n.

Avertissement

Des erreurs ont pu survenir malgré le soin apporté à ce travail.

Notes sur la traduction

Certains concepts sont difficiles à rendre en français ou peuvent nécessiter une explication, aussi les expressions originales en anglais viennent parfois en renfort dans le texte sous cette forme :
ex. traduction [ndt. translation]

D'autre part, certains liens renvoient sur des définitions contenues dans les recommandations originales du W3C. Ces liens sont doublés vers leur version française et sont signalés ainsi : vf.

On peut trouver la liste des modifications qui seront apportées dans une prochaine version à http://www.w3.org/2001/03/C14N-errata.

Archives compressées et autres formats

Cette traduction est disponible sous forme d'archive compressée et, le cas échéant, dans d'autres formats à l'adresse http://www.yoyodesign.org/doc/w3c/w3c.html.

Autres documents traduits

On peut consulter les traductions en français d'autres documents du W3C à
http://www.w3.org/Consortium/Translation/French

Avis légal

Copyright © 1994-2003 World Wide Web Consortium,
(Massachusetts Institute of Technology,
European Research Consortium for Informatics and Mathematics,
Keio University).
Tous droits réservés. Consulter la notice de copyright pour les productions du W3C.


W3C

XML canonique
version 1.0

Recommandation du W3C du 15 mars 2001

Cette version :
http://www.w3.org/TR/2001/REC-xml-c14n-20010315
Dernière version :
http://www.w3.org/TR/xml-c14n
Version précédente :
http://www.w3.org/TR/2001/PR-xml-c14n-20010119
Auteur/rédacteur :
John Boyer, PureEdge Solutions Inc., jboyer@PureEdge.com

Résumé

Tout document XML fait partie d'un ensemble de documents XML, qui sont logiquement équivalents dans le contexte d'une application, mais dont la représentation physique varie en fonction des changements syntaxiques autorisés par la spécification XML 1.0 [XML] et celle des espaces de nommage dans XML [Names]. Cette spécification décrit une méthode pour générer une représentation physique, la forme canonique, d'un document XML qui tient compte des changements admissibles. À l'exception des limitations concernant des situations inhabituelles, quand deux documents ont la même forme canonique, alors les deux documents sont logiquement équivalents dans le contexte de l'application donnée. Remarquez que deux documents peuvent avoir des formes canoniques distinctes et pourtant être équivalents dans un contexte donné, en fonction des règles d'équivalence propres de l'application qui ne pourraient être assimilées par aucune spécification XML générale.

Statut de ce document

Cette section décrit le statut de ce document au moment de sa parution. D'autres documents peuvent venir le remplacer. Le dernier statut de ce document est conservé au W3C.

Ce document, qui a été revu par les membres du W3C et les tiers concernés, a été homologué par le Directeur comme recommandation du W3C. C'est un document stable qui peut être utilisé comme matériel de référence ou cité comme référence normative par un autre document.

Ce document a été produit par le groupe de travail XML Signature IETF/W3C, (voir également le compte-rendu d'activité XML Signature du W3C). Cette version inclut quelques améliorations rédactionnelles par rapport à la version antérieure. Le seul changement en substance est l'ajout d'un article dans le corrigé [NFC-Corrigendum] du rapport technique « TR15 : Les formes de normalisation Unicode » [NFC]. Ce corrigé tient compte d'une erreur selon laquelle le caractère U+FB1D HEBREW LETTER YOD WITH HIRIQ a été omis par accident de la table des exclusions de composition de la norme Unicode 3.0. Les implémentations canoniques XML doivent désormais (correctement) exclure ce caractère de la composition des caractères lors du traitement de normalisation [NFC].

La spécification XML canonique a été revue en détails pendant son développement, selon la procédure du W3C. Le groupe de travail a résolu avec succès tous les problèmes soulevés lors de la phase de dernier appel et d'appel pour implémentation et a documenté l'existence d'implémentations interopérables dans son rapport d'interopérabilité.

Veuillez signaler les erreurs de ce document au rédacteur en même temps qu'une copie sur la liste de diffusion publique w3c-ietf-xmldsig@w3.org. Toutes ces erreurs seront documentées dans un errata disponible à http://www.w3.org/2001/03/C14N-errata.

On peut trouver la liste des rapports techniques courants du W3C à http://www.w3.org/TR.

Table des matières

  1. Introduction
    1. La terminologie
    2. Les applications
    3. Les limitations
  2. La canonisation XML
    1. Le modèle de données
    2. L'ordre du document
    3. Le modèle de traitement
    4. Les sous-ensembles du document
  3. Exemples de canonisation XML
    1. Les instructions de traitement, les commentaires et les éléments en dehors du document
    2. Les blancs dans le contenu du document
    3. Les balises ouvrantes et fermantes
    4. Les modifications des caractères et les références des caractères
    5. Les références des entités
    6. Le codage UTF-8
    7. Les sous-ensembles du document
  4. Les résolutions
    1. Aucune déclaration XML
    2. Aucune normalisation du modèle des caractères
    3. La gestion des blancs en dehors de l'élément document
    4. Aucune récriture du préfixe de l'espace de nommage
    5. L'ordre des déclarations d'espace de nommage et des attributs
    6. Les déclarations d'espaces de nommage superflues
    7. La propagation de la déclaration de l'espace de nommage par défaut dans les sous-ensembles du document
    8. Le tri des attributs par l'URI de l'espace de nommage
  5. Références
  6. Remerciements

1 Introduction

La recommandation XML 1.0 [XML] spécifie la syntaxe d'une classe de ressources, appelées documents XML. La recommandation des espaces de nommage dans XML [Names] spécifie une syntaxe et une sémantique supplémentaires pour les documents XML. Il est possible que des documents XML, qui sont équivalents pour les utilisations de nombreuses applications, diffèrent dans leur représentation physique. Par exemple, ils peuvent différer dans la structure de leurs entités, l'ordre de leurs attributs et le codage de leurs caractères. Cette spécification a pour objectif l'établissement d'une méthode pour déterminer si deux documents sont identiques ou non, ou si une application a modifié le document ou non, hormis les transformations permises par la spécification XML 1.0 ou celles des espaces de nommage dans XML.

1.1 La terminologie

Les mots-clés « DOI(VEN)T », « NE DOI(VEN)T PAS », « REQUIS », « DEVRA », « NE DEVRA PAS », « DEVRAIT », « NE DEVRAIT PAS », « RECOMMANDÉ », « PEUT » et « OPTIONNEL », employés dans ce document, doivent s'interpréter comme cela est décrit dans le document RFC2119 [Keywords].

Voir le renvoi [Names] pour la définition de QName.

Un « sous-ensemble du document » est une portion de document XML, représentée par un ensemble de nœuds, qui peut ne pas inclure tous les nœuds du document.

La « forme canonique » d'un document XML est la représentation physique du document produite selon la méthode décrite dans cette spécification. Les changements se résument à la liste suivante :

Le terme « XML canonique » se rapporte à un code XML qui est dans la forme canonique. La « méthode de canonisation XML » est l'algorithme, défini par cette spécification, qui génère la forme canonique d'un document XML donné, ou d'un sous-ensemble de ce document. Le terme « canonisation XML » se rapporte à l'opération qui consiste à appliquer la méthode de canonisation XML sur un document XML, ou un sous-ensemble de celui-ci.

La recommandation XPath 1.0 [XPath] définit le terme « ensemble de nœuds » [ndt. node-set] et spécifie un modèle de données pour représenter un document XML en entrée sous forme d'un ensemble de nœuds de divers types (élément, attribut, espace de nommage, texte, commentaire, instruction de traitement et racine). Les nœuds sont inclus ou non dans un ensemble de nœuds en fonction de l'évaluation d'une expression. Dans cette spécification, on emploie un ensemble de nœuds pour indiquer directement si chaque nœuds devrait être restitué ou non dans la forme canonique (dans ce sens, on l'utilise comme ensemble mathématique formel). Un nœud exclus de cet ensemble n'est pas restitué dans la forme canonique qui est générée, même si son nœud parent est compris dans l'ensemble de nœuds. Néanmoins, un nœud omis peut encore influer sur la restitution de ses descendants (par exemple, en augmentant le contexte de l'espace de nommage des descendants).

1.2 Les applications

Comme la recommandation XML 1.0 [XML] et celle des espaces de nommage dans XML [Names] définissent plusieurs méthodes syntaxiques pour exprimer les mêmes informations, les applications XML tendent à prendre des libertés vis-à-vis des changements qui n'ont aucun impact sur le contenu informationnel du document. La canonisation XML est conçue dans le but d'aider les applications qui demandent la possibilité de tester si le contenu informationnel d'un document, ou d'un sous-ensemble du document, a changé ou non. Ceci est réalisé par comparaison de la forme canonique du document original, avant le traitement par l'application, avec la forme canonique du document résultant du traitement de l'application.

Par exemple, une signature numérique sur la forme canonique d'un document XML, ou d'un sous-ensemble de celui-ci, permettrait aux calculs du condensé de la signature d'être insensibles aux changements intervenant dans la représentation physique du document original, pourvu que ces changements aient été définis comme étant logiquement équivalent par la recommandation XML 1.0 ou celle des espaces de nommage XML. Au cours de la génération de la signature, le condensé est calculé sur la forme canonique du document. Le document est ensuite transmis au tiers concerné qui valide la signature en lisant le document et en calculant un condensé de la forme canonique du document reçu. L'équivalence des condensés calculés par le signataire et le tiers concerné (et donc l'équivalence des formes canoniques sur lesquelles ils ont été calculés) garantit que le contenu informationnel du document n'a pas été altéré depuis sa signature.

1.3 Les limitations

Deux documents XML peuvent avoir des contenus informationnels qui diffèrent et qui sont néanmoins logiquement équivalents dans le contexte d'une application donnée. Bien que deux documents XML soient équivalents (mises à part les limitations indiquées dans cette section) si leurs formes canoniques sont équivalentes, le présent travail n'a pas pour objectif d'établir une méthode telle que deux documents soient équivalents si et seulement si leurs formes canoniques sont identiques. Une telle méthode est impossible, en partie du fait des règles spécifiques de l'application, telles que celles régissant les blancs sans importance et les données équivalentes (par exemple, l'expression <color>black</color> à comparer avec <color>rgb(0,0,0)</color>). Il existe également des équivalences établies par d'autres recommandations et avant-projets du W3C. La prise en compte de ces règles d'équivalence supplémentaires est hors du cadre de ce travail. Elles peuvent être considérées par l'application ou devenir l'objet de spécifications ultérieures.

La forme canonique d'un document XML peut ne pas être entièrement opérationnelle dans le contexte de l'application, même si les circonstances dans lesquelles cela survient sont inhabituelles. Ce problème peut concerner certaines applications, étant donné que la forme canonique d'un document et la forme canonique de la forme canonique du document sont équivalentes. Par exemple, dans une application de signature numérique, on ne peut pas établir si le document original opérationnel ou la forme canonique non opérationnelle ont été signés, étant donné que l'on peut substituer la forme canonique au document original sans changer le calcul du condensé. Cependant, le risque pour la sécurité ne survient que dans les circonstances inhabituelles décrites ci-dessous, qui toutes peuvent être résolues ou tout au moins détectées avant la génération de la signature numérique.

Les difficultés apparaissent en raison de la perte des informations suivantes, qui ne sont pas disponibles dans le modèle de données :

  1. l'URI de base, notamment dans le contenu dérivé du texte de remplacement des références externes générales des entités analysées ;
  2. les notations et les références des entités non analysées externes ;
  3. les types des attributs dans la déclaration du type de document.

Dans le premier cas, remarquez qu'un document contenant un URI relatif [URI] est seulement opérationnel quand on y accède à partir d'un URI particulier qui fournit l'URI de base correct. En outre, si le document contient des références externes générales d'entités analysées vers un contenu ayant des URI relatifs, alors ces URI relatifs ne seront pas opérationnels dans la forme canonique, qui remplace les références d'entité par un contenu interne (changeant de ce fait l'URI de base par défaut de ce contenu). On peut typiquement résoudre ces deux problèmes en ajoutant une gestion de l'attribut xml:base [XBase] à l'application, puis en ajoutant les attributs xml:base adéquats à l'élément document et à tous les éléments au niveau supérieur dans les entités externes. De surcroît, les applications ont souvent l'occasion de résoudre les URI relatifs, avant le besoin d'une forme canonique. Par exemple, dans une application de signature numérique, le document est souvent ramené et traité avant la génération de la signature. Le traitement DEVRAIT créer un nouveau document dans lequel les URI relatifs auront été convertis en URI absolus, atténuant ainsi un éventuel risque pour la sécurité pour le nouveau document.

Dans le deuxième cas, la perte des références des entités non analysées externes et des notations qui les relient aux applications signifie que les formes canoniques ne peuvent pas distinguer correctement entre les documents XML qui incorporent des données non analysées au travers de ce mécanisme. C'est un cas inhabituel précisément parce que la plupart des processeurs XML écartent actuellement la déclaration de type de document, ce qui écarte la notation, la corrélation de l'entité à un URI et le type d'attribut qui relie la valeur d'attribut au nom d'une entité. Pour les documents qui doivent être soumis à plus d'un processeur XML, la conception XML indique typiquement une référence vers des données non analysées en utilisant un URI dans la valeur de l'attribut.

Dans le troisième cas, la perte des types des attributs peut affecter la forme canonique de diverses manières, en fonction du type. Les attributs de type ID cessent d'être des attributs ID. C'est pourquoi, toutes les expressions XPath, qui se réfèrent à la forme canonique en utilisant la fonction id(), cessent d'opérer. Les types d'attribut ENTITY et ENTITIES ne sont pas concernés par ce cas ; ils sont couverts dans le deuxième cas ci-dessus. Les attributs de type énuméré et de type ID, IDREF, IDREFS, NMTOKEN, NMTOKENS et NOTATION échouent à être contraint de manière appropriée, lors des tentatives ultérieures pour changer la valeur de l'attribut, si la forme canonique remplace le document original pendant le traitement de l'application. Les applications peuvent contourner les difficultés de ce genre en s'assurant du placement en tête d'une déclaration de type de document appropriée, avant d'utiliser la forme canonique dans un traitement XML supplémentaire. Ce sera vraisemblablement une tâche aisée puisque les listes d'attributs sont acquises à partir d'un sous-ensemble de DTD externe standard et toutes les déclarations d'entités et de notations, qui ne sont pas également dans le sous-ensemble de DTD externe, sont typiquement construites à partir des informations de configuration de l'application et rajoutées au sous-ensemble de DTD interne.

Bien que ces limitations ne soient pas graves, il serait possible de les résoudre dans une version future de la canonisation XML si, par exemple, une nouvelle version de XPath était créée, qui s'appuierait sur l'ensemble d'informations XML [Infoset], actuellement en cours de développement au W3C.

2 La canonisation XML

2.1 Le modèle de données

Le modèle de données définit dans la recommandation XPath 1.0 [XPath] est utilisé pour représenter le document ou le sous-ensemble de document XML en entrée. Les implémentations DEVRAIENT s'appuyer sur une implémentation XPath, mais ne sont pas obligées de le faire. La canonisation XML se définit par rapport à la définition XPath d'un ensemble de nœuds et les implémentations DOIVENT produire des résultats équivalents.

Le premier paramètre en entrée pour la méthode de canonisation XML est soit un ensemble de nœuds XPath, soit un flux d'octets contenant un document XML bien-formé. Les implémentations DOIVENT gérer les flux d'octets en entrée et DEVRAIENT également gérer les aspects sous-ensembles de documents via les ensembles de nœuds en entrée. Pour la description de la canonisation par rapport à un ensemble de nœuds XPath, cette section traite de la manière dont un flux d'octets est converti en ensemble de nœuds XPath.

Le second paramètre en entrée pour la méthode de canonisation XML est un drapeau booléen, qui indique si les commentaires devraient être inclus ou non par cette méthode dans la forme canonique en sortie. Si la forme canonique contient des commentaires, correspondant aux nœuds de commentaires dans l'ensemble de nœuds en entrée, le résultat est appelé « XML canonique avec commentaires ». Remarquer que le modèle de données XPath ne crée pas de nœuds de commentaires pour les commentaires qui apparaissent dans la déclaration de type de document. Les implémentations sont TENUES d'avoir la possibilité de produire du XML canonique en excluant tous les commentaires qui pourraient survenir dans le document ou le sous-ensemble de document en entrée. La gestion du XML canonique avec commentaires est RECOMMANDÉE.

Si un document XML doit être converti en un ensemble de nœuds, la recommandation XPath REQUIERT qu'un processeur XML soit utilisé pour créer les nœuds de son modèle de données et représenter entièrement le document. Le processeur XML effectue les tâches suivantes, dans cet ordre :

  1. normaliser les sauts de ligne ;
  2. normaliser les valeurs des attributs ;
  3. remplacer les sections de type CDATA par leur contenu textuel ;
  4. résoudre les références des caractères et des entités analysées.

Le flux d'octets en entrée DOIT contenir un document XML bien-formé, mais il n'est pas nécessaire que l'entrée soit validée. Cependant, la normalisation des valeurs d'attributs et la résolution des références d'entités DOIVENT être effectuées selon les procédures du processeur XML de validation. De même, les nœuds des attributs par défaut (déclarés dans les éléments ATTLIST avec une valeur AttValue mais non spécifiés) sont créés dans chaque élément. Ainsi, les déclarations dans la déclaration de type de document sont utilisées pour créer la forme canonique, même si cette déclaration de type de document n'est pas retenue dans la forme canonique.

Le modèle de données XPath représente les données à l'aide de caractères UCS. Les implémentations DOIVENT utiliser des processeurs XML, qui gèrent les codages UTF-8 et UTF-16, et traduire vers le domaine de caractères UCS. Pour UTF-16, les marques d'ordre des multiplets de tête [ndt. leading byte order mark], considérées comme artifices de codage, sont retirées des donnés textuelles UCS (les espaces insécables de largeur nulle qui suivent, apparaissant dans les données UTF-16, ne sont pas retirés) [UTF-16, Section 3.2]. La gestion du codage ISO-8859-1 est RECOMMANDÉE, tous les autres codages de caractères sont OPTIONNELS.

Tous les blancs à l'intérieur du document racine DOIVENT être conservés (sauf les caractères #xD supprimés par la normalisation de délimitation des lignes). Cela comprend tous les blancs dans les entités externes. Les blancs en dehors de l'élément racine DOIVENT être écartés.

Dans le modèle de données XPath, il existe les types de nœuds suivants : racine, élément, commentaire, instruction de traitement, texte, attribut et espace de nommage. Il existe un seul nœud racine dont les enfants sont des nœuds instructions de traitement et commentaires pour représenter les informations qui se trouvent hors de l'élément document (et hors de la déclaration de type de document). Le nœud racine possède également un seul nœud élément qui représente l'élément document au niveau supérieur. Chaque nœud élément peut avoir des nœuds enfants de type élément, texte, instruction de traitement et commentaire. Les attributs et les espaces de nommage associés à un élément ne sont pas considérés comme nœuds enfants de l'élément, mais sont associés à cet élément par inclusion dans les axes des attributs et des espaces de nommage de l'élément. Remarquez que les axes des attributs et des espaces de nommage peuvent ne pas correspondre directement au texte qui apparaît dans la balise ouvrante de l'élément dans le document original.

Remarque : Un élément a des nœuds attributs pour représenter les déclarations des attributs non-espace de nommage qui apparaissent dans la balise ouvrante ainsi que des nœuds pour représenter les attributs par défaut.

Selon le modèle de données de XPath, la canonisation XML reconnaît les espaces de nommage [Names]. Cependant, elle ne peut donc pas tenir compte des équivalences des espaces de nommage, en utilisant une récriture de préfixe d'espace de nommage (voir l'explication dans la section 4). Dans le modèle de données XPath, chaque élément et chaque attribut ont un nom, retourné par la fonction name(), qui peut, à la discrétion de l'application, être le nom de type QName apparaissant dans le document original. La canonisation XML REQUIERT que le processeur XML retienne les informations suffisantes de sorte que le nom de type QName, tel que celui-ci apparaît dans le document original, puisse être fourni.

Remarque : Un élément E possède des nœuds d'espace de nommage, qui représentent ses déclarations d'espace de nommage, ainsi que toutes celles des déclarations d'espace de nommage faites par ses ancêtres qui n'ont pas été surclassées par les déclarations de E, l'espace de nommage par défaut si celui-ci n'est pas vide et la déclaration de préfixe xml.

Remarque : Cette spécification soutient la récente décision plénière XML de déprécier les URI relatifs comme suit : les implémentations de canonisation XML DOIVENT signaler un échec des opérations sur les documents qui contiennent des URI d'espace de nommage relatifs. La canonisation XML NE DOIT PAS être implémenté avec un analyseur XML qui convertit les URI relatifs en URI absolus.

Le contenu textuel est représenté dans le modèle de données XPath par des nœuds de texte. Tous les caractères consécutifs sont placés dans un seul nœud de texte. En outre, les caractères du nœud de texte sont représentés dans le domaine des caractères UCS. La méthode de canonisation XML ne réalise pas la normalisation du modèle des caractères (voir l'explication dans la section 4). Cependant, le processeur XML, qui est utilisé dans la préparation de l'entrée pour le modèle de données XPath, est REQUIS d'utiliser la forme C de normalisation Unicode [NFC, NFC-Corrigendum] lors de la conversion d'un document XML vers le domaine de caractères UCS à partir d'un codage qui n'est pas basé sur UCS (pour l'instant, les codages basés sur UCS comprennent UTF-8, UTF-16, UTF-16BE comme UTF-16LE, UCS-2 et UCS-4).

Puisque la canonisation XML convertit un ensemble de nœuds XPath en une forme canonique, le premier paramétre DOIT être soit un ensemble de nœuds XPath ou bien être converti à partir d'un flux de données vers un ensemble de nœuds, en opérant le traitement XML nécessaire pour créer les nœuds XPath décrit ci-dessus, en fixant ensuite le contexte d'évaluation XPath initial ainsi :

enfin, en évaluant l'expression par défaut suivante :

Valeur du paramètre de commentaire Expression XPath par défaut
Sans ("false") (//. | //@* | //namespace::*)[not(self::comment())]
Avec ("true") (//. | //@* | //namespace::*)

Les expressions dans ce tableau génèrent un ensemble de nœuds qui contient chaque nœud du document XML (sauf les commentaires quand la valeur du paramètre de commentaire est "false").

Si l'entrée est un ensemble de nœuds XPath, alors l'ensemble de nœuds doit contenir explicitement chaque nœud à restituer dans la forme canonique. Par exemple, le résultat de l'expression XPath id("E") est un ensemble de nœuds correspondant à l'élément dont la valeur d'attribut ID est "E". Puisqu'aucun de ses nœuds descendants, nœuds d'attributs et nœuds d'espace de nommage n'est dans l'ensemble, la forme canonique consisterait seulement des balises ouvrante et fermante de l'élément, moins les déclarations d'attributs et d'espaces de nommage, sans contenu interne. La section 3.7 montre un exemple de la sérialisation d'un élément identifié, avec son contenu interne et ses déclarations d'attributs et d'espaces de nommage.

2.2 L'ordre du document

Bien que l'ensemble de nœuds XPath soit défini comme étant désordonné, la recommandation [XPath] définit le terme « ordre du document » comme l'ordre dans lequel la première apparition de la représentation XML de chaque nœud survient dans la représentation du document, après l'expansion des entités générales, et à l'exception des nœuds d'espaces de nommage et d'attributs dont l'ordre dépend de l'application en question.

La méthode de canonisation XML traite un ensemble de nœuds en imposant les règles supplémentaires suivantes d'ordre du document sur les nœuds d'espaces de nommage et d'attribut de chaque élément :

La comparaison alphabétique, qui range les chaînes dans l'ordre alphabétique croissant, se base sur les valeurs de point de code UCS, ce qui équivaut à un ordre alphabétique basé sur UTF-8.

2.3 Le modèle de traitement

L'ensemble de nœuds XPath est converti en un flux d'octets, la forme canonique, en générant les caractères UCS représentatifs pour chacun des nœuds dans l'ensemble de nœuds, dans l'ordre du document croissant, puis en codant le résultat en UTF-8 (sans marque d'ordre pour les multiplets de tête). Aucun nœud n'est traité plus d'une fois. Remarquez que le traitement du nœud élément E comprend le traitement de tous les membres de l'ensemble de nœuds dont E est l'ancêtre. C'est pourquoi, tout de suite après que le texte représentatif pour E a été généré, l'élément E et tous les nœuds dont E est l'ancêtre sont retirés de l'ensemble de nœuds (ou une certaine opération logiquement équivalent a lieu, de sorte que le prochain nƏud de l'ensemble de nœuds, dans l'ordre du document, ne soit pas traité). Remarquez, cependant, que le nœud d'élément n'est pas retiré de l'ensemble de nœuds tant que ses enfants n'ont pas été traités.

Le résultat du traitement du nœud dépend de son type et de sa présence ou non dans l'ensemble de nœuds. Si le nœud n'est pas dans l'ensemble de nœuds, alors aucun texte n'est généré pour celui-ci, à l'exception du résultat du traitement de ses axes des espaces de nommage et des attributs (seulement pour les éléments) et de ses enfants (les éléments et le nœud racine). Si le nœud est dans l'ensemble de nœuds, alors le texte est généré pour représenter le nœud dans la forme canonique, en plus du texte généré par le traitement des axes des espaces de nommage et des attributs et des nœuds enfants de celui-ci.

Remarque : L'ensemble de nœuds est traité comme un ensemble de nœuds, non comme une liste de sous-arbres. Pour canoniser un élément, y compris ses espaces de nommage, attributs et contenu, l'ensemble de nœuds doit effectivement contenir tous les nœuds correspondant à ces parties du documents, et non juste le nœud élément.

Le texte généré pour un nœud dépend de son type, donné dans la liste suivante :

Le nom de type QName d'un nœud est soit le nom local, si la chaîne de préfixe de nommage est vide, soit le préfixe d'espace de nommage suivi par un caractère deux-points « : » et le nom local de l'élément. Le préfixe d'espace de nommage utilisé dans le nom de type QName DOIT être le même que celui qui apparaissait dans le document en entrée.

2.4 Les sous-ensembles de document

Certaines applications requièrent la possibilité de créer une représentation physique pour un sous-ensemble du document XML (autre que celui généré par défaut, qui peut être un sous-ensemble propre du document si les commentaires sont omis). Les implémentation de canonisation XML qui s'appuient sur XPath peuvent offrir cette fonctionnalité à peu de frais, en acceptant un ensemble de nœuds en entrée plutôt qu'un flux d'octets.

Le traitement d'un nœud élément E DOIT être légèrement modifié, quand un ensemble de nœuds XPath est fourni en entrée et quand le parent de l'élément est omis de l'ensemble de nœuds. La méthode pour le traitement de l'axe des attributs d'un élément E dans l'ensemble de nœuds est améliorée. Tous les nœuds éléments au long de l'axe ancestor de l'élément E sont examinés pour trouver les occurrences les plus proches des attributs dans l'espace de nommage xml, tels que xml:lang et xml:space (que ceux-ci soient ou non dans l'ensemble de nœuds). À partir de cette liste des attributs, retirer tous ceux qui se trouvent dans l'axe des attributs de l'élément E (que ceux-ci soient ou non dans l'ensemble de nœuds). Puis, fusionner alphabétiquement cette liste d'attributs avec les nœuds de l'axe des attributs de l'élément E qui se trouvent dans l'ensemble de nœuds, en traitant les nœuds d'attributs dans cette liste des attributs fusionnés.

Remarque : Les entités XML peuvent dériver une signification propre à l'application à partir de n'importe quel endroit dans le balisage XML tout comme de règles non exprimées dans la recommandation XML 1.0 et celle des espaces de nommage dans XML. Clairement, on ne peut pas spécifier de telles règles dans ce document, ainsi le créateur de l'ensemble de nœuds en entrée doit être responsable de la conservation des informations nécessaires pour capturer la sémantique entière des membres de l'ensemble de nœuds résultant.

Le XML canonique généré pour un document XML entier est bien-formé. La forme canonique d'un sous-ensemble de document XML peut ne pas être bien-formée. Cependant, puisque la forme canonique peut faire l'objet d'un traitement XML supplémentaire, la plupart des ensembles de nœuds soumis à canonisation seront conçus pour produire une forme canonique qui soit un document XML, ou une entité analysée générale externe, bien-formé. Qu'elle soit obtenue à partir d'un document entier ou d'un sous-ensemble du document, si la forme canonique est un document XML bien-formé, alors les applications suivantes de la même méthode de canonisation XML sur la forme canonique ne produiront aucun changement.

3 Exemples de canonisation XML

Les exemples dans cette section suppose un processeur non validant, principalement de sorte qu'on puisse utiliser une déclartion de type de document pour déclarer les entités ainsi que les attributs par défaut et les attributs de divers types (tels que ceux des types ID et énuméré), sans avoir à déclarer tous les attributs de tous les éléments dans le document. De même, un exemple contient un élément qui viole délibérément une contrainte de validité (parce qu'il est encore bien-formé).

3.1 Les instructions de traitement, les commentaires et les éléments en dehors du document

Document en entrée <?xml version="1.0"?>

<?xml-stylesheet href="doc.xsl"
type="text/xsl" ?>

<!DOCTYPE doc SYSTEM "doc.dtd">

<doc>Bonjour le monde !<!-- Commentaire 1 --></doc>

<?pi-without-data ?>

<!-- Commentaire 2 -->

<!-- Commentaire 3 -->
Forme canonique (non commentée) <?xml-stylesheet href="doc.xsl"
type="text/xsl" ?>
<doc>Bonjour le monde !</doc>
<?pi-without-data?>
Forme canonique (commentée) <?xml-stylesheet href="doc.xsl"
type="text/xsl" ?>
<doc>Bonjour le monde !<!-- Commentaire 1 --></doc>
<?pi-without-data?>
<!-- Commentaire 2 -->
<!-- Commentaire 3 -->

Cet exemple illustre :

3.2 Les blancs dans le contenu du document in Document Content

Document en entrée <doc>
<propre> </propre>
<sale> A B </sale>
<melange>
A
<propre> </propre>
B
<sale> A B </sale>
C
</melange>
</doc>
Forme canonique <doc>
<propre> </propre>
<sale> A B </sale>
<melange>
A
<propre> </propre>
B
<sale> A B </sale>
C
</melange>
</doc>

Cet exemple illustre :

Remarque : Dans cet exemple, le document en entrée et la forme canonique sont identiques, les deux se terminant par un caractère « > ».

3.3 Les balises ouvrantes et fermantes

Document en entrée <!DOCTYPE doc [<!ATTLIST e9 attr CDATA "default">]>
<doc>
<e1 />
<e2 ></e2>
<e3 name = "elem3" id="elem3" />
<e4 name="elem4" id="elem4" ></e4>
<e5 a:attr="range" b:attr="bien" attr2="suis" attr="Je"
xmlns:b="http://www.ietf.org"
xmlns:a="http://www.w3.org"
xmlns="http://exemple.org"/>
<e6 xmlns="" xmlns:a="http://www.w3.org">
<e7 xmlns="http://www.ietf.org">
<e8 xmlns="" xmlns:a="http://www.w3.org">
<e9 xmlns="" xmlns:a="http://www.ietf.org"/>
</e8>
</e7>
</e6>
</doc>
Forme canonique <doc>
<e1></e1>
<e2></e2>
<e3 id="elem3" name="elem3"></e3>
<e4 id="elem4" name="elem4"></e4>
<e5 xmlns="http://exemple.org" xmlns:a="http://www.w3.org" xmlns:b="http://www.ietf.org" attr="Je" attr2="suis" b:attr="bien" a:attr="range"></e5>
<e6 xmlns:a="http://www.w3.org">
<e7 xmlns="http://www.ietf.org">
<e8 xmlns="">
<e9 xmlns:a="http://www.ietf.org" attr="default"></e9>
</e8>
</e7>
</e6>
</doc>

Cet exemple illustre :

Remarque : Certaines balises ouvrantes dans la forme canonique sont très longues, mais dans cet exemple, chaque balise ouvrante tient entièrement sur une seule ligne.

Remarque : Dans l'élément e5, l'attribut b:attr précède a:attr parce que la clé principale est l'URI de l'espace de nommage, non le préfixe de l'espace de nommage, et l'attribut attr2 precedes b:attr, parce que l'espace de nommage par défaut ne s'applique pas aux attributs non qualifiés (l'URI de l'espace de nommage de l'attribut attr2 est donc vide).

3.4 Les modifications des caractères et les références des caractères

Document en entrée <!DOCTYPE doc [
<!ATTLIST normId id ID #IMPLIED>
<!ATTLIST normNames attr NMTOKENS #IMPLIED>
]>
<doc>
<text>Première ligne&#x0d;&#10;Seconde ligne</text>
<value>&#x32;</value>
<compute><![CDATA[value>"0" && value<"10" ?"valid":"error"]]></compute>
<compute expr='value>"0" &amp;&amp; value&lt;"10" ?"valid":"error"'>valid</compute>
<norm attr=' &apos; &#x20;&#13;&#xa;&#9; &apos; '/>
<normNames attr=' A &#x20;&#13;&#xa;&#9; B '/>
<normId id=' &apos; &#x20;&#13;&#xa;&#9; &apos; '/>
</doc>
Forme canonique <doc>
<text>Première ligne&#xD;
Seconde ligne</text>
<value>2</value>
<compute>value&gt;"0" &amp;&amp; value&lt;"10" ?"valid":"error"</compute>
<compute expr="value>&quot;0&quot; &amp;&amp; value&lt;&quot;10&quot; ?&quot;valid&quot;:&quot;error&quot;">valid</compute>
<norm attr=" ' &#xD;&#xA;&#x9; ' "></norm>
<normNames attr="A &#xD;&#xA;&#x9; B"></normNames>
<normId id="' &#xD;&#xA;&#x9; '"></normId>
</doc>

Cet exemple illustre :

Remarque : Le dernier élément, normId, est bien-formé, mais il viole une contrainte de validité des attributs de type ID. Pour tester les implémentations XML canonique basées sur des processeurs de validation, retirer la ligne contenant cet élément de l'entrée et de la forme canonique. En général, on devrait décourager les consommateurs XML d'utiliser cette fonctionnalité de XML.

Remarque : Les références des caractères blancs autres que &#x20; ne sont pas affectés par la normalisation de la valeur de l'attribut [XML].

Remarque : Dans la forme canonique, la valeur de l'attribut nommé attr, dans l'élément norm, commence par un caractère espace, un caractère apostrophe (guillemet simple), puis quatre caractères espace avant la première référence de caractères.

Remarque : L'attribut expr du second élément compute ne contient aucun saut de ligne.

3.5 Les références des entités

Document en entrée <!DOCTYPE doc [
<!ATTLIST doc attrExtEnt ENTITY #IMPLIED>
<!ENTITY ent1 "Bonjour">
<!ENTITY ent2 SYSTEM "monde.txt">
<!ENTITY entExt SYSTEM "terre.png" NDATA png>
<!NOTATION gif SYSTEM "voirpng.exe">
]>
<doc attrExtEnt="entExt">
&ent1; le &ent2; !
</doc>

<!-- Supposons que monde.txt contient le seul mot "monde" (sans les guillemets) -->
Forme canonique (non commentée) <doc attrExtEnt="entExt">
Bonjour le monde !
</doc>

Cet exemple illustre :

3.6 Le codage UTF-8

Document en entrée <?xml version="1.0" encoding="ISO-8859-1"?>
<doc>&#169;</doc>
Forme canonique <doc>#xC2#xA9</doc>

Cet exemple illustre :

Remarque : Le contenu de l'élément doc N'EST PAS la chaîne #xC2#xA9 mais plutôt les deux octets dont les valeurs hexadécimales sont C2 et A9, ce qui correspond au codage UTF-8 du point de code du caractère copyright « © ».

3.7 Les sous-ensembles du document

Document en entrée <!DOCTYPE doc [
<!ATTLIST e2 xml:space (default|preserve) 'preserve'>
<!ATTLIST e3 id ID #IMPLIED>
]>
<doc xmlns="http://www.ietf.org" xmlns:w3c="http://www.w3.org">
<e1>
<e2 xmlns="">
<e3 id="E3"/>
</e2>
</e1>
</doc>
Expression du sous-ensemble du document <!-- Évalué par rapport à la déclaration xmlns:ietf="http://www.ietf.org" -->

(//. | //@* | //namespace::*)
[
self::ietf:e1 or (parent::ietf:e1 and not(self::text() or self::e2))
or
count(id("E3")|ancestor-or-self::node()) = count(ancestor-or-self::node())
]
Forme canonique <e1 xmlns="http://www.ietf.org" xmlns:w3c="http://www.w3.org"><e3 xmlns="" id="E3" xml:space="preserve"></e3></e1>

Cet exemple illustre :

Remarque : Dans l'expression du sous-ensemble du document, la sous-expression (//. | //@* | //namespace::*) sélectionne tous les nœuds dans le document en entrée, en soumettant chacun d'eux à l'expression du prédicat entre crochets. L'expression est vraie pour l'élément e1 et ses nœuds d'espaces de nommage explicites et elle est vraie si l'élément identifié par « E3 » se trouve dans le chemin ancestor-or-self du nœud contextuel (tel que l'expression ancestor-or-self reste de la même taille dans l'union avec l'élément identifié par « E3 »).

Remarque : La forme canonique ne contient aucun saut de ligne.

4 Les résolutions

Cette section présente un certain nombre de points-clés pour la prise de décision ainsi que le raisonnement qui préside à chaque décision. Bien que cette spécification définisse maintenant la canonisation XML par rapport au modèle de données XPath plutôt que celui de XML Infoset, la forme canonique décrite dans ce document est très semblable, à bien des égards, à la forme canonique décrite dans l'avant-projet XML canonique de janvier 2000 [C14N-20000119]. Cependant, il existe quelques différences et certaines sous-sections présentent les changements intervenus.

4.1 Aucune déclaration XML

La déclaration XML, comprenant le numéro de version et le codage de caractères, est omise de la forme canonique. Le codage n'est pas nécessaire dans la mesure où la forme canonique est codée en UTF-8. La version non plus puisque l'absence d'un numéro de version indique sans ambiguïté la version XML 1.0.

Les versions futures de XML requérront l'inclusion d'une déclaration XML pour indiquer le numéro de version. Par contre, la méthode de canonisation décrite dans cette spécification pourrait ne plus s'appliquer aux futures versions de XML sans quelques modifications. Quand la canonisation d'une nouvelle version de XML sera requise, cette spécification pourrait être mise à jour pour inclure la déclaration XML tout comme il sera vraisemblablement remédié à l'absence de la déclaration XML du modèle de données XPath (par exemple, en ré-émettant un nouveau XPath appuyé sur le modèle de données Infoset).

4.2 Aucune normalisation du modèle des caractères

La norme Unicode [Unicode] autorise plusieurs représentations différentes de certains « caractères pré-composés » (un exemple simple en serait le caractère « ç »). Ainsi, deux documents XML, avec un contenu équivalent pour ce qui est de la plupart des applications, peuvent contenir des séquences de caractères qui diffèrent. Le W3C prépare une représentation normalisée [CharModel]. L'avant-projet XML canonique C14N-20000119 utilisait cette forme normalisée. Cependant, nombre de processeurs XML 1.0 n'effectuent pas cette normalisation. De plus, les applications qui doivent résoudre ce problème respectent la normalisation du modèle de caractères à tout instant, à commencer au moment où le contenu textuel est créé, pour éviter les échecs de traitement qui pourraient sinon en résulter (par exemple, voir l'exemple de Cowan). C'est pourquoi, la normalisation du modèle de caractères a été retirée du champs de la canonisation XML. Malgré tout, le processeur XML, employé pour préparer le modèle de données XPath en entrée, est requis (par le modèle de données) d'utiliser la forme de normalisation C [NFC, NFC-Corrigendum] lors de la conversion d'un document XML vers le domaine de caractères UCS, à partir de tout codage qui ne soit pas basé sur UCS (actuellement, les codages basés sur UCS comprennent UTF-8, UTF-16, UTF-16BE comme UTF-16LE, UCS-2 et UCS-4).

4.3 La gestion des blancs en dehors de l'élément document

L'avant-projet XML canonique C14N-20000119 plaçait un caractère #xA après chaque instruction de traitement en dehors de l'élément document et un autre caractère #xA après la balise fermante de l'élément document. La méthode trouvée dans la présente spécification opère la même fonction, à l'exception de l'omission du #xA final après la dernière instruction de traitement (ou commentaire ou balise fermante de l'élément document). Cette technique assure que les instruction de traitement (et commentaires) enfants du nœud racine soient séparés du balisage par un saut de ligne, même si le nœud racine ou l'élément document sont omis de l'ensemble de nœuds en sortie.

4.4 Aucune récriture du préfixe de l'espace de nommage

L'avant-projet XML canonique C14N-20000119 décrivait une méthode pour la récriture des préfixes d'espaces de nommage, de sorte que deux documents, avec des déclarations d'espaces de nommage logiquement équivalentes, auraient également des préfixes d'espaces de nommage identiques. L'objectif était d'éliminer les dépendances envers des préfixes d'espaces de nommage particuliers dans un document, lors d'un test d'équivalence logique. Cependant, il existe maintenant nombre de contextes dans lesquels les préfixes d'espaces de nommage peuvent donner la valeur des informations dans un document XML. Par exemple, une expression XPath, dans la valeur d'un attribut ou dans le contenu d'un élément, peut référencer un préfixe d'espace de nommage. La récriture des préfixes d'espaces de nommage endommagerait donc un tel document en changeant sa signification (et il ne peut plus être logiquement équivalent, si sa signification a changé).

Plus formellement, soit D1 un document contenant un XPath, dans la valeur d'un attribut ou dans le contenu d'un élément, qui se rapporte aux préfixes de d'espaces de nommage utilisés dans D1. Supposons en outre que les préfixes d'espaces de nommage dans D1 seront tous récrits par la méthode de canonisation. Posons D2 = D1, puis modifions les préfixes d'espaces de nommage dans D2 et modifions les références de l'expression XPath vers les préfixes d'espaces de nommage, de telle sorte que D2 et D1 restent logiquement équivalents. Étant donné que la récriture n'inclut pas les occurences des références d'espace de nommage dans la valeur des attributs et le contenu des éléments, la forme canonique de D1 n'équivaut pas à la forme canonique de D2, puisque les XPath seront différents. Ainsi, bien que la récriture de l'espace de nommage normalise les déclarations d'espaces de nommage, l'objectif consistant à éliminer les dépendances envers les préfixes d'espaces de nommage particuliers dans le document n'est pas atteint.

On peut même prouver que la récriture de l'espace de nommage est dommageable plutôt que simplement inefficace. Soit D1 un document contenant un XPath, dans la valeur d'un attribut ou dans le contenu d'un élément, qui se rapporte aux préfixes d'espaces de nommages utilisés dans D1. Supposons de plus que les préfixes d'espaces de nommage dans D1 seront tous récrits par la méthode de canonisation. Posons maintenant D2 comme la forme canonique de D1. Clairement, les formes canoniques de D1 et D2 sont équivalentes (puisque D2 est la forme canonique de la forme canonique de D1), pourtant D1 et D2 ne sont pas logiquement équivalents, parce que le XPath mentionné ci-dessus fonctionne dans D1 et pas dans D2.

Remarquer qu'on peut émettre un argument similaire à l'encontre de la méthode de canonisation XML basée sur l'un des cas présentés dans la section « Les limitations », les problèmes ne pouvant pas être facilement résolus dans ces cas, alors que nous avons ici l'occasion d'éviter volontairement l'introduction d'une telle limitation.

Les applications, qui doivent effectuer un test d'équivalence logique, doivent réaliser des tests plus sophistiqués que la simple comparaison des flux d'octets. Cepandant, il sera très vraisemblablement nécessaire, dans tous les cas, de tester les équivalences logiques en fonction des règles des applications ainsi que celles des autres recommandations, avant-projets et travaux futurs apparentées à XML.

4.5 L'ordre des déclarations des espaces de nommage et des attributs

L'avant-projet XML canonique C14N-20000119 oscillait entre les déclarations d'espaces de nommage et les déclarations d'attributs. Cela faisait partie du système de récriture des préfixes d'espaces de nommage, que cette spécification élimine. Celle-ci obéit au modèle de données XPath qui place tous les nœuds d'espaces de nommage avant tous les nœuds d'attributs.

4.6 Les déclarations d'espaces de nommage superflues

Les déclarations d'espaces de nommage superflues ne sont pas faites dans la forme canonique. Que ce soit pour un espace de nommage par défaut vide, pour un espace de nommage par défaut non vide ou pour une corrélation de préfixe de nommage, la méthode de canonisation XML en omet la déclaration si elle détermine que l'élément parent immédiat, dans la forme canonique, possède une déclaration équivalente à portée. L'élément document racine est géré spécialement, dans la mesure où il n'a pas d'élément parent. Toutes les déclarations d'espaces de nommage qu'il contient sont retenues, à l'exception d'un espace de nommage par défaut vide qui est automatiquement omis.

Par rapport à la méthode qui consiste à simplement restituer le contexte d'espace de nommage entier de chaque élément, les implémentations ne sont pas contrariées par plus d'un facteur constant dans la durée de traitement et l'utilisation de la mémoire. Les avantages comprennent :

Remarquez que, dans les sous-ensembles des documents, un élément avec les omissions de son élément ancêtre sera restitué dans la forme canonique avec des déclarations d'espaces de nommage qui auront pu être faites dans ses ancêtres omis, préservant ainsi la signification de l'élément.

4.7 La propagation de la déclaration de l'espace de nommage par défaut dans les sous-ensembles du document

Le modèle de données XPath représente un espace de nommage par défaut vide par l'absence d'un nœud, et non par la présence d'un nœud d'espace de nommage par défaut ayant une valeur vide. C'est pourquoi, par rapport au fait que l'élément e3 dans les exemples suivants ne soit pas qualifié par un espace de nommage, nous ne pouvons pas faire la différence entre <e1 xmlns="a:b"><e2 xmlns=""><e3/></e2></e1> et <e1 xmlns="a:b"><e2><e3 xmlns=""/></e2></e1>. Tout ce que nous savons, c'est que l'élément e3 n'était pas qualifié par un espace de nommage en entrée, et donc nous conservons cette information en sortie si l'élément e2 est omis, de sorte que l'élément e3 n'emprunte pas la qualification d'espace de nommage de l'élément e1.

4.8 Le tri des attributs par l'URI de l'espace de nommage

Vu l'obligation de conserver les préfixes d'espace de nommage déclarés dans le document, le tri des attributs par le préfixe plutôt que par l'URI de l'espace de nommage comme clé principale est viable et plus facile à implémenter. Cependant, on a choisi l'URI de l'espace de nommage comme clé principale, parce que cela apparaissait plus proche de l'objectif de la spécification des « espaces de nommage dans XML », qui est d'identifier les espaces de nommage par l'URI et le nom local, et non par un préfixe et un nom local. L'effet de ce tri est le regroupement de tous les attributs qui se trouvent dans le même espace de nommage.

5 Références

C14N-20000119
XML canonique version 1.0, avant-projet du W3C. T. Bray, J. Clark, J. Tauber et J. Cowan. 19 janvier 2000. http://www.w3.org/TR/2000/WD-xml-c14n-20000119.html.
CharModel
Le modèle de caractères pour le World Wide Web, avant-projet du W3C. Rédacteurs Martin J. Dürst, François Yergeau, Misha Wolf, Asmus Freytag et Tex Texin. http://www.w3.org/TR/charmod/.
Cowan
Exemple de dommage causé par la normalisation du modèle de caractères, Message dans l'archive de liste de diffusion du groupe de travail XML Signature. John Cowan, 7 juillet 2000. http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0038.html.
Infoset
L'ensemble d'informations XML, avant-projet du W3C. Rédacteurs John Cowan et Richard Tobin. http://www.w3.org/TR/xml-infoset.
ISO-8859-1
Le jeu de caractères Latin 1 ISO-8859-1. http://www.utoronto.ca/webdocs/HTMLdocs/NewHTML/iso_table.html ou http://www.iso.ch/cate/cat.html.
Keywords
Les mots-clés à utiliser dans les RFC pour indiquer les niveaux d'obligation, IETF RFC 2119. S. Bradner. Mars 1997. http://www.ietf.org/rfc/rfc2119.txt.
Namespaces
Les espaces de nommage dans XML, W3C Recommendation. Rédacteurs Tim Bray, Dave Hollander et Andrew Layman. http://www.w3.org/TR/REC-xml-names/.
NFC
TR15 : Les formes de normalisation Unicode. M. Davis, M. Dürst. Révision du 18 novembre 1999. http://www.unicode.org/unicode/reports/tr15/tr15-18.html.
NFC-Corrigendum
Le corrigé de normalisation. The Unicode Consortium. http://www.unicode.org/unicode/uni2errata/Normalization_Corrigendum.html.
Unicode
La norme Unicode version 3.0. The Unicode Consortium. ISBN 0-201-61633-5. http://www.unicode.org/unicode/standard/versions/Unicode3.0.html.
UTF-16
UTF-16 : un codage de la norme ISO 10646, IETF RFC 2781. P. Hoffman, F. Yergeau. Février 2000. http://www.ietf.org/rfc/rfc2781.txt.
UTF-8
UTF-8 : un format de transformation de la norme ISO 10646, IETF RFC 2279. F. Yergeau. Janvier 1998. http://www.ietf.org/rfc/rfc2279.txt.
URI
Les identifiants de ressource uniformes (URI) : Syntaxe générique, IETF RFC2396. T. Berners-Lee, R. Fielding, L. Masinter. Août 1998 http://www.ietf.org/rfc/rfc2396.txt.
XBase
XML Base Rédacteur Jonathan Marsh, 7 juin 2000. http://www.w3.org/TR/xmlbase/.
XML
Le langage de balisage extensible (XML) 1.0 (Seconde édition), recommandation du W3C. Rédacteurs Tim Bray, Jean Paoli, C. M. Sperberg-McQueen et Eve Maler. 6 octobre 2000. http://www.w3.org/TR/REC-xml.
XML DSig
La syntaxe et le traitement XML-Signature, projet IETF/recommandation candidate du W3C. D. Eastlake, J. Reagle, D. Solo, M. Bartel, J. Boyer, B. Fox et E. Simon. 31 octobre 2000. http://www.w3.org/TR/xmldsig-core/.
XML Plenary Decision
Décision plénière XML du W3C sur les références d'URI relatifs dans les déclarations des espaces de nommage, document du W3C. 11 septembre 2000. http://lists.w3.org/Archives/Public/xml-uri/2000Sep/0083.html.
XPath
Le langage de chemin XML (XPath) version 1.0, recommandation du W3C. Rédacteurs James Clark et Steven DeRose. 16 novembre 1999. http://www.w3.org/TR/1999/REC-xpath-19991116.

6 Remerciements (informatif)

Les personnes suivantes ont fait des remarques pertinentes qui participent à la qualité de cette spécification :