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.
Des erreurs ont pu survenir malgré le soin apporté à ce travail.
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.
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.
On peut consulter les traductions en français d'autres documents du W3C à
http://www.w3.org/Consortium/Translation/French
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.
Copyright © 2001 W3C® (MIT, INRIA, Keio), tous droits réservés. Les règles de responsabilité, de nom de marque, d'utilisation des documents et de licence des logiciels du W3C s'appliquent.
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.
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.
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.
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).
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.
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 :
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.
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 :
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.
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.
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 :
L'axe des espaces de nommage : Considérons une liste L ne contenant que des nœuds d'espaces
de nommage dans l'axe et dans l'ensemble de nœuds, en ordre alphabétique croissant. Pour commencer le traitement de la
liste L, si le premier nœud n'est pas le nœud de l'espace de nommage par défaut (un nœud sans
URI d'espace de nommage et sans nom local), alors générer un caractère espace suivi par xmlns="",
si et seulement si les conditions suivantes sont réunies :
Cette dernière condition élimine les occurrences superflues de xmlns="" dans la forme canonique,
comme un élément reçoit seulement un xmlns="" si son espace de nommage par défaut est
vide et s'il a un parent immédiat dans la forme canonique qui a un espace de nommage par défaut non vide. Pour
achever le traitement de la liste L, traiter simplement chaque nœud d'espace de nommage dans L,
mais omettre le nœud d'espace de nommage avec un nom local xml, que définit le préfixe xml,
si sa valeur de chaîne est "http://www.w3.org/XML/1998/namespace" ;
xmlns au nœud d'espace de nommage par défaut s'il existe (dans XPath, le nœud
d'espace de nommage par défaut a un URI et un nom local vide) ;
&, tous les crochets à gauche « < » par <, tous les
caractères guillemets par " et les caractères blancs #x9, #xA et #xD
par des références de caractères. Les références de caractères s'écrivent en
hexadécimal majuscule sans zéro de tête (par exemple, #xD est représenté par la
référence de caractère 
) ;&, les crochets à gauche « < » par <, les crochets à droite
« > » par > et les caractères #xD par 
 ;<?), le nom de cible de l'instruction de traitement du nœud, un caractère
espace en tête et la valeur de chaîne si celle-ci n'est pas vide et le symbole de fermeture de l'instruction de traitement
(?>). Si la valeur de chaîne est vide, alors le caractère espace de tête n'est pas rajouté.
Également, un caractère de queue #xA est restitué, après le symbole de fermeture de
l'instruction de traitement des instructions de traitement enfants du nœud racine ayant un ordre de document moindre que
l'élément document, et un caractère de tête #xA, avant le symbole d'ouverture de l'instruction
de traitement des instructions de traitement enfants du nœud racine ayant un ordre de document plus grand que l'élément
document ;<!--),
la valeur de chaîne du nœud et le symbole de fermeture de commentaire (-->). Également,
un caractère de queue « #xA » est restitué après le symbole de fermeture de commentaire
des commentaires enfants du nœud racine ayant un ordre de document moindre que l'élément document, et un
caractère de tête #xA, avant le symbole d'ouverture de commentaire des commentaires enfants du nœud
racine ayant un ordre de document plus grand que l'élément document. (Les enfants commentaires du nœud racine
représentent des commentaires en dehors de l'élément document au niveau supérieur et en dehors de la
déclaration de type de document).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.
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.
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é).
| Document en entrée |
<?xml version="1.0"?>
|
| Forme canonique (non commentée) |
<?xml-stylesheet href="doc.xsl"
|
| Forme canonique (commentée) |
<?xml-stylesheet href="doc.xsl"
|
Cet exemple illustre :
| Document en entrée |
<doc>
|
| Forme canonique |
<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 « > ».
| Document en entrée |
<!DOCTYPE doc [<!ATTLIST e9 attr CDATA "default">]>
|
| Forme canonique |
<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).
| Document en entrée |
<!DOCTYPE doc [
|
| Forme canonique |
<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   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.
| Document en entrée |
<!DOCTYPE doc [
|
| Forme canonique (non commentée) |
<doc attrExtEnt="entExt">
|
Cet exemple illustre :
| Document en entrée |
<?xml version="1.0" encoding="ISO-8859-1"?>
|
| 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 « © ».
| Document en entrée |
<!DOCTYPE doc [
|
| Expression du sous-ensemble du document |
<!-- Évalué par rapport à la déclaration xmlns:ietf="http://www.ietf.org" -->
|
| 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 :
xml, dans les sous-ensembles du document ;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.
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.
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).
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).
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.
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.
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.
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 :
xmlns="" dans les formes canoniques, pour les applications qui ne sont même
pas aptes à utiliser les espaces de nommage, ou ne les gèrent que de façon réduite ;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.
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.
Les personnes suivantes ont fait des remarques pertinentes qui participent à la qualité de cette spécification :