Résumé

La recommandation XML canonique [XML-C14N] spécifie une sérialisation standard de XML qui, quand elle est appliquée à un sous-document, inclut le contexte de l'ancêtre du sous-document, comprenant toutes les déclarations d'espaces de nommage et les attributs dans l'espace de nommage « xml: ». Cependant, certaines applications requièrent une méthode excluant, dans la mesure du pratique, le contexte de l'ancêtre du sous-document canonisé. Par exemple, on pourrait demander que la signature numérique sur une charge utile XML (le sous-document) dans un message XML ne soient pas rompue quand ce sous-document est extrait de son message original et/ou inséré dans un contexte différent. Cette exigence est satisfaite par la canonisation XML exclusive.

Statut de ce document

Table des matières

1. Introduction
   1. La terminologie
   2. Les applications
   3. Les limitations
2. La nécessité d'une canonisation XML exclusive
   1. Un exemple simple
   2. Les problèmes généraux liés aux sur-enveloppes
3. La spécification de la canonisation XML exclusive
   1. L'implémentation contrainte (non normatif)
4. L'utilisation dans la sécurité XML
5. Les considérations sur la sécurité
   1. Le contexte de la cible
   2. Les ensembles de nœuds « ésotériques »
6. Références
7. Remerciements

1. Introduction

La recommandation XML [XML] spécifie la syntaxe d'une classe d'objets appelés documents XML. La recommandations des espaces de nommage dans XML [XML-NS] spécifie une syntaxe et une sémantique supplémentaires pour les documents XML. Il est normal que les documents et les sous-documents XML, qui sont équivalents pour les besoins 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 leurs codages de caractères. L'objectif de cette spécification consiste à établir une méthode pour la sérialisation de la représentation de l'ensemble de nœuds XPath d'un document XML, ou d'un sous-ensemble, de sorte que :

1. l'ensemble de nœuds soit au minimum affecté par tout contexte XML qui aura été omis ;
2. la canonisation d'un ensemble de nœuds, représentant un code XML bien-équilibré [XML-Fragment], ne soit pas altérée par les opérations de canonisation exclusive suivantes ;
3. on puisse déterminer si deux ensembles de nœuds sont identiques, mises à part les transformations considérées comme insignifiantes par cette spécification du point de vue de [XML, XML-NS].

Une compréhension de la recommandation XML canonique [XML-C14N] est requise.

1.1 La terminologie

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

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 la représentation d'un document XML en entrée comme un rassemblement 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 exclus d'un ensemble de nœuds en fonction de l'évaluation d'une expression. Dans cette spécification et dans [XML-C14N], on utilise un ensemble de nœuds pour indiquer directement si chacun des nœuds doit être restitué ou non dans la forme canonique (dans ce sens, on l'utilise comme un ensemble mathématique formel). Un nœud qui est exclus de cet ensemble n'est pas rendu dans la forme canonique qui est générée, même si son nœud parent est lui inclus dans l'ensemble de nœuds. Cependant, un nœud omis peut encore avoir une influence sur la restitution de ses descendants (par exemple, en affectant le contexte d'espace de nommage des descendants).

Un sous-ensemble de document est une portion de document XML, indiquée par un ensemble de nœuds XPath, qui n'inclut pas forcément tous les nœuds dans le document. Comme défini dans la spécification [XPath], chaque nœud (par exemple, un élément, un attribut ou un espace de nommage) possède exactement un seul parent, qui est soit un nœud élément, soit le nœud racine. Un nœud apex [ndt. apex node] est un nœud élément, dans un sous-ensemble de document, qui n'a aucun nœud élément ancêtre dans ce sous-ensemble de document. Un nœud orphelin [ndt. orphan node] est un nœud élément dont l'élément parent ne se trouve pas dans le sous-ensemble de document. Le parent en sortie [ndt. output parent], d'un nœud orphelin qui n'est pas un nœud apex, est l'élément ancêtre le plus proche du nœud orphelin qui est dans le sous-ensemble de document ; un nœud apex n'a aucun parent en sortie. Le parent en sortie d'un nœud non orphelin est le parent de ce nœud. Un ancêtre en sortie [ndt. output ancestor] est tout nœud élément ancêtre dans le sous-ensemble de document.

