Groupe de travail Réseau |
J. Boyer, PureEdge Solutions Inc. |
Request for Comments : 3076 |
mars 2001 |
Catégorie : Information |
Traduction Claude Brière de L’Isle, décembre 2007 |
Statut du présent mémo
Le présent mémo fournit des informations pour la communauté de l’Internet. Il ne spécifie aucune norme de l’Internet. La distribution du présent mémo n’est soumise à aucune restriction
Notice de copyright
Copyright (C) The Internet Society (2001). Tous droits réservés.
Résumé
Tout document XML (Langage de balisage extensible) fait partie d’un ensemble de documents XML qui sont logiquement équivalents au sein d’un contexte d’application, mais qui peuvent varier dans des représentations physiques sur la base de changements syntaxiques permis par XML 1.0 et par les espaces de nom dans XML. La présente 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 permis. Excepté les limitations concernant quelques cas peu usuels, si deux documents ont la même forme canonique, les deux documents sont logiquement équivalents au sein d’un contexte d’application donné. Noter que deux documents peuvent avoir des formes canoniques différentes et être quand même équivalents dans un contexte donné sur la base de règles d’équivalence spécifiques d’une application dont aucune spécification XML généralisée ne peut tenir compte.
Table des matières
1 Introduction
1.1 Terminologie
1.2 Applications
1.3 Limitations
2 Canonisation XML
2.1 Modèle des données
2.2 Ordre du document
2.3 Modèle de traitement
2.4 Sous-ensembles de document
3 Exemples de canonisation XML
3.1 Instructions de traitement, commentaires, et élément en-dehors d’un document
3.2 Espaces dans le contenu d’un document
3.3 Étiquettes de début et de fin
3.4 Modifications de caractères et références de caractères
3.5 Références d’entité
3.6 Codage UTF-8
3.7 Sous-ensembles de document
4 Résolutions
4.1 Pas de déclaration XML
4.2 Pas de normalisation de modèle de caractère
4.3 Traitement des espaces blanches en-dehors d’un élément de document
4.4 Pas de réécriture de préfixe d’espace de nom
4.5 Ordre des déclarations et attributs des espaces de nom
4.6 Déclarations d’espace de nom superflues
4.7 Propagation des déclarations d’espace de nom par défaut dans les sous-ensembles de documents
4.8 Tri des attributs par URI d’espace de nom ..
Considérations sur la sécurité
Références
La Recommandation XML 1.0 [XML] spécifie la syntaxe d’une classe de ressources appelées documents XML. Les espaces de nom dans la Recommandation XML [Names] spécifient une syntaxe et sémantique supplémentaires pour les documents XML. Il est possible que des documents XML qui sont équivalents pour les besoins de nombreuses applications diffèrent dans leur représentation physique. Par exemple, ils peuvent différer par leur structure d’entité, l’ordre de leurs attributs, et le codage des caractères. Le but de la présente spécification est d’établir une méthode pour déterminer si deux documents sont identiques, ou si une application n’a pas changé un document, mises à part les transformations permises par XML 1.0 et Namespaces.
Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" dans le présent document sont à interpréter comme décrit dans la RFC 2119 [Keywords].
Voir dans [Names] la définition de QName.
Un sous–ensemble de document est une portion d’un document XML indiqué par un ensemble-nœud 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 par la méthode décrite dans la présente spécification.
Les changements sont résumés dans la liste suivante :
* Le document est codé en UTF-8
* Les coupures de ligne sont normalisée en #xA en entrée, avant l’analyse
* Les valeurs d’attribut sont normalisées, comme par un processeur de validation
* Les références de caractère et d’entité analysée sont remplacées
* Les sections CDATA sont remplacées par leur contenu de caractère
* La déclaration XML et la déclaration de type de document (DTD) sont retirées
* Les éléments vides sont convertis en paires d’étiquettes début-fin
* L’espace blanche en-dehors de l’élément de document et à l’intérieur des étiquettes de début et de fin est normalisée
* Toutes les espaces dans le contenu de caractère sont conservées (à l’exclusion des caractères retirés durant la normalisation de saut à la ligne)
* Les délimiteurs de valeur d’attribut sont faits avec des guillemets (doubles)
* Les caractères spéciaux dans les valeurs d’attribut et le contenu de caractère sont remplacés par des références de caractère
* Les déclarations d’espace de nom superflues sont retirées de chaque élément
* Des attributs par défaut sont ajoutés à chaque élément
* L’ordre lexicographique est imposé aux déclarations d’espace de nom et aux attributs de chaque élément
Le terme XML canonique se réfère à XML en forme canonique. La méthode de canonisation de XML est l’algorithme défini par la présente spécification qui génère la forme canonique d’un document ou sous-ensemble de document XML donné. Le terme de canonisation XML se réfère au processus d’application de la méthode de canonisation XML à un document ou sous-ensemble de document XML.
La Recommandation XPath 1.0 [XPath] définit le terme ensemble-nœud et spécifie un modèle de données pour représenter un document XML d’entrée comme un ensemble de nœuds de divers types (élément, attribut, espace de nom, texte, commentaire, instruction de traitement, et racine). Les nœuds sont inclus dans, ou exclus de, un ensemble-nœud sur la base de l’évaluation d’une expression. Dans la présente spécification, un ensemble-nœud est utilisé pour indiquer directement si chaque nœud devrait ou non être rendu sous la forme canonique (dans ce sens, il est utilisé comme un ensemble mathématique formel). Un nœud qui est exclu de l’ensemble n’est pas rendu dans la forme canonique générée, même si son nœud parent est inclus dans l’ensemble de nœud. Cependant, un nœud omis a toujours un impact sur le rendu de ses descendants (par exemple, en augmentant le contexte d’espace de nom des descendants).
Comme la Recommandation XML 1.0 [XML] les espaces de nom dans la Recommandation XML [Names] définissent plusieurs méthodes syntaxiques pour exprimer la même information, les applications XML tendent à prendre des libertés avec les changements qui n’ont pas d’impact sur le contenu des informations du document. La canonisation XML est conçue pour être utile aux applications qui exigent la capacité à tester si le contenu des informations d’un document ou sous-ensemble de document a changé. Cela est fait en comparant la forme canonique du document original avant le processus d’application à la forme canonique du document résultant du processus d’application.
Par exemple, une signature numérique sur la forme canonique d’un document XML ou sous-ensemble de document permettrait que les calculs du résumé de signature oublient les changements de la représentation physique du document original, pourvu que les changements soient définis comme logiquement équivalents selon XML 1.0 ou Namespaces dans XML. Durant la génération de la signature, le résumé est calculé sur la forme canonique du document. Le document est alors transféré au consommateur d’assertion, qui valide la signature en lisant le document et en calculant un résumé de la forme canonique du document reçu. L’équivalence des résumés calculés par les parties signataire et consommatrice (et donc l’équivalence des formes canoniques sur lesquelles ils ont été calculés) assure que le contenu d’information du document n’a pas été altéré depuis sa signature.
Deux documents XML peuvent avoir des contenus d’information différents qui sont néanmoins des équivalents logiques au sein d’un contexte d’application donné. Bien que deux documents XML soient équivalents (en laissant de côté les limitations données dans ce paragraphe) si leurs formes canoniques sont identiques, le but de cet ouvrage n’est pas d’établir une méthode qui fasse que deux tels documents XML soient équivalents si et seulement si leurs formes canoniques sont identiques. Une telle méthode est irréalisable, en partie à cause des règles spécifiques de l’application telles que celles qui gouvernent les espaces blanches sans importance et les données équivalentes (par exemple, <couleur>noir</couleur> contre <couleur>rgb(0,0,0)</couleur>). Il y a aussi des équivalences établies par d’autres Recommandations du W3C et des travaux en projet. La prise en compte de ces règles additionnelles d’équivalence sort du domaine d’application du présent ouvrage. Elle peut être effectuée par l’application ou être le sujet de spécifications futures.
La forme canonique d’un document XML peut n’être pas complètement opérationnelle au sein du contexte d’application, bien que les circonstances dans lesquelles cela se produit soient inhabituelles. Ce problème peut être réel dans certaines applications dans la mesure où 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, la forme canonique peut être substituée au document original sans changer le calcul du résumé. Cependant, la risque pour la sécurité ne survient que dans les circonstances inhabituelles décrites ci-dessous, qui peuvent toutes être résolues ou au moins détectées avant la génération de la signature numérique.
Les difficultés surgissent du fait de la perte des informations suivantes, non disponibles dans le modèle de données :
1. URI de base, particulièrement dans un contenu dérivé du texte de remplacement de références d’entité analysée externe générale
2. notations et références d’entité non analysée externe
3. types d’attribut dans la déclaration de type de document
Dans le premier cas, noter qu’un document qui contient un URI relatif [URI] n’est opérationnel que quand il y est accédé à partir d’un URI spécifique qui fournit l’URI de base approprié. De plus, si le document contient des références d’entité générale externe qui ont été analysées comme contenant des URI relatifs, les URI relatifs ne seront pas opérationnels sous la forme canonique, qui remplace la référence d’entité par le contenu interne (changeant implicitement par là l’URI de base par défaut de ce contenu). Ces deux problèmes peuvent normalement être résolus en ajoutant la prise en charge de l’attribut xml:base [XBase] à l’application, puis en ajoutant les attributs xml:base appropriés à l’élément de document et à tous les éléments de niveau supérieur dans les entités externes. De plus, les applications ont souvent l’opportunité de résoudre les URI relatifs avant qu’il soit besoin d’une forme canonique. Par exemple, dans une application de signature numérique, un document est souvent restitué et traité avant la génération de la signature. Le traitement DEVRAIT créer un nouveau document dans lequel les URI relatifs auraient été convertis en URI absolus, diminuant par là tout risque pour la sécurité du nouveau document.
Dans le second cas, la perte de références d’entité externe non analysée et les notations qui les lient aux applications signifie que les formes canoniques ne peuvent pas faire de distinction correcte entre les documents XML qui incorporent des données non analysées via ce mécanisme. C’est un cas qui n’est pas habituel précisément parce que la plupart des processeurs XML éliminent normalement la déclaration de type du document, ce qui élimine la notation, le lien de l’entité à un URI, et le type d’attribut qui lie la valeur d’attribut à un nom d’entité. Pour les documents qui doivent être soumis à plus d’un processeur XML, le concept XML indique normalement une référence à des données non analysées en utilisant un URI dans la valeur d’attribut.
Dans le troisième cas, la perte des types d’attribut peut affecter la forme canonique de différentes façons selon le type. Les attributs de type ID cessent d’être des attributs d’identifiant. Et donc, toute expression XPath qui se réfère à la forme canonique en utilisant la fonction id() cesse de fonctionner. Les types d’attribut ENTITY et ENTITIES ne sont pas dans ce cas ; ils sont couverts par le second cas ci-dessus. Les attributs des types cités et de type ID, IDREF, IDREFS, NMTOKEN, NMTOKENS, et NOTATION ne réussissent pas à être contraints de façon appropriée durant les tentatives ultérieures de changer la valeur d’attribut si la forme canonique remplace la document original durant le processus d’application. Les applications peuvent éviter les difficultés de ce cas en s’assurant qu’une déclaration de type de document appropriée est ajoutée avant d’utiliser la forme canonique dans la suite du traitement XML. Ce sera vraisemblablement une tâche facile car les listes d’attributs sont habituellement acquises auprès d’un sous-ensemble DTD externe standard, et toute déclaration d’entité et de notation qui n’est pas aussi dans le sous-ensemble DTD externe est normalement construite à partir des informations de configuration d’application et ajoutées au sous-ensemble DTD interne.
Bien que ces limitations ne soient pas sévères, 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 sur la base de l’ensemble d’informations XML [Infoset] en cours de développement au W3C.
Le modèle de données défini dans la Recommandation XPath 1.0 [XPath] est utilisé pour représenter le document ou sous-ensemble de document XML d’entrée. Les mises en œuvre DEVRAIENT se fonder sur le développement de XPath, bien que ce ne soit pas exigé. La canonisation XML est définie en termes de définition XPath d’un ensemble-nœud, et les mises en œuvre DOIVENT produire des résultats équivalents.
Le premier paramètre d’entrée de la méthode de canonisation XML est un ensemble-nœud XPath ou un flux d’octets contenant un document XML bien formé. Les mises en œuvre DOIVENT prendre en charge le flux d’octets en entrée et DEVRAIENT aussi prendre en charge le dispositif de sous-ensemble de document via l’entrée d’ensemble-nœud. Pour décrire la canonisation en termes d’ensemble-nœud XPath, ce paragraphe décrit comment un flux d’octet est converti en ensemble-nœud XPath.
Le second paramètre d’entrée de la méthode de canonisation XML est un fanion booléen qui indique si des commentaires devraient ou non être inclus dans le résultat de forme canonique par la méthode de canonisation XML. Si une forme canonique contient des commentaires correspondants aux nœuds commentaires dans l’ensemble-nœud d’entrée, le résultat est appelé XML canonique avec commentaires. Noter que le modèle de données XPath ne crée pas de nœuds commentaire pour les commentaires qui apparaissent au sein de la déclaration de type de document (DTD). Il est EXIGÉ des mises en œuvre qu’elles soient capables de produire le XML canonique en excluant tous les commentaires qui ont pu apparaître dans le document ou sous-ensemble de document d’entrée. La prise en charge de XML canonique avec commentaires est RECOMMANDÉE.
Si un document XML doit être converti en un ensemble-nœud, XPath EXIGE qu’un processeur XML soit utilisé pour créer les nœuds de son modèle de données pour représenter pleinement le document. Le processeur XML effectue dans l’ordre les tâches suivantes :
1. normaliser les coupures de ligne
2. normaliser les valeurs d’attribut
3. remplacer les sections CDATA par leur contenu de caractères
4 résoudre les références de caractère et d’entité analysée
Le flux d’octets d’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 de valeur d’attribut et la résolution de référence d’entité DOIVENT être effectuées en conformité avec les comportements d’un processeur XML de validation. De même, les nœuds pour les attributs par défaut (déclarés dans ATTLIST avec une AttValue mais non spécifiés) sont créés dans chaque élément. Ainsi, la déclaration, dans la déclaration de type de document, est utilisée pour aider à la création de la forme canonique, bien que la déclaration de type de document ne soit pas conservée en forme canonique.
Le modèle de données XPath représente des données qui utilisent les caractères UCS. Les mises en œuvre DOIVENT utiliser des processeurs XML qui acceptent UTF-8 et UTF-16 et traduisent dans le domaine de caractères UCS. Pour UTF-16, la marque de rangement des octets en commençant par la gauche est traitée comme un artifice de codage et enlevée des données de caractères UCS (les espaces insécables de largeur zéro ultérieures qui apparaissent dans les données UTF-16 ne sont pas retirées) [UTF-16, paragraphe 3.2]. L’acceptation du codage ISO-8859-1 est RECOMMANDÉE, et tous les autres codages de caractères sont FACULTATIFS.
Toutes les espaces au sein de l’élément de document racine DOIVENT être préservées (excepté les caractères #xD supprimés par la normalisation de délimiteur de ligne). Cela inclut toutes les espaces dans les entités externes. Les espaces en dehors d’un élément de document racine DOIVENT être éliminées.
Dans le modèle de données XPath, il existe les types de nœud suivants : racine, élément, commentaire, instruction de traitement, texte, attribut et espace de nom. Il existe un seul nœud racine dont les enfants sont les nœuds d’instruction de traitement et les nœuds de commentaires pour représenter les informations en-dehors de l’élément de document (et en-dehors de la déclaration de type de document). Le nœud racine a aussi un seul nœud d’élément qui représente l’élément de document de niveau supérieur. Chaque nœud d’élément peut avoir des nœuds fils de l’élément type, texte, instruction de traitement, et commentaire. Les attributs et espaces de nom associés à un élément ne sont pas considérés comme des nœuds fils de l’élément, mais sont associés à l’élément par inclusion dans les axes d’attribut et d’espace de nom de l’élément. Noter que les axes d’attribut et d’espace de nom peuvent ne pas correspondre directement au texte qui apparaît dans l’étiquette de début de l’élément dans le document original.
Note : Un élément a des nœuds d’attribut pour représenter les déclarations d’attribut de non espace de nom qui apparaissent dans son étiquette de début ainsi que des nœuds pour représenter les attributs par défaut.
Grâce au modèle de données XPath, la canonisation XML est avertie des espaces de nom [Names]. Cependant, elle ne peut pas et en conséquence ne tient pas compte des équivalences d’espace de nom qui utilisent la réécriture de préfixe d’espace de nom (voir l’explication à la Section 4). Dans le modèle de données XPath, chaque élément et attribut a un nom qui est retourné par la fonction name() qui peut, à la discrétion de l’application, être le QName qui apparaît dans le document original. La canonisation XML EXIGE que le processeur XML conserve suffisamment d’informations pour que le QName de l’élément puisse être fourni comme il apparaissait dans le document original.
Note : Un élément E a des nœuds d’espace de nom qui représentent ses déclarations d’espace de nom ainsi que toutes déclarations d’espace de nom faites par ses ancêtres qui n’ont pas été écrasées dans les déclarations de E, l’espace de nom par défaut s’il n’est pas vide, et la déclaration du préfixe xml.
Note non normative : La présente spécification soutient la décision de la récente réunion plénière de XML de déconseiller les URI relatifs d’espace de nom comme suit : les mises en œuvre de canonisation XML DOIVENT rapporter un échec d’opération sur les documents qui contiennent des URI relatifs d’espace de nom. La canonisation XML NE DOIT PAS être mise en œuvre avec un analyseur XML qui convertit les URI relatifs en URI absolus.
Le contenu de caractère est représenté dans le modèle de données XPath avec les nœuds de texte. Tous les caractères consécutifs sont placés dans un seul nœud de texte. De plus, les caractères du nœud de texte sont représentés dans le domaine de caractères UCS. La méthode de canonisation XML n’effectue pas de normalisation de modèle de caractère (voir l’explication à la Section 4). Cependant, il est EXIGÉ que le processeur XML utilisé pour préparer l’entrée de modèle de données XPath utilise la forme de normalisation C [NFC, NFC-Corrigendum] lors de la conversion d’un document XML dans le domaine de caractères UCS à partir de tout codage qui n’est pas fondé sur UCS (actuellement, les codages fondés sur UCS incluent UTF-8, UTF-16, UTF-16BE, et UTF-16LE, UCS-2, et UCS-4).
Comme la canonisation XML convertit un ensemble-nœud XPath en une forme canonique, le premier paramètre DOIT être un ensemble-nœud XPath ou il doit être converti d’un flux d’octets en un ensemble-nœud en effectuant le traitement XML nécessaire pour créer les nœuds XPath décrits ci-dessus, puis en établissant un contexte d’évaluation XPath initial de :
* Un nœud de contexte, initialisé au nœud racine du document XML d’entrée.
* Une position de contexte, initialisée à 1.
* Une taille de contexte, initialisée à 1.
* Toute bibliothèque de fonctions se conformant à la Recommandation XPath.
* Un ensemble vide de liaisons variables.
* Un ensemble vide de déclarations d’espaces de nom.
et évaluant l’expression par défaut suivante :
Valeur de paramètre de commentaire |
Expression XPath par défaut |
Sans (faux) : |
(//. | //@* |//namespace::*)[not(self::comment())] |
Avec (vrai): |
(//. | //@* | //namespace::*) |
Les expressions de ce tableau génèrent un ensemble-nœud qui contient chaque nœud du document XML (excepté les commentaires si la valeur de paramètre de commentaire est faux).
Si l’entrée est un ensemble-nœud XPath, l’ensemble-nœud doit explicitement contenir chaque nœud à mettre en forme canonique. Par exemple, le résultat de l’expression XPath id("E") est un ensemble-nœud qui ne contient que le nœud correspondant à l’élément ayant une valeur d’attribut d’identifiant de "E". Comme aucun des ses nœuds descendants, des nœuds d’attribut et des nœuds d’espace de nom, n’est dans l’ensemble, la forme canonique comporterait seulement les étiquettes de début et de fin de l’élément, moins les déclarations d’attribut et d’espace de nom, sans contenu interne. Le paragraphe 3.7 donne un exemple de la façon de mettre en série un élément identifié avec son contenu interne et ses déclarations d’attributs et d’espace de nom.
Bien qu’un ensemble-nœud XPath soit défini comme non ordonné, la Recommandation XPath 1.0 [XPath] définit le terme ordre de document comme l’ordre dans lequel le premier caractère de la représentation XML de chaque nœud survient dans la représentation XML du document après l’expansion des entités générales, excepté les nœuds d’espace de nom et d’attribut dont l’ordre du document dépend de l’application.
La méthode de canonisation XML traite un ensemble-nœud en imposant les règles supplémentaires d’ordre de document suivantes sur les nœuds d’espace de nom et d’attribut de chaque élément :
* Les nœuds d’espace de nom et d’attribut d’un élément ont une position d’ordre de document plus grande que l’élément mais inférieure à tout nœud fils de l’élément.
* Les nœuds d’espace de nom ont une position d’ordre de document inférieure aux nœuds d’attribut.
* Les nœuds d’espace de nom d’un élément sont triés lexicographiquement par nom local (le nœud d’espace de nom par défaut, s’il en existe un, n’a pas de nom local et est donc le dernier dans l’ordre lexicographique).
* Les nœuds d’attribut d’un élément sont triés lexicographiquement par URI d’espace de nom comme clé primaire et par nom local comme clé secondaire (un URI d’espace de nom vide est le dernier dans l’ordre lexicographique).
La comparaison lexicographique, qui ordonne les chaînes dans l’ordre alphabétique de la plus faible valeur à la plus grande, se fonde sur les valeurs du codet UCS, qui sont équivalentes à l’ordre lexicographique fondé sur UTF-8.
L’ensemble-nœud XPath est converti en un flux d’octets, de forme canonique, en générant les caractères UCS représentatifs pour chaque nœud dans l’ensemble-nœud en ordre de document ascendant, puis en codant le résultat en UTF-8 (sans marque d’ordre des octets en commençant par la gauche). Aucun nœud n’est traité plus d’une fois. Noter que le traitement d’un nœud d’élément E inclut le traitement de tous les membres de l’ensemble-nœud pour lequel E est un ancêtre. Donc, directement après la génération du texte représentatif de E, E et tous les nœuds pour lesquels E est un ancêtre sont retirés de l’ensemble-nœud (ou une opération logiquement équivalente survient de telle sorte que le prochain nœud de l’ensemble-nœud dans l’ordre du document n’ait pas été traité). Noter cependant, qu’un nœud d’élément n’est pas retiré de l’ensemble-nœud jusqu’à ce que ses enfants soient traités.
Le résultat du traitement d’un nœud dépend de son type et de s’il est ou non dans l’ensemble-nœud. Si un nœud n’est pas dans l’ensemble-nœud, aucun texte n’est alors généré pour le nœud sauf pour le résultat du traitement de ses axes d’espace de nom et d’attribut (seulement les éléments) et de ses enfants (éléments et nœud racine). Si le nœud est dans l’ensemble-nœud, du texte est alors généré pour représenter le nœud sous forme canonique en plus du texte généré par le traitement des axes d’espace de nom et d’attribut du nœud et des nœuds fils.
Note : L’ensemble-nœud est traité comme un ensemble de nœuds, et non comme une liste de sous-embranchements. Pour canoniser un élément comportant ses espaces de nom, ses attributs, et son contenu, l’ensemble-nœud doit en réalité contenir tous les nœuds correspondants à ces parties du document, et non juste le nœud d’élément.
Le texte généré pour un nœud dépend du type du nœud et est donné dans la liste suivante :
* Nœud racine – C’est le parent de l’élément de document de niveau supérieur. Le résultat du traitement de chacun de ses nœuds fils est dans l’ensemble-nœud dans l’ordre du document. Le nœud racine ne génère pas de marque d’ordre des octets, de déclaration XML, ni rien qui provienne de l’intérieur de la déclaration de type de document.
* Nœuds d’élément – Si l’élément n’est pas dans l’ensemble-nœud, le résultat est alors obtenu en traitant l’axe d’espace de nom, puis l’axe des attributs, puis les nœuds fils des élément qui sont dans l’ensemble-nœud (dans l’ordre du document). Si l’élément est dans l’ensemble-nœud, le résultat est alors un crochet angulaire ouvert (<), le QName de l’élément, le résultat du traitement de l’axe d’espace de nom, le résultat du traitement de l’axe des attributs, un crochet angulaire fermé (>), le résultat du traitement des nœuds fils de l’élément qui sont dans l’ensemble-nœud (dans l’ordre du document), un crochet angulaire ouvert, une barre oblique (/), le QName de l’élément, et un crochet angulaire fermé.
*
o Axe des espaces de nom – Considérons une liste L ne contenant que les nœuds d’espace de nom dans l’axe et dans l’ensemble-nœud en ordre lexicographique (ascendant). Pour commencer le traitement de L, si le premier nœud n’est pas le nœud d’espace de nom par défaut (un nœud sans URI d’espace de nom et sans nom local), générons un espace suivi de xmlns="" si et seulement si les conditions suivantes sont satisfaites :
+ L’élément E qui possède l’axe est dans l’ensemble-nœud
+ Le plus proche élément ancêtre de E dans l’ensemble-nœud a un nœud d’espace de nom par défaut dans l’ensemble-nœud (les nœuds d’espace de nom par défaut ont toujours des valeurs non vides dans XPath).
La dernière condition élimine les occurrences superflues de xmlns="" dans la forme canonique car un élément ne reçoit qu’un xmlns="" si son espace de nom par défaut est vide et si il a un parent immédiat en forme canonique qui a un espace de nom par défaut non vide. Pour finir le traitement de L, traiter simplement chaque nœud d’espace de nom de L, sauf à omettre les nœuds d’espace de nom avec le nom local xml, qui définit le préfixe xml, si sa valeur de chaîne est http://www.w3.org/XML/1998/namespace.
o Axe des attributs – En ordre lexicographique (ascendant), traiter chaque nœud qui est dans l’axe des attributs de l’élément et dans l’ensemble-nœud.
* Nœuds d’espace de nom – Un nœud d’espace de nom N est ignoré si l’élément ancêtre le plus proche de l’élément parent du nœud qui est dans l’ensemble-nœud a un nœud d’espace de nom dans l’ensemble-nœud avec le même nom local et la même valeur que N. Autrement, traiter le nœud d’espace de nom N de la même façon qu’un nœud d’attribut, sauf à allouer le nom local xmlns au nœud d’espace de nom par défaut s’il existe (en XPath, le nœud d’espace de nom par défaut a un URI et un nom local vides).
* Nœuds d’attributs – une espace, le QName du nœud, un signe égal, un guillemet ouvert (double guillemet), la valeur de chaîne modifiée, et un guillemet fermé (double guillemet). La valeur de chaîne du nœud est modifiée en remplaçant tous les caractères éperluettes (&) par &, tous les crochets angulaires ouverts (<) par <, tous les guillemets (double guillemets) par ", et les caractères espace blanche #x9, #xA, et #xD, par des références de caractère. Les références de caractère sont écrites en hexadécimal majuscules sans zéros en tête (par exemple, #xD est représenté par la référence de caractère 
).
* Nœuds de texte – la valeur de la chaîne, sauf que toutes les éperluettes sont remplacées par &, tous les crochets angulaires ouverts (<) sont remplacés par <, tous les crochets angulaires fermés (>) sont remplacés par >, et tous les caractères #xD sont remplacés par 
.
* Nœuds d’instruction de traitement (PI) – Le symbole d’ouverture de PI (<?), le nom de cible PI du nœud, une espace en tête et la valeur de la chaîne si elle n’est pas vide, et le symbole de fermeture de PI (?>). Si la valeur de la chaîne est vide, l’espace en tête n’est alors pas ajoutée. Aussi, un #xA en queue est rendu après le symbole de fermeture de PI pour les PI fils du nœud racine avec un ordre de document inférieur à l’élément de document, et un #xA en tête est rendu avant le symbole d’ouverture de PI de la PI fils du nœud racine avec un ordre de document supérieur à l’élément de document.
* Nœud de commentaire – Rien si on génère du XML canonique sans commentaire. Pour le XML canonique avec commentaire, générer le symbole d’ouverture de commentaire (<!--), la valeur de la chaîne pour le nœud, et le symbole de clôture de commentaire (-->). Aussi, un #xA en queue est rendu après le symbole de clôture de commentaire pour commenter les fils du nœud racine avec un ordre de document inférieur à l’élément de document, et un #xA en tête est rendu avant le symbole d’ouverture de commentaire des commentaires fils du nœud racine avec un ordre de document supérieur à l’élément de document. (Les commentaires fils du nœud racine représentent des commentaires en-dehors de l’élément de document de niveau supérieur et en dehors de la déclaration de type de document.)
Le QName d’un nœud est soit le nom local si la chaîne de préfixe d’espace de nom est vide, soit le préfixe d’espace de nom, deux points, puis le nom local de l’élément. Le préfixe d’espace de nom utilisé dans le QName DOIT être le même que celui qui apparaît dans le document d’entrée.
Certaines applications exigent la capacité à créer une représentation physique pour un sous-ensemble de document XML (autre que celui généré par défaut, qui peut être un sous-ensemble approprié du document si les commentaires sont omis). Les mises en œuvre de canonisation XML qui se fondent sur XPath peuvent fournir cette fonctionnalité avec peu de redondance supplémentaire en acceptant un ensemble-nœud en entrée plutôt qu’un flux d’octets.
Le traitement d’un nœud d’élément E DOIT être légèrement modifié lorsqu’un ensemble-nœud XPath est donné comme entrée et que le parent de l’élément est omis de l’ensemble-nœud. La méthode de traitement de l’axe d’attribut d’un élément E dans l’ensemble-nœud est améliorée. Tous les nœuds d’élément le long de l’axe ancêtre de E sont examinés à la recherche des plus proches occurrences d’attributs dans l’espace de nom xml, comme xml:lang et xml:space (qu’ils soient ou non dans l’ensemble-nœud). D’après la liste des attributs, retirer tous ceux qui sont sur l’axe des attributs de E (qu’ils soient ou non dans l’ensemble-nœud). Puis fusionner lexicographiquement cette liste d’attributs avec les nœuds de l’axe des attributs de E qui sont dans l’ensemble-nœud. Le résultat de la visite de l’axe des attributs est calculé en traitant les nœuds d’attribut dans cette liste d’attributs fusionnée.
Note : Les entités XML peuvent déduire une signification spécifique de l’application à partir de tout endroit du balisage XML aussi bien que de règles non exprimées dans XML 1.0 et les Recommandations Namespaces. Il est clair que ces règles ne peuvent pas être spécifiées dans le présent document, aussi le créateur de l’ensemble-nœud d’entrée doit il être responsable de la préservation des informations nécessaires à la capture de la sémantique complète des membres de l’ensemble-nœud 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 n’être pas bien formée en XML. Cependant, comme la forme canonique peut être soumise à un traitement XML ultérieur, la plupart des ensembles-nœuds XPath présentés à la canonisation seront conçus de façon à produire une forme canonique qui soit un document XML bien formé ou une entité externe analysée générale. Qu’elle soit d’un document ou d’un sous-ensemble de document, si la forme canonique est du XML bien formé, les applications ultérieures de la même méthode de canonisation XML à la forme canonique ne provoqueront alors aucun changement.
Les exemples de la présente section supposent un processeur non validant, principalement afin qu’une déclaration de type de document puisse être utilisée pour déclarer des entités aussi bien que des attributs par défaut et des attributs de divers types (comme des identifiants et des énumérations) sans avoir à déclarer tous les attributs pour tous les éléments du document. Un exemple contient aussi un élément qui viole délibérément une contrainte de validité (parce qu’elle est quand même bien formée).
Document d’entrée
<?xml version="1.0"?>
<?xml-stylesheet href="doc.xsl" type="text/xsl" ?>
<!DOCTYPE doc SYSTEM "doc.dtd">
<doc>Hello, world!<!-- Comment 1 --></doc>
<?pi-without-data ?>
<!-- Comment 2 -->
<!-- Comment 3 -->
Forme canonique (sans commentaire)
<?xml-stylesheet href="doc.xsl" type="text/xsl" ?>
<doc>Hello, world!</doc>
<?pi-without-data?>
Forme canonique (avec commentaire)
<?xml-stylesheet href="doc.xsl" type="text/xsl" ?>
<doc>Hello, world!<!-- Comment 1 --></doc>
<?pi-without-data?>
<!-- Comment 2 -->
<!-- Comment 3 -->
Démontre :
* La perte de la déclaration XML.
* La perte de DTD.
* La normalisation d’espace blanche en-dehors de l’élément de document (le premier caractère des deux formes canoniques est '<'; une seule coupure de ligne sépare les PI et les commentaires en-dehors de l’élément de document).
* La perte des espaces blanches entre en PITarget (cible des instructions de traitement) et ses données.
* La rétention des espaces blanches à l’intérieur des données d’instruction de traitement.
* Suppression des commentaires pour la forme canonique sans commentaire, incluant le délimiteur pour les commentaires en-dehors de l’élément de document (le dernier caractère dans les deux formes canoniques est '>')
Document d’entrée
<doc>
<clean> </clean>
<dirty> A B </dirty>
<mixed>
A
<clean> </clean>
B
<dirty> A B </dirty>
C
</mixed>
</doc>
Forme canonique
<doc>
<clean> </clean>
<dirty> A B </dirty>
<mixed>
A
<clean> </clean>
B
<dirty> A B </dirty>
C
</mixed>
</doc>
Démontre :
* Conserve toutes les espaces blanches entre les étiquettes de début consécutives, clean ou dirty.
* Conserve toutes les espaces blanches entre les étiquettes de fin consécutives, clean ou dirty.
* Conserve toutes les espaces blanches entre les paires d’étiquettes de début/fin, clean ou dirty
* Conserve toutes les espaces blanches en contenu de caractère, clean ou dirty.
Note : Dans cet exemple, le document d’entrée et la forme canonique sont identiques. Tous deux se terminent par la caractère '>'.
Document d’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="out" b:attr="sorted" attr2="all" attr="I'm" xmlns:b="http://www.ietf.org" xmlns:a="http://www.w3.org"
xmlns="http://example.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://example.org" xmlns:a="http://www.w3.org" xmlns:b="http://www.ietf.org" attr="I'm" attr2="all"
b:attr="sorted" a:attr="out"></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>
Démontre :
* La conversion d’élément vide en paire d’étiquettes début-fin.
* La normalisation des espaces blanches dans les étiquettes de début et de fin.
* L’ordre relatif des axes d’espace de nom et d’attribut.
* L’ordre lexicographique des axes d’espace de nom et d’attribut.
* La rétention des préfixes d’espace de nom du document d’origine.
* L’élimination des déclarations d’espace de nom superflues.
* L’ajout de l’attribut par défaut.
Note : Certaines étiquettes de début dans la forme canonique sont très longues, mais chaque étiquette de début de cet exemple tient entièrement sur une seule ligne.
Note : En e5, b:attr précède a:attr parce que la principale clé est l’URI d’espace de nom et non le préfixe d’espace de nom, et attr2 précède b:attr parce que l’espace de nom par défaut n’est pas appliqué à des attributs non qualifiés (de sorte que l’URI d’espace de nom pour attr2 est vide).
Document d’entrée
<!DOCTYPE doc [
<!ATTLIST normId id ID #IMPLIED>
<!ATTLIST normNames attr NMTOKENS #IMPLIED>
]>
<doc>
<text>First line
 Second line</text>
<value>2</value>
<compute><![CDATA[value>"0" && value<"10" ?"valid":"error"]]>
</compute>
<compute expr='value>"0" && value<"10" ?"valid":"error"'>valid</compute>
<norm attr=' '   
	 ' '/>
<normNames attr=' A   
	 B '/>
<normId id=' '   
	 ' '/>
</doc>
Forme canonique
<doc>
<text>First line
 Second line</text>
<value>2</value>
<compute>value>"0" && value<"10" ?"valid":"error"
</compute>
<compute expr="value>"0" && value<"10" ?" valid":"error"">valid</compute>
<norm attr=" ' 
	 ' "></norm>
<normNames attr="A 
	 B"></normNames>
<normId id="' 
	 '"></normId>
</doc>
Démontre :
* Le remplacement de la référence de caractère.
* Le réglage des délimiteurs de valeur d’attribut à des guillemets (double guillemets).
* La normalisation de la valeur d’attribut.
* Le remplacement de la section CDATA.
* Le codage des caractères spéciaux en références de caractères dans les valeurs d’attribut (&, <, ", 
, 
, 	).
* Le codage des caractères spéciaux en références de caractères dans le texte (&, <, >, 
)
Note : Le dernier élément, normId, est bien formé mais viole une contrainte de validité des identifiants de type des attributs. Pour tester les mises en œuvre d’XML canonique fondées sur les processeurs de validation, retirer la ligne qui contient cet élément de l’entrée et de la forme canonique. En général, on déconseille aux consommateurs de XML d’utiliser cette caractéristique de XML.
Note : Les références de caractères d’espace blanche autres que   ne sont pas affectées par la normalisation de valeur d’attribut [XML].
Note : Dans la forme canonique, la valeur de l’attribut nommé attr dans la norme d’élément commence par une espace, un guillemet simple, puis quatre espaces avant la première référence de caractère.
Note : L’attribut expr du second élément compute ne contient pas de coupure de ligne.
Document d’entrée
<!DOCTYPE doc [
<!ATTLIST doc attrExtEnt ENTITY #IMPLIED>
<!ENTITY ent1 "Hello">
<!ENTITY ent2 SYSTEM "world.txt">
<!ENTITY entExt SYSTEM "earth.gif" NDATA gif>
<!NOTATION gif SYSTEM "viewgif.exe">
]>
<doc attrExtEnt="entExt">
&ent1;, &ent2;!
</doc>
<!—Posons que world.txt contient "world" (en excluant les guillemets) -->
Forme canonique (sans commentaire)
<doc attrExtEnt="entExt">
Hello, world!
</doc>
Démontre :
* Le remplacement de référence d’entité analysée interne.
* Le remplacement de référence d’entité analysée externe (y compris d’espace blanches en-dehors des éléments et PI).
* Les références d’entité non analysée externe.
Document d’entrée
<?xml version="1.0" encoding="ISO-8859-1"?>
<doc>©</doc>
Forme canonique
<doc>#xC2#xA9</doc>
Démontre :
* l’effet du transcodage d’un codage d’échantillon en UTF-8.
Note : 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, qui sont le codage UTF-8 du codet UCS pour le symbole copyright (c).
Document d’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 de document
(//. | //@* | //namespace::*)
[ <br/>
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>
Démontre :
* Propagation de l’espace de nom vide par défaut à partir de l’élément parent omis.
* Propagation des attributs dans l’espace de nom xml dans les sous-ensembles de document.
* Persistance de l’omission des déclarations d’espace de nom chez les descendants.
Note : Dans l’expression du sous-ensemble de document, la sous-expression (//. | //@* | //namespace::*) sélectionne tous les nœuds dans le document d’entrée, soumettant chacun à l’expression du prédicat entre crochets. L’expression est vraie pour e1 et ses nœuds implicites d’espace de nom, et elle est vraie si l’élément identifié par E3 est dans le chemin ancestor-or-self du nœud de contexte (tel que ancestor-or-self reste de la même taille dans l’union avec l’élément identifié par E3).
Note : La forme canonique ne contient pas de délimiteur de ligne.
La présente section expose un certain nombre de points de décision ainsi que les raisons de chaque décision. Bien que la présente spécification définisse la canonisation XML en termes de modèle de données XPath plutôt que d’Infoset XML, la forme canonique décrite dans le présent document est assez similaire sous la plupart des aspects à la forme canonique décrite dans le projet d’XML canonique de janvier 2000 [C14N-20000119]. Cependant, il existe quelques différences, et les paragraphes exposent ces changements.
La déclaration XML, y compris le numéro de version et le codage des caractères est omise dans la forme canonique. Le codage n’est pas nécessaire car la forme canonique est codée en UTF-8. La version n’est pas nécessaire car l’absence de numéro de version indique sans ambiguïté XML 1.0.
Les futures versions de XML exigeront l’inclusion d’une déclaration XML pour indiquer le numéro de version. Cependant, la méthode de canonisation décrite dans la présente spécification pourrait n’être pas applicable aux futures versions de XML sans quelques modifications. Lorsque la canonisation d’une nouvelle version de XML sera nécessaire, la présente spécification pourra être mise à jour pour inclure la déclaration XML car on peut supposer qu’on saura à ce moment remédier à l’absence de la déclaration XML dans le modèle de données XPath (par exemple, en produisant un nouvel XPath sur la base du modèle de données Infoset).
La norme Unicode [Unicode] permet plusieurs représentations différentes de certains "caractères précomposés" (un exemple est +U00E7, "LETTRE LATINE C MINUSCULE AVEC CEDILLE"). Et donc deux documents XML avec un contenu équivalent pour les besoins 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]. Le projet XML canonique C14N-20000119 utilise cette forme normalisée. Cependant, de nombreux processeurs XML 1.0 n’effectuent pas cette normalisation. De plus, des applications qui doivent résoudre ce problème mettent normalement en application la normalisation de modèle de caractère toutes les fois qu’elles démarrent lorsque le contenu de caractère est créé afin d’éviter les défaillances de traitement qui en résulteraient autrement (par exemple, voir celui de Cowan). Donc la normalisation de modèle de caractère a été retirée du domaine d’application de la canonisation XML. Cependant, le processeur XML utilisé pour préparer l’entrée du modèle de données XPath doit nécessairement (d’après le modèle de données) utiliser la forme C de normalisation [NFC, NFC-Corrigendum] lors de la conversion d’un document XML au domaine de caractères UCS à partir de tout codage non fondé sur UCS (actuellement, les codages fondés sur UCS incluent UTF-8, UTF-16, UTF-16BE, UTF-16LE, UCS-2, et UCS-4).
Le projet de XML canonique C14N-20000119 plaçait un #xA après chaque PI en-dehors de l’élément de document ainsi qu’un #xA après l’étiquette de fin de l’élément de document. La méthode de la présente spécification effectue la même fonction excepté l’omission du #xA final après la dernière PI (ou commentaire ou étiquette de fin de l’élément de document). Cette technique garantit que la PI (et commentaire) fille de la racine est séparée du balisage par une coupure de ligne même si le nœud racine ou l’élément de document sont omis de l’ensemble-nœud de sortie.
Le projet de XML canonique C14N-20000119 décrivait une méthode de réécriture des préfixes d’espace de nom telle que deux documents ayant des déclarations d’espace de nom logiquement équivalentes auraient aussi des préfixes d’espace de nom identiques. L’objectif était d’éliminer la dépendance envers les préfixes d’espace de nom particuliers dans un document lors de la recherche d’équivalences logiques. Cependant, il existe maintenant un certain nombre de contextes dans lesquels les préfixes d’espace de nom peuvent transmettre une valeur d’information dans un document XML. Par exemple, une expression XPath dans une valeur d’attribut ou contenu d’élément peut faire référence à un préfixe d’espace de nom. Et donc la réécriture des préfixes d’espace de nom endommagerait un tel document en changeant sa signification (et il ne peut plus être logiquement équivalent si sa signification a changé).
De façon plus formelle, soit D1 un document contenant un XPath dans une valeur d’attribut ou de contenu d’élément qui se réfère à des préfixes d’espace de nom utilisés en D1. Supposons de plus que les préfixes d’espace de nom dans D1 seront tous réécrits par la méthode de canonisation. Soit D23D D1, puis modifions les préfixes d’espace de nom dans D2 et modifions les références de l’expression XPath en préfixes d’espace de nom de telle sorte que D2 et D1 restent logiquement équivalents. Comme la réécriture d’espace de nom n’inclut pas les occurrences de référence d’espace de nom dans les valeurs d’attribut et les contenus d’élément, la forme canonique de D1 n’est pas égale à la forme canonique de D2 parce que le XPath sera différent. Et donc, bien que la réécriture d’espace de nom normalise les déclarations d’espace de nom, l’objectif d’éliminer la dépendance envers les préfixes d’espace de nom particuliers dans le document n’est pas atteint.
De plus, il est possible de prouver que la réécriture d’espace de nom est dommageable, plus que simplement inefficace. Soit D1 un document contenant un XPath dans une valeur d’attribut ou contenu d’élément qui se réfère à des préfixes d’espace de nom utilisés en D1. Supposons de plus que les préfixes d’espace de nom en D1 seront tous réécrits par la méthode de canonisation. Soit maintenant D2 la forme canonique de D1. Il est clair que les formes canoniques de D1 et D2 sont équivalentes (car D2 est la forme canonique de la forme canonique de D1), et pourtant D1 et D2 ne sont pas logiquement équivalents parce que le XPath susmentionné fonctionne dans D1 et pas dans D2.
Noter qu’un argument similaire peut être avancé contre la méthode de canonisation XML fondée sur n’importe lequel des cas de la section Limitations, et les problèmes ne peuvent pas être réglés facilement dans ces cas, tandis qu’ici, nous avons une opportunité d’éviter délibérément d’introduire une telle limitation.
Les applications qui doivent tester les équivalences logiques doivent effectuer des essais plus sophistiqués que la simple comparaison de flux d’octet. Cependant, il est très vraisemblablement nécessaire dans tous les cas afin de tester les équivalences logiques sur la base des règles d’application ainsi que des règes provenant des autres recommandations qui se rapportent à XML, projets en cours et travaux futurs.
Le projet de XML canonique C14N-20000119 alternait entre déclarations d’espace de nom et déclarations d’attribut. Cela fait partie du schéma de réécriture du préfixe d’espace de nom, que la présente spécification élimine. Elle suit le modèle de données XPath qui met tous les nœuds d’espace de nom avant les nœuds d’attribut.
Les déclarations d’espace de nom superflues ne sont pas faites dans la forme canonique. Que ce soit pour un espace de nom vide par défaut, un espace de nom non vide par défaut ou un line de préfixe d’espace de nom, la méthode de canonisation XML omet une déclaration si elle détermine que l’élément parent immédiat dans la forme canonique a une déclaration équivalente dans sa portée. l’élément de document racine est traité de façon particulière car il n’a pas d’élément parent. Toutes les déclarations d’espace de nom qu’il contient sont conservées, excepté la déclaration d’un espace de nom vide par défaut qui est automatiquement omise.
Au sujet de la méthode de simple rendu du contexte d’espace de nom tout entier de chaque élément, les mises en œuvre ne sont pas entravées par plus d’un facteur constant dans le temps de traitement et l’utilisation de la mémoire. Les avantages en sont :
* d’éliminer les invasions de xmlns="" à partir des formes canoniques d’applications qui peuvent n’utiliser même pas d’espaces de nom, ou ne les prendre en charge que de façon minimale,
* d’éliminer les déclarations d’espace de nom d’éléments où ils n’ont rien à faire conformément au modèle de contenu de l’application, simplifiant par là la tâche de rattachement d’une déclaration de type de document à une forme canonique.
Noter que dans les sous-ensembles de document, un élément avec des omissions de sa chaîne d’éléments ancêtres sera rendue à la forme canonique avec des déclarations d’espace de nom qui peuvent avoir été faites dans ses ancêtres omis, préservant donc ainsi la signification de l’élément.
Le modèle de données XPath représente un espace de nom vide par défaut avec une absence de nœud, et non avec la présence d’un nœud d’espace de nom par défaut qui a une valeur vide. Et donc, par rapport au fait que l’élément e3 dans les exemples suivants n’est pas qualifié comme espace de nom, on ne peut pas dire 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 l’on sait est que e3 n’a pas d’espace de nom qualifié en entrée, aussi préserve t-on cette information en sortie si e2 est omis de sorte que e3 ne prend pas la qualification d’espace de nom par défaut de e1.
Étant donnée l’exigence de préservation des préfixes d’espace de nom déclarés dans un document, le tri des attributs par préfixes plutôt que par URI d’espace de nom, comme clé principale, est viable et plus facile à mettre en œuvre.
Cependant, l’URI d’espace de nom a été choisi comme clé principale parce que c’est plus proche des intentions de la spécification Names de XML, qui est d’identifier les espaces de nom par URI et nom local, et non par préfixe et nom local. L’effet du tri est de grouper ensemble tous les attributs qui sont dans le même espace de nom.
Les questions de sécurité sont exposées au paragraphe 1.3.
[C14N-20000119] Canonical XML Version 1.0, W3C Working Draft. T. Bray, J. Clark, J. Tauber, et J. Cowan. 19 janvier 2000. http://www.w3.org/TR/2000/WD-xml-c14n-20000119.html .
[CharModel] Working Draft. éd. : Martin J. Durst, Francois Yergeau, Misha Wolf, Asmus Freytag, Tex Texin. http://www.w3.org/TR/charmod/ .
[Cowan] Example of Harmful Effect of Character Model Normalization, Lettre dans XML Signature Working Group Mail Archive. John Cowan, 7 juillet 2000. http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0038.html .
[Infoset] XML Information Set, W3C Working Draft. John Cowan, Richard Tobin. http://www.w3.org/TR/xml-infoset
[ISO-8859-1] ISO-8859-1 Latin 1 Character Set. http://www.utoronto.ca/webdocs/HTMLdocs/ NewHTML/iso_table.html ou http://www.iso.ch/cate/cat.html .
[Keywords] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d’exigence", BCP 14, RFC 2119, mars 1997.
[Namespaces] Namespaces in XML, W3C Recommendation. éd. : Tim Bray, Dave Hollander et Andrew Layman. http://www.w3.org/TR/REC-xml-names/
[NFC] TR15, Unicode Normalization Forms. M. Davis, M. Durst. Revision 18: novembre 1999. http://www.unicode.org/unicode/reports/tr15/tr15-18.html .
[NFC-Corrigendum] NFC-Corrigendum. The Unicode Consortium. http://www.unicode.org/unicode/uni2errata/Normalization_Corrigendum.html .
[Unicode] The Unicode Standard, version 3.0. The Unicode Consortium. ISBN 0-201-61633-5. http://www.unicode.org/unicode/standard/versions/Unicode3.0.html .
[UTF-16] P. Hoffman et F. Yergeau, "UTF-16, un codage de ISO 10646", RFC 2781, février 2000.
[UTF-8] F. Yergeau, "UTF-8, un format de transformation de ISO 10646", RFC 2279, janvier 1998.
[URI] T. Berners-Lee, R. Fielding et L. Masinter, "Identifiants de ressource universels (URI) :Syntaxe générique", RFC 2396, août 1998.
[XBase] XML Base. éd. : Jonathan Marsh. 07 juin 2000. http://www.w3.org/TR/xmlbase/ .
[XML] Extensible Markup Language (XML) 1.0 (Seconde édition), W3C=20 Recommendation. éd. : Tim Bray, Jean Paoli, C. M. Sperberg-McQueen et Eve Maler. 6 octobre 2000. http://www.w3.org/TR/REC-xml .
[XML DSig] D. Eastlake, J. Reagle et D. Solo, "Syntaxe et traitement de signature XML", RFC 3075, juillet 2000.
[XML Plenary Decision] W3C XML Plenary Decision on relative URI References dans namespace declarations, Document W3C. 11 septembre 2000. http://lists.w3.org/Archives/Public/xml-uri/2000Sep/0083.html .
[XPath] XML Path Language (XPath) Version 1.0, , W3C Recommendation. éd. : James Clark et Steven DeRose. 16 novembre 1999. http://www.w3.org/TR/1999/REC-xpath-19991116 .
Adresse de l’auteur
John Boyer
PureEdge Solutions Inc.
téléphone : 1-888-517-2675
mél : jboyer@PureEdge.com
Remerciements
Les personnes suivantes ont fourni des commentaires précieux qui ont amélioré la qualité de cette spécification :
* Doug Bunting, Ariba
* John Cowan, Reuters
* Martin J. Durst, W3C
* Donald Eastlake 3rd, Motorola
* Merlin Hughes, Baltimore
* Gregor Karlinger, IAIK TU Graz
* Susan Lesch, W3C
* Jonathan Marsh, Microsoft
* Joseph Reagle, W3C
* Petteri Stenius, Done360
* Kent Tamura, IBM
Déclaration de Copyright
Copyright (C) The Internet Society (2001).
Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.
Le présent document et les informations y contenues sont fournies sur une base "EN L’ÉTAT" et LE CONTRIBUTEUR, L’ORGANISATION QU’IL OU ELLE REPRÉSENTE OU QUI LE/LA FINANCE (S’IL EN EST), LA INTERNET SOCIETY ET LA INTERNET ENGINEERING TASK FORCE DÉCLINENT TOUTES GARANTIES, EXPRIMÉES OU IMPLICITES, Y COMPRIS MAIS NON LIMITÉES À TOUTE GARANTIE QUE L’UTILISATION DES INFORMATIONS CI-ENCLOSES NE VIOLENT AUCUN DROIT OU AUCUNE GARANTIE IMPLICITE DE COMMERCIALISATION OU D’APTITUDE À UN OBJET PARTICULIER.
Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’IETF au sujet des droits dans les documents de l’IETF figurent dans les BCP 78 et BCP 79.
Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.
L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf- ipr@ietf.org.
Remerciement
Le financement de la fonction d’édition des RFC est actuellement fourni par Internet Society.