Par exemple, considérons un arbre de document avec trois générations en aval du nœud racine A, une majuscule dénotant un nœud qui se trouve dans le sous-ensemble de document (A,E,G).

Représentation imagée :

Représentation textuelle :

  A-+-b
    `-c-+-d
        `-E-+-f
            `-G

Les caractéristiques suivantes s'appliquent :

• A est un nœud apex, parent en sortie de E et ancêtre en sortie de (E,G) ;
• E est un nœud orphelin et le parent en sortie de G.

Un élément E, dans un sous-ensemble de document, utilise visiblement une déclaration d'espace de nommage, i.e. un préfixe d'espace de nommage P et la valeur rattachée V, si E, ou un nœud attribut dans le sous-ensemble de document dont le parent est E, a un nom qualifié dans lequel P est le préfixe d'espace de nommage. Une définition similaire s'applique à un élément E, dans un sous-ensemble de document, qui utilise visiblement la déclaration d'espace de nommage par défaut, ce qui survient quand E n'a aucun préfixe d'espace de nommage.

L'axe des espaces de nommage d'un élément contient les nœuds de toutes les déclarations d'espaces de nommage, non par défaut, qui ont été faites dans l'élément ainsi que ceux des déclarations d'espaces de nommage, non par défaut, héritées des ancêtre de l'élément en question. L'axe des espaces de nommage contient aussi un nœud qui représente l'espace de nommage par défaut, si ce n'est pas la chaîne vide, que l'espace de nommage par défaut ait été déclaré dans l'élément ou bien par un ancêtre de celui-ci. Tout sous-ensemble des nœuds dans un axe des espaces de nommage peut être inclus dans un sous-ensemble de document.

La méthode de canonisation, décrite dans cette spécification, reçoit un paramètre InclusiveNamespaces PrefixList qui liste les préfixes d'espaces de nommage gérés de la manière décrite par la recommandation XML canonique [XML-C14N].

La forme canonique exclusive d'un sous-ensemble de document est une représentation de l'ensemble de nœuds XPath, en tant que séquence d'octets, produite par la méthode décrite dans cette spécification. C'est celle qui est définie dans la recommandation XML canonique [XML-C14N], à l'exception des changements qui se résument comme suit :

• les attributs dans l'espace de nommage XML, tels que xml:lang et xml:space ne sont pas importés dans les nœuds orphelins du sous-ensemble de document ;
• les nœuds d'espaces de nommage, qui ne sont pas dans la liste InclusiveNamespaces PrefixList, sont seulement exprimés dans les balises ouvrantes où ils sont visibles et s'ils ne sont pas en activité depuis un ancêtre en sortie de cette balise.

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

1.2 Les applications

Les applications de canonisation XML exclusive sont très semblables à celles de XML canonique [XML-C14N]. Cependant, la canonisation exclusive, ou les moyens équivalents pour exclure la plupart du contexte XML, est nécessaire aux applications de signature, pour lesquelles le contexte XML du XML signé changera. Ce genre de changement est typique de l'application de nombreux protocoles.

Remarquez, dans le cas de l'élément SignedInfo de [XML-DSig], que la spécification d'une méthode de canonisation adéquate est la seule technique disponible pour protéger la signature des changements insignifiants dans la forme physique et des changements dans le contexte XML.

1.3 Les limitations

La canonisation XML exclusive revêt les limitations du XML canonique [XML-C14N], plus deux limitations supplémentaires, comme suit :

1. Le XML en cours de canonisation peut dépendre de l'effet des attributs d'espace de nommage XML, tels que xml:lang, xml:space et xml:base, qui apparaissent dans les nœuds ancêtres. Pour éviter les problèmes liés à la non importation de ces attributs dans un sous-ensemble de document enveloppé, il faut soit les donner explicitement dans les nœuds apex du sous-ensemble de document XML en cours de canonisation, soit toujours les déclarer avec une valeur équivalente dans tous les contextes dans lesquels le sous-ensemble de document XML sera interprété ;
2. les applications qui utilisent le XML canonisé peuvent dépendre de l'effet des déclarations d'espaces de nommage XML où le préfixe d'espace de nommage rattaché est visiblement inutilisé. Un exemple en serait un attribut dont la valeur est une expression XPath et dont l'évaluation dépend par conséquent des préfixes d'espaces de nommage référencés dans l'expression. Ou encore, une valeur d'attribut pourrait être considérée comme un nom de type QName [XML-NS] par certaines applications, mais il ne s'agira que d'une valeur de chaîne pour XPath :

   <number xsi:type="xsd:decimal">10.09</number>.

   Pour éviter les problèmes liés à de telles déclarations d'espaces de nommage :

   • le code XML doit être modifié, de sorte que l'utilisation du préfixe d'espace de nommage impliqué soit visible, ou bien
   • les déclarations d'espaces de nommage doivent apparaître et ≖ctre rattachées aux mêmes valeurs dans tous les contextes où le XML sera interprété, ou bien
   • les préfixes de ces espaces de nommage doivent apparaître dans la liste InclusiveNamespaces PrefixList.

2. La nécessité de la canonisation XML exclusive

Dans certains cas, notamment pour du XML signé dans les applications de protocoles, il est nécessaire de canoniser un sous-docuemnt, de telle sorte qu'il soit substantiellement indépendant de son contexte XML. C'est parce qu'il est courant, dans les applications de protocoles, d'envelopper le code XML dans diverses couches d'éléments de message ou de transport, d'ôter ces enveloppes et de contruire de nouveaux messages de protocoles, dont certaines parties ont été extraites des divers messages reçus précédemment. Si les morceaux de XML en question sont signés, ils ont besoin d'être canonisés, de telle sorte que ces opérations ne rompent pas la signature et que celle-ci présente encore autant de sécurité que ce qui peut pratiquement obtenu.

2.1 Un exemple simple

En exemple simple du type de problème que peuvent introduire les changements de contexte XML pour les signatures, considérons le document suivant :

   <n1:elem1 xmlns:n1="http://b.exemple">
       contenu
   </n1:elem1>

ceci est ensuite enveloppé dans un autre document :

   <n0:pdu xmlns:n0="http://a.exemple">
      <n1:elem1 xmlns:n1="http://b.exemple">
          contenu
      </n1:elem1>
   </n0:pdu>

Le premier document ci-dessus est en forme canonique. Mais supposons que ce document soit enveloppé comme dans le second. Le sous-document, avec l'élément elem1 comme nœud apex, peut s'extraire dans ce cas à l'aide d'une expression XPath, tel que :

 (//. | //@* | //namespace::*)[ancestor-or-self::n1:elem1]

La conséquence de l'application de la canonisation XML canonique sur l'ensemble de nœuds XPath est la suivante (sans tenir compte des sauts de ligne pour présenter ce document) :

   <n1:elem1 xmlns:n0="http://a.exemple"
             xmlns:n1="http://b.exemple">
       contenu
   </n1:elem1>

Remarquez que l'espace de nommage n0 a été inclus par la canonisation XML canonique, parce qu'elle inclut le contexte de l'espace de nommage. Un tel changement romprait la signature sur l'élément elem1 du premier document.

2.2 Les problèmes généraux liés aux sur-enveloppes

En exemple plus complet des changements dans la forme canonique qui peuvent survenir, quand le contexte d'enveloppement d'un sous-ensemble de document a changé, considérons le document suivant :

   <n0:local xmlns:n0="truc:muche"
             xmlns:n3="ftp://exemple.org">
      <n1:elem2 xmlns:n1="http://exemple.net"
                xml:lang="en">
          <n3:machin xmlns:n3="ftp://exemple.org"/>
      </n1:elem2>
   </n0:local>

Et considérons le document suivant, produit en changeant l'enveloppe de l'élément elem2 :

   <n2:pdu xmlns:n1="http://exemple.com"
           xmlns:n2="http://truc.exemple"
           xml:lang="fr"
           xml:space="retain"> « errata-E01 »
      <n1:elem2 xmlns:n1="http://exemple.net"
                xml:lang="en">
          <n3:machin xmlns:n3="ftp://exemple.org"/>
      </n1:elem2>
   </n2:pdu>

Supposons un ensemble de nœuds produit à partir de chacun des cas, en appliquant l'expression XPath suivante :

 (//. | //@* | //namespace::*)[ancestor-or-self::n1:elem2]

L'application de la canonisation XML canonique à l'ensemble de nœuds produit à partir du premier document donne la sérialisation suivante (sans tenir compte des sauts de ligne pour présenter ce document) :

   <n1:elem2 xmlns:n0="truc:muche"
             xmlns:n1="http://exemple.net"
             xmlns:n3="ftp://exemple.org"
             xml:lang="en">
       <n3:machin></n3:machin>
   </n1:elem2>

Cependant, bien que l'élément elem2 soit représenté par la même séquence d'octets dans les deux morceaux XML externes ci-dessus, la version XML canonique de l'élément elem2 du second cas serait comme suit (sans tenir compte des sauts de ligne pour présenter ce document) :

   <n1:elem2 xmlns:n1="http://exemple.net"
             xmlns:n2="http://truc.example"
             xml:lang="en"
             xml:space="retain"> « errata-E01 »
       <n3:machin xmlns:n3="ftp://exemple.org"></n3:machin>
   </n1:elem2>

Remarquez que le changement dans le contexte a induit énormément de changements dans le sous-document quand celui-ci est sérialisé par la canonisation inclusive XML canonique [XML-C14N]. Dans le premier exemple, l'espace de nommage n0 avait été inclus à partir du contexte et la présence d'une déclaration d'espace de nommage n3 identique dans le contexte avait remonté cette déclaration à l'apex de la forme canonisée. Dans le second exemple, l'espace de nommage n0 a disparu, mais l'espace de nommage n2 est apparu, l'espace de nommage n3 n'est plus remonté et une déclaration xml:space est apparue, en conséquence du changement dans le contexte. Mais les changements de contexte n'ont pas tous d'effet. Dans le second exemple, la présence aux nœuds ancêtres d'un attribut xml:lang et d'un préfixe de déclaration d'espace de nommage n1 n'a aucun effet, en raison des déclarations existantes au nœud elem2.

À l'inverse, en utilisant la canonisation XML exclusive, comme spécifiée ici, la forme physique de l'élément elem2, tel qu'il serait extrait par l'expression XPath précédente, est comme suit (sans tenir compte des sauts de ligne pour présenter le document) :

   <n1:elem2 xmlns:n1="http://exemple.net"
             xml:lang="en">
       <n3:machin xmlns:n3="ftp://exemple.org"></n3:machin>
   </n1:elem2>

Et ceci dans les deux cas.

3. La spécification de la canonisation XML exclusive

Le modèle de données, le traitement, les paramètres en entrée et les données en sortie pour la canonisation XML exclusive sont les mêmes que pour la canonisation XML canonique [XML-C14N], avec les exceptions suivantes :

1. la canonisation XML canonique, appliquée à un sous-ensemble du document, requiert la recherche, par les nœuds ancêtres de chaque nœud élément orphelin, des attributs d'espace de nommage XML, tels que xml:lang et xml:space. Ceux-ci sont copiés dans les nœuds éléments, sauf si une déclaration du même attribut se trouve déjà dans l'axe des attributs de l'élément (que celui-ci soit inclus ou non dans le sous-ensemble du document). Cette recherche et cette copie sont omises dans la méthode de canonisation XML exclusive ;
2. la méthode de canonisation XML exclusive peut recevoir le paramètre supplémentaire InclusiveNamespaces PrefixList, éventuellement nul, qui contient une liste des préfixes d'espaces de nommage et/ou un atome indiquant la présence de l'espace de nommage par défaut. Tous les nœuds d'espaces de nommage apparaissant dans cette liste sont gérés selon la canonisation XML canonique [XML-C14N] ;
3. un nœud d'espace de nommage N, dont le préfixe n'apparaît pas dans la liste InclusiveNamespaces PrefixList, est restituté si toutes les conditions suivantes sont réunies :
   1. son élément parent est dans l'ensemble de nœuds, et ;
   2. il est visiblement utilisé par son élément parent, et ;
   3. le préfixe n'a pas encore été restitué par un quelconque ancêtre en sortie, ou encore l'ancêtre en sortie le plus proche de son élément parent, qui utilise visiblement le préfixe d'espace de nommage, n'a pas de nœud d'espace de nommage dans l'ensemble de nœuds, avec le même préfixe d'espace de nommage et la même valeur que l'espace de nommage N.
4. si l'atome représentant l'espace de nommage par défaut n'est pas présent dans la liste InclusiveNamespaces PrefixList, alors les règles de restitution de xmlns="" sont changées comme suit. Lors de la canonisation de l'axe des espaces de nommage d'un élément E, qui se trouve dans l'ensemble de nœuds, on produit xmlns="" en sortie si et seulement si toutes les conditions suivantes sont réunies :
   1. l'élément E utilise visiblement l'espace de nommage par défaut (i.e., celui-ci n'a pas de préfixe d'espace de nommage), et ;
   2. il n'a aucun nœud espace de nommage dans l'ensemble de nœuds, et ;
   3. l'ancêtre en sortie le plus proche de l'élément E, qui utilise visiblement l'espace de nommage par défaut, a un nœud espace de nommage par défaut dans l'ensemble de nœuds.

   (Cette étape pour l'espace de nommage xmlns="" est nécessaire, parce que celui-ci n'est pas représenté par un nœud espace de nommage dans le modèle de données XPath, mais comme l'absence d'un nœud espace de nommage ; voir la section « 4.7 La propagation de l'espace de nommage par défaut dans les sous-ensemble du document » [XML-C14N].)

3.1 L'implémentation contrainte (non-normative)

Ce qui suit représente une marche à suivre (non normative) pour l'implémentation de la méthode de canonisation XML exclusive dans un grand nombre de situations communes. Elle suppose un sous-ensemble bien-formé et que l'élément se trouve dans l'ensemble de nœuds, de même que la totalité de son axe des espaces de nommage ; si l'élément n'est pas dans l'ensemble de nœuds, son axe des espaces de nommage ne le sera pas non plus.

1. traiter récursivement l'arbre entier (celui à partir duquel l'ensemble de nœuds XPath a été sélectionné), dans l'ordre du document, en commençant par la racine. (L'opération qui consiste à copier les attributs d'espace de nommage xml: de l'ancêtre dans les nœuds éléments apex en sortie n'est pas réalisée) ;
2. si le nœud n'est pas dans l'ensemble de nœuds XPath, continuer le traitement de ses nœuds éléments enfants récursivement ;
3. si le nœud élément est dans l'ensemble de nœuds XPath, alors sortir le nœud selon la canonisation XML canonique, sauf les nœuds espaces de nommage qui sont restitués comme suit :
   1. le paramètre ns_rendered représente la copie d'un dictionnaire de préfixes et de leurs valeurs, pris sur le dessus de la pile [ndt. stack] state, qui ont déjà été restitués par un ancêtre en sortie de l'élément parent du nœud espace de nommage ;
   2. restituer chaque nœud espace de nommage, si et seulement si toutes les conditions suivantes sont réunies :
      1. il est visiblement utilisé par l'élément parent immédiat ou l'un des attributs de celui-ci, ou encore il est présent dans la liste InclusiveNamespaces PrefixList, et ;
      2. son préfixe et sa valeur n'apparaissent pas dans le paramètre ns_rendered.
   3. restituer xmlns="", si et seulement si toutes les conditions suivantes sont réunies :
   4. 1. l'espace de nommage par défaut est visiblement utilisé par le nœud élément parent immédiat, ou l'atome de préfixe par défaut est présent dans la liste InclusiveNamespaces PrefixList, et ;
      2. l'élément n'a pas de nœud espace de nommage, dans l'ensemble de nœuds, qui déclare une valeur pour l'espace de nommage par défaut, et ;
      3. le préfixe d'espace de nommage par défaut est présent dans le dictionnaire ns_rendered.
   5. insérer tous les nœuds espaces de nommage (y compris xmlns="") dans le dictionnaire ns_rendered, en remplaçant les éventuelles entrées existantes. Pousser le dictionnaire ns_rendered sur la pile state et effectuer la récursion ;
   6. après que la récursion est achevée, extraire la pile state.

4. L'utilisation dans la sécurité XML

La canonisation exclusive peut s'utiliser comme algorithme des éléments Transform ou CanonicalizationMethod dans une signature numérique XML [XML-DSig] et le cryptage XML [XML-Enc].

Identifiant :

http://www.w3.org/2001/10/xml-exc-c14n#

http://www.w3.org/2001/10/xml-exc-c14n#WithComments

Tout comme avec [XML-C14N], on peut utiliser le paramètre "#WithComments" pour inclure la sérialisation des commentaires XML. Cet algorithme admet également le paramètre explicite optionnel d'un élément InclusiveNamespaces vide avec l'attribut PrefixList. La valeur de cet attribut, éventuellement nul, est une liste de préfixes d'espaces de nommage séparés par des blancs, dans laquelle la valeur "#defaut" désigne l'espace de nommage par défaut, préfixes qui sont gérés selon [XML-C14N]. La liste est dans le format NMTOKENS (liste dont les valeurs sont séparées par des blancs).
« errata-E02 »

Par exemple :

   <ds:Transform
      Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
      <ec:InclusiveNamespaces PrefixList="dsig soap #default"
          xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/>
   </ds:Transform>

cela indique la transformation de canonisation exclusive et, autrement, que les espaces de nommage avec les préfixes "dsig" ou "soap" et les espaces de nommage par défaut devraient être traités selon [XML-C14N].

   Définition de schéma :

   <?xml version="1.0" encoding="utf-8"?>
   <!DOCTYPE schema
     PUBLIC "-//W3C//DTD XMLSchema 200102//EN" "http://www.w3.org/2001/XMLSchema.dtd"
    [
      <!ATTLIST schema 
        xmlns:ec CDATA #FIXED 'http://www.w3.org/2001/10/xml-exc-c14n#'>
      <!ENTITY ec 'http://www.w3.org/2001/10/xml-exc-c14n#'> 
      <!ENTITY % p ''>
      <!ENTITY % s ''>
     ]>

   <schema xmlns="http://www.w3.org/2001/XMLSchema"
           xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
           targetNamespace="http://www.w3.org/2001/10/xml-exc-c14n#"
           version="0.1" elementFormDefault="qualified">

     <element name="InclusiveNamespaces"
              type="ec:InclusiveNamespaces"/>
     <complexType name="InclusiveNamespaces">
        <attribute name="PrefixList" type="NMTOKENS"/> « errata-E02 »
     </complexType>
   </schema>

   DTD :
   <!ELEMENT InclusiveNamespaces    EMPTY >
   <!ATTLIST InclusiveNamespaces
      PrefixList    NMTOKENS    #REQUIRED > « errata-E02 »

5. Les considérations sur la sécurité

Cette spécification est utilisée pour la sérialisation d'un ensemble de nœuds XPath, selon certains postulats donnés dans [XML-C14N] et la présente spécification. En voici trois exemples :

1. les implémentations de [XML-C14N] et de cette spécification ne restituent pas de déclaration XML ;
2. les implémentations de cette spécification ne restituent que les attributs issus de l'espace de nommage « XML » (par exemple, xml:lang, xml:space et xml:base) quand ceux-ci se trouvent dans le sous-ensemble en cours de sérialisation ;
3. les implémentations de cette spécification ne considèrent pas l'apparition d'un préfixe d'espace de nommage dans la valeur d'un attribut comme étant visiblement utilisé.

Bien que de tels choix soient cohérents par rapport aux autres spécifications XML et satisfassent aux conditions d'application du groupe de travail, il est important qu'une application XML construise soigneusement ses transformations de manière à ce que le résultat soit significatif et non équivoque dans son contexte d'application. En complément de cette section, la section « Les limitations » de la présente spécification, la section « Les résolutions » de [XML-C14N] et la section « Les considérations sur la sécurité » de [XML-DSig] devraient être soigneusement étudiées.

5.1 Le contexte de la cible

5.2 Les ensembles de nœuds « ésotériques »

6. Références

Keywords

RFC 2119. Les mots-clés à utiliser dans les RFC pour indiquer les niveaux d'obligation. S. Bradner. Best Current Practice, mars 1997.

Disponible à http://www.ietf.org/rfc/rfc2119.txt

URI

RFC 2396. Les identifiants de ressource uniformes (URI) : syntaxe générique. T. Berners-Lee, R. Fielding et L. Masinter. Standards Track, août 1998.

Disponible à http://www.ietf.org/rfc/rfc2396.txt

XML

Le langage de balisage extensible (XML) 1.0 (Seconde édition). T. Bray, E. Maler, J. Paoli et C. M. Sperberg-McQueen. Recommandation du W3C, octobre 2000.

Disponible à http://www.w3.org/TR/2000/REC-xml-20001006

XML-C14N

XML canonique J. Boyer. Recommandation du W3C, mars 2001.

Disponible à http://www.w3.org/TR/2001/REC-xml-c14n-20010315

Disponible à http://www.ietf.org/rfc/rfc3076.txt

XML-DSig

La syntaxe et le traitement XML-Signature. D. Eastlake, J. Reagle et D. Solo. Avant-projet de norme IETF/recommandation du W3C, août 2001.

Disponible à http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/

XML-Fragment

L'échange de fragment XML. P. Grosso et D. Veillard. Recommandation candidate du W3C, février 2001.

Disponible à http://www.w3.org/TR/2001/CR-xml-fragment-20010212

XInclude

Les inclusions XML (XInclude) version 1.0. J. Marsh et D. Orchad. Recommandation candidate du W3C, février 2002.

Disponible à http://www.w3.org/TR/2002/CR-xinclude-20020221/

XML-NS

Les espaces de nommage dans XML. T. Bray, D. Hollander et A. Layman. Recommandation du W3C, janvier 1999.

Disponible à http://www.w3.org/TR/1999/REC-xml-names-19990114/

XML-Enc

La syntaxe et le traitement XML-Encryption. D. Eastlake et J. Reagle. Recommandation candidate du W3C, mars 2002.

Disponible à http://www.w3.org/TR/2002/CR-xmlenc-core-20020304/

XML-schema

XML Schema - Partie 1 : Les structures D. Beech, M. Maloney, N. Mendelsohn et H. Thompson. Recommandation du W3C, mai 2001.

Disponible à http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/

XPath

Le langage de chemin XML (XPath) version 1.0. J. Clark et S. DeRose. Recommandation du W3C, novembre 1999.

Disponible à http://www.w3.org/TR/1999/REC-xpath-19991116

7. Remerciements (informatif)

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

• Merlin Hughes, Baltimore
• Thomas Maslen, DSTC
• Paul Denning, MITRE
• Christian Geuer-Pollmann, University Siegen
• Bob Atkinson, Microsoft