Traduction de la recommandation
XPointer Framework
du 25 mars 2003

Statut du document traduit

Références

Avertissement

Cette traduction d'un document du W3C n'est pas la version officielle en français : seul le document original en anglais a valeur de référence.

Bien qu'elle ait été vérifiée, la traduction peut comporter des erreurs.

Errata

La traduction intègre toutes les corrections officielles depuis la parution de la recommandation en décembre 2002. Le texte signale les corrections apportées de la manière suivante :

« errata E01 »

Supports de la traduction

Les notes de traduction se présentent dans le texte sous deux formes :

  1. L'une explicite : traduction [NdT. translation]
  2. L'autre affiche la note au survol du pointeur : traduction

Les liens vers un document du W3C sont doublés vers une traduction quand elle existe :
un document du W3C→vf

Télécharger une archive

Cf. les archives disponibles pour les traductions hébergées sur ce site.

Les traductions des documents du W3C

Le World Wide Web Consortium tient un répertoire des traductions disponibles.

Notice légale

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


W3C

Le cadre XPointer

Recommandation du W3C du 25 mars 2003

Cette version :
http://www.w3.org/TR/2003/REC-xptr-framework-20030325/
Dernière version :
http://www.w3.org/TR/xptr-framework/
Version précédente :
http://www.w3.org/TR/2002/PR-xptr-framework-20021113/
Rédacteurs :
Paul Grosso, Arbortext, Inc. <paul@arbortext.com>
Eve Maler, Sun Microsystems <eve.maler@sun.com>
Jonathan Marsh, Microsoft <jmarsh@microsoft.com>
Norman Walsh, Sun Microsystems <Norman.Walsh@Sun.COM>

Veuillez consulter l'errata de ce document, lequel peut contenir des corrections normatives.

Ce document est également disponible dans ce format non normatif : XML.

Seule la version originale en anglais de cette spécification est normative. Des traductions non normatives peuvent éventuellement être disponibles.


Résumé

Cette spécification définit le cadre du langage de pointeur XML (XPointer), un système extensible pour l'adressage XML qui sous-tend les spécifications de systèmes [NdT. schemes] XPointer supplémentaires. Ce cadre est conçu pour servir de fondement aux identificateurs de fragments de toute ressource dont le type de média Internet est text/xml, application/xml, text/xml-external-parsed-entity ou application/xml-external-parsed-entity. Les autres types de média fondés sur XML sont également encouragés à utiliser ce cadre pour définir leurs propres langages d'identificateur de fragment.

Statut de ce document

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

Ce document est une recommandation (REC) du W3C. Il a été revu par les membres du W3C et les tiers intéressés et il 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 à partir d'un autre document. Le rôle du W3C en produisant cette recommandation consiste à attirer l'attention sur la spécification et d'en promouvoir le large déploiement. Ceci améliore les fonctionnalités et l'interopérabilité du Web.

Ce document a été produit par le groupe de travail sur les liaisons XML du W3C qui fait partie de l'activité XML. Il répond à un sous-ensemble minimal des conditions requises pour XPointer originales, et constitue, avec les spécifications du système element() XPointer et du système xmlns() XPointer, la totalité sinon l'essentiel de la syntaxe des identificateurs de fragment pour les types de média XML.

Les commentaires du public concernant cette recommandation sont les bienvenus. Veuillez les adresser à la liste de diffusion publique www-xml-linking-comments@w3.org (archives).

On peut trouver des informations concernant les mises en œuvres relatives à cette spécification et celles qui l'accompagnent, à savoir le système element() XPointer→vf et le système xmlns() XPointer→vf, dans le rapport de mise en œuvre.

Des divulgations de brevets et des conditions d'utilisation sont associées à cette recommandation, on peut les consulter sur la page de la déclaration des droits de propriété intellectuelle de XPointer conformément à la politique du W3C.

On peut trouver la liste des recommandations et des autres documents techniques courants du W3C à http://www.w3.org/TR/. Les publications du W3C peuvent, à tout instant, être mises à jour, remplacées ou rendues obsolètes par d'autres documents.

Table des matières

  1. Introduction
    1. La notation
    2. La terminologie
  2. La conformité
  3. Le langage et le traitement
    1. La syntaxe
    2. Les pointeurs abrégés
    3. Les pointeurs basés sur un système
    4. Le contexte de liaison d'espace de nommage
  4. L'échappement des caractères
    1. Les contextes d'échappement
    2. Exemples d'échappements

Annexe

A Références
A.1 Les références normatives
A.2 Les références non normatives


1 Introduction

Cette spécification définit le cadre du langage de pointeur XML (XPointer), un système extensible pour l'adressage XML qui sous-tend les spécifications de systèmes XPointer supplémentaires. Ce cadre est destiné à servir de base aux identificateurs de fragments de toute ressource dont le type de média Internet est text/xml, application/xml, text/xml-external-parsed-entity ou application/xml-external-parsed-entity. Les autres types de média fondés sur XML sont également invités à utiliser ce cadre pour définir leurs propres langages d'identificateur de fragment.

Beaucoup de types d'application à traitement XML ont besoin d'adresser les structures internes des ressources XML en recourant à des adresses URI, par exemple, le langage de liaison XML [XLink], le langage d'inclusion XML [XInclude], le cadre de description des ressources [RDF] et le protocole SOAP 1.2 [SOAP12]. Cette spécification ne contraint pas les types des applications qui utilisent des adresses URI pour désigner des ressources XML ni contraint ou dicte le comportement de ces applications une fois que les informations voulues ont été localisées dans ces ressources.

1.1 La notation

[Définition : Les mots-clés doi(ven)t, ne doi(ven)t pas, requis, devra, ne devra pas, devrai(en)t, ne devrai(en)t pas, recommandé, peu(ven)t et optionnel dans cette spécification doivent s'interpréter selon le document [RFC 2119]].

La grammaire formelle du cadre XPointer est exprimée en utilisant la notation simple de la forme Backus-Naur étendue (EBNF), comme décrit dans la recommandation XML [XML].

1.2 La terminologie

[Définition : pointeur] [NdT. pointer]

Une chaîne conforme à cette spécification. Cette spécification définit la syntaxe et la sémantique des pointeurs.

[Définition : partie de pointeur] [NdT. pointer part]

Une portion de pointeur qui fournit un nom de système et certaines données de pointeur conformément à la définition du système en question. Le processeur XPointer évalue une partie de pointeur pour identifier zéro ou plus sous-ressources dans une ressource XML.

[Définition : système] [NdT. scheme]

Un format spécialisé de données de pointeur qui a un nom et qui est défini dans une spécification.

[Définition : processeur XPointer]

Un composant logiciel qui identifie les sous-ressources d'une ressource XML en lui appliquant un pointeur. Cette spécification définit le comportement des processeurs XPointer.

[Définition : application]

Un composant logiciel qui intègre ou utilise un processeur XPointer parce que ce composant a besoin d'accéder à des sous-ressources XML. Les occurrences et usages des pointeurs XPointer, ainsi que le comportement à appliquer aux ressources et aux sous-ressources obtenues par le traitement de ces pointeurs, obéissent à la définition du format de données correspondant à chaque application (que ce format se fonde sur XML ou non). Par exemple, les navigateurs Web HTML [HTML] et les processeurs XInclude sont des applications susceptibles d'utiliser des processeurs XPointer.

[Définition : erreur]

Une violation des règles syntaxiques de cette spécification, ou bien l'échec d'un pointeur à identifier une sous-ressource.

[Définition : contexte de liaison d'espace de nommage] [NdT. namespace binding context]

La liaison des préfixes d'espace de nommage, définis selon la spécification des espaces de nommage XML [XML-Names], aux noms des espaces de nommage associés.

2 La conformité

Cette spécification définit un cadre d'utilisation ; elle ne définit pas, pour l'instant, de niveau de conformité minimum pour les processeurs XPointer. Les explications de cette section ne définissent donc que les règles de conformité pour la partie cadre d'un niveau de conformité minimum.

Le processeur XPointer dépend de l'aptitude de l'application à inverser le codage et l'échappement d'un identificateur de fragment (cf. 4 L'échappement des caractères).

Le comportement du processeur XPointer dépend de la disponibilité de certaines informations provenant de la ressource XML : dans la terminologie de la spécification [Infoset], les items d'information et les propriétés pertinentes sont rappelées dans la liste suivante. Certains items et certaines propriétés seront à leur tour présents, ou non, conformément au traitement de la définition de type de document (DTD) ou du schéma XML : les processeurs XPointer conformes ne sont pas obligés de réaliser ce traitement mais, si c'est le cas, le traitement des pointeurs abrégés tirera avantage des informations fournies de ce fait (cf. 3.2 Les pointeurs abrégés).

Les composants logiciels prétendant au titre de processeur XPointer doivent se conformer à cette spécification du cadre XPointer et à toutes les autres spécifications qui, avec celle-ci, définissent le niveau de conformité minimum de XPointer. Ces composants peuvent se conformer aux spécifications de systèmes XPointer supplémentaires. Les processeurs XPointer doivent documenter les spécifications des systèmes supplémentaires auxquelles ils sont conformes. Les spécifications dépendant du traitement XPointer devraient documenter les systèmes qui leur sont nécessaires et ceux qu'elles reconnaissent.

Les processeurs XPointer conformes doivent signaler à l'application les erreurs provenant du cadre XPointer. Les applications sont libres de quitter ou bien de récupérer d'une manière quelconque aux erreurs du cadre XPointer.

3 Le langage et le traitement

Cette section décrit le cadre XPointer et le comportement des processeurs XPointer en fonction de ce cadre.

Le processeur XPointer reçoit en entrée une ressource XML et une chaîne à utiliser comme pointeur (par exemple, un identificateur de fragment, avec un inversement des échappements, qui fait partie de l'adresse URI utilisée pour accéder à la ressource) puis essaye d'évaluer le pointeur par rapport à la ressource et produit en sortie une identification des sous-ressources, ou sinon une ou plusieurs erreurs.

3.1 La syntaxe

Si la chaîne utilisée comme pointeur n'adhère pas à la syntaxe définie dans cette section, alors il y a condition d'erreur.

Le symbole S est défini dans [XML]. Les symboles NCName et QName sont définis dans [XML-Names].

La syntaxe du cadre XPointer
[1] Pointer  ::= Shorthand | SchemeBased
[2] Shorthand  ::= NCName
[3] SchemeBased  ::= PointerPart (S? PointerPart)*
[4] PointerPart  ::= SchemeName '(' SchemeData ')'
[5] SchemeName  ::= QName
[6] SchemeData  ::= EscapedData*
[7] EscapedData  ::= NormalChar | '^(' | '^)' | '^^' | '(' SchemeData ')'
[8] NormalChar  ::= UnicodeChar - [()^]
[9] UnicodeChar  ::= [#x0-#x10FFFF]

Comme cela apparaît dans les productions ci-dessus, la fin de la partie de pointeur est signalée par un caractère parenthèse fermante ) qui vient contrebalancer le caractère parenthèse ouvrante ( indiquant le début de cette partie. Si une parenthèse ouvrante, ou bien fermante, apparaît dans les données de système, sans que celle-ci soit équilibrée par une contrepartie, alors elle doit être échappée par un caractère caret ^ qui la précède. L'échappement d'un couple de parenthèses équilibrées est autorisé. Toute occurrence littérale du caractère caret ^ doit être échappée par un caret supplémentaire (c'est-à-dire ^^). Tout autre usage d'un caret constitue une condition d'erreur.

3.2 Les pointeurs abrégés

Un pointeur abrégé, anciennement appelé un nom strict [NdT. barename], se compose d'un nom de type NCName seul. Il identifie un élément au plus dans l'ensemble d'information de la ressource ; plus spécifiquement, le premier (le cas échéant) dans l'ordre du document ayant un nom de type NCName comme identificateur. On détermine les identificateurs d'un élément de la manière suivante :

  1. Si la propriété [attributs] d'un item d'information d'élément comporte un item d'information d'attribut dont la valeur est un ID déterminé par un schéma, alors on identifie l'élément par la valeur de la propriété [valeur normalisée de schéma] de cet item d'information d'attribut ;

  2. Si la propriété [enfants] d'un item d'information d'élément comporte un item d'information d'élément dont la valeur est un ID déterminé par un schéma, alors on identifie l'élément par la valeur de la propriété [valeur normalisée de schéma] de cet item d'information d'élément ;

  3. Si la propriété [attributs] d'un item d'information d'élément comporte un item d'information d'attribut dont la valeur est un ID déterminé par une définition DTD, alors on identifie l'élément par la valeur de la propriété [valeur normalisée] de cet item d'information d'attribut.

  4. Un item d'information d'élément peut également être identifié par la valeur d'un ID déterminé extérieurement.

Si aucun item d'information d'élément n'est identifié par le nom NCName d'un pointeur abrégé, alors le pointeur est en condition d'erreur.

Remarque :

Un item d'information d'élément peut être identifié par plusieurs valeurs, dans un document avec plusieurs ID déterminés par une définition DTD, ID déterminés par un schéma et ID déterminés extérieurement. Pour ces documents, cela peut se traduire par la perte de l'interopérabilité si les valeurs des identificateurs d'un élément particulier ne sont pas toujours les mêmes.

[Définition : Un item d'information d'élément, ou d'attribut, est un ID déterminé par un schéma si, et seulement si, l'une des caractéristiques suivantes est vérifiée :]

  1. Cet item comporte une propriété [définition de type de membre], ou bien [définition de type], dont la valeur de la propriété [nom] est égale à ID et celle de la propriété [espace de nommage cible] est égale à http://www.w3.org/2001/XMLSchema ;

  2. Cet item comporte une propriété [définition de type de base] dont la valeur est celle de ces propriétés [nom] et [espace de nommage cible] ;

  3. Cet item comporte une propriété [définition de type de base] dont la valeur de sa propre propriété [définition de type de base] est celle de ces propriétés [nom] et [espace de nommage cible], et ainsi de suite en parcourant récursivement la propriété [définition de type de base] ;

  4. Cet item comporte une propriété [nom de définition de type] égale à ID et une propriété [espace de nommage de définition de type] égale à http://www.w3.org/2001/XMLSchema ;

  5. Cet item comporte une propriété [nom de définition de type de membre] égale à ID et une propriété [espace de nommage de définition de type de membre] égale à http://www.w3.org/2001/XMLSchema.

[Définition : Un item d'information d'attribut est un ID déterminé par une définition DTD si, et seulement si, celui-ci comporte une propriété [définition de type] dont la valeur est égale à ID].

[Définition : Un ID déterminé extérieurement est une chaîne, représentant un identificateur d'élément, dont la valeur est établie par l'application au moyen de mécanismes non définis par cette spécification].

Remarque :

Pour les ressources ayant des types de média basés sur XML, les pointeurs abrégés se comportent approximativement comme les identificateur de fragment HTML. Toutefois, si l'information du type de ID n'est pas disponible, en raison de l'absence d'une définition DTD, d'un schéma ou d'informations propres à l'application, le pointeur n'identifiera aucun élément. On peut rendre l'identification d'un élément plus fiable de plusieurs façons. Par exemple, le créateur de la ressource peut utiliser un sous-ensemble interne de la définition DTD pour indiquer la présence d'attributs de type ID et le créateur du pointeur peut, au lieu d'un pointeur abrégé, utiliser un pointeur basé sur un système ou fournir un ou plusieurs systèmes qui adressent l'élément voulu autrement.

Remarque :

Les définitions précédentes ne sont pas affectées par le fait que la valeur ayant identitifé un item d'information d'élément soit unique ou non dans le document, parce que ni la spécification [XML] ni la spécification [XMLSchema] ne l'imposent pour l'assignation du type ID.

3.3 Les pointeurs basés sur un système

Un pointeur basé sur un système se compose d'une ou de plusieurs parties de pointeur, séparées optionnellement par des blancs [NdT. white space] (S). Chaque partie possède un nom de système et contient, entre parenthèses, des données (de type EscapedData) conformément au système nommé. Si les données de système contiennent des parenthèses, elles doivent soit s'équilibrer, soit être échappées.

Quand plusieurs parties de pointeur se présentent, le processeur XPointer doit les évaluer selon un ordre de gauche à droite. Si le processeur XPointer ne reconnaît pas le système qui est employé dans une partie de pointeur, il saute cette partie de pointeur. Si le processeur XPointer n'identifie aucune sous-ressource, l'évaluation continue et, le cas échéant, la partie de pointeur suivante est évaluée. Le résultat de la première partie de pointeur dont l'évaluation identifie une ou plusieurs sous-ressources est retourné par le processeur XPointer comme résultat du pointeur dans son ensemble, et l'évaluation se termine. Si aucune partie de pointeur n'identifie une sous-ressource, il y a condition erreur.

Dans l'exemple suivant, si la partie de pointeur xpointer n'est pas comprise, ou bien échoue à identifier une sous-ressource, la partie de pointeur element sera évaluée. Par contre, si la partie de pointeur xpointer identifie des sous-ressources, la partie de pointeur element ne sera pas évaluée.

#xpointer(id('boy-blue')/horn[1])element(boy-blue/3)

Le nom d'un système se compose syntaxiquement d'un Préfixe [NdT. Prefix] et d'une PartieLocale [NdT. LocalPart], comme défini dans la spécification [XML-Names]. De manière abstraite, les noms de système sont des tuples formés de la PartieLocale et du nom d'espace de nommage correspondant à ce Préfixe dans le contexte de liaison d'espace de nommage. Si le contexte de liaison d'espace de nommage ne contient aucun préfixe correspondant, ou si le couple (nom d'espace de nommage, PartieLocale) ne correspond à aucun nom de système géré par le processeur XPointer, alors la partie de pointeur n'est pas évaluée.

Cette spécification réserve tous les noms de système non qualifiés pour une définition dans des systèmes XPointer supplémentaires définis dans les recommandations du W3C. L'utilisation des noms QName comme noms de système offre un cadre général d'extension par les autres types de média basés sur XML qui souhaitent utiliser ce cadre pour définir leurs propres langages d'identificateur de fragment. Quel que soit le système à utiliser conjointement au cadre XPointeur, sa définition doit spécifier un nom de système constitué d'un couple (nom d'espace de nommage, PartieLocale).

3.4 Le contexte de liaison d'espace de nommage

Les spécifications de systèmes doivent définir les moyens permettant d'associer les préfixes des espaces de nommage XML [XML-Names] aux noms des espaces de nommage pour interpréter les préfixes des noms de système, ou des noms des éléments, attributs et autres noms de type QName apparaissant dans les parties de pointeur. Ces associations contribuent à un contexte de liaison d'espace de nommage qui s'applique à toutes les parties de pointeur situées à la droite de la partie de pointeur réalisant l'association, à moins que les systèmes concernés ne définissent des exceptions explicites. La documentation d'un système de liaison à un espace de nommage doit spécifier si les liaisons restent en vigueur pour les parties de pointeur suivantes. La documentation de chaque système doit spécifier si celui-ci recourt au contexte de liaison d'espace de nommage.

Dans l'exemple suivant, on utilise le système xmlns (voir [XPtrXmlns]) pour ajouter une liaison (préfixe/espace de nommage) au contexte de liaison d'espace de nommage. Le processeur XPointer utilise cette information pour déterminer si img:rect indique le nom d'un système qu'il gère.

#xmlns(img=http://exemple.org/image)img:rect(10,10,50,50)

Le contexte de liaison d'espace de nommage initial, antérieur à l'évaluation de la première partie de pointeur, est constitué d'une seule entrée : le préfixe xml lié au nom d'espace de nommage http://www.w3.org/XML/1998/namespace. Le contexte de liaison d'espace de nommage est soumis aux contraintes suivantes (les tentatives de violation de ces contraintes n'auront aucun effet sur le contexte de liaison d'espace de nommage) :

  • Le préfixe xml est lié au nom d'espace de nommage http://www.w3.org/XML/1998/namespace. Il ne doit pas être lié à un quelconque autre nom d'espace de nommage ;

  • le nom d'espace de nommage http://www.w3.org/XML/1998/namespace est lié au préfixe xml. Il ne doit pas être lié à un quelconque autre préfixe ;

  • le préfixe xmlns ne doit pas être lié à un nom d'espace de nommage ;

  • le nom d'espace de nommage http://www.w3.org/2000/xmlns/ ne doit pas être lié à un quelconque préfixe.

Les préfixes commencent par la séquence des trois lettres x, m et l, quelle que soit leur casse, sont réservés. Les utilisateurs ne devraient pas les employer, sauf selon les définitions de la spécification XML et de celles de la famille XML.

4 L'échappement des caractères

Le codage de caractères des pointeurs XPointeur est [Unicode]. Toutefois, le langage XPointer est conçu pour un usage dans un contexte d'adresses URI [RFC 2396] et d'adresses IRI [IRI], lesquelles imposent le codage et l'échappement de certains caractères. Les pointeurs XPointer et les adresses IRI contenant des pointeurs XPointer apparaissent souvent dans les documents XML et les entités analysées externes, ce qui impose des échappements spécifiques lorsque le codage limite le répertoire des caractères pouvant être utilisés directement. D'autres contextes peuvent imposer l'application d'un échappement supplémentaire sur les pointeurs XPointer. Également, comme certains caractères sont significatifs pour le traitement XPointer, il est nécessaire d'échapper ces caractères afin de les employer dans un sens ordinaire.

4.1 Les contextes d'échappement

Les contextes suivants exigent l'application de divers types d'échappement sur les pointeurs XPointer :

A. L'échappement des caractères significatifs pour XPointer

Comme décrit dans 3.1 La syntaxe, les parenthèses non équilibrées et les occurrences du caractère caret ^ doivent être échappées.

B. L'échappement et le codage des caractères IRI réservés

[Définition : Un identificateur de ressource internationalisé, ou IRI, est un élément de protocole qui étend la syntaxe des adresses URI au répertoire bien plus vaste des caractères Unicode [Unicode]]. Les adresses IRI permettent un surensemble des caractères des adresses URI entièrement échappées, mais les occurrences normales des caractères pourcentages % doivent être échappées, étant donné qu'il s'agit du caractère utilisé pour l'échappement dans les adresses URI et IRI.

C'est pourquoi, lorsqu'on insère un pointeur dans une adresse IRI, toutes les occurrences des signes pourcentages % doivent être échappées. Les autres caractères peuvent l'être également, bien que ce ne soit pas recommandé. Les caractères sont échappés de la manière suivante :

  1. Chaque caractère à échapper est converti dans le codage de caractères UTF-8 [RFC 2279] sur un ou plusieurs octets ;

  2. Les octets résultants sont échappés à l'aide du mécanisme d'échappement des adresses URI (c'est-à-dire, ils sont convertis dans la forme %HH, dans laquelle HH représente la valeur d'octet en notation hexadécimale) ;

  3. Le caractère original est remplacé par la séquence de caractères résultante.

Par exemple, le caractère % devient %25.

C. L'échappement et le codage des caractères réservés des adresses URI

Les adresses IRI peuvent être converties en adresses URI pour leur consommation par les résolveurs d'adresses URI. Les caractères non admis dans les adresses URI comprennent tous les caractères non-ASCII, plus les caractères exclus listés dans la section 2.4 du document [RFC 2396], à l'exception des caractères dièse #, pourcentage % et crochets [ et ] qui ont été ré-admis par le document [RFC 2732]. Les caractères non admis sont échappés de la manière suivante :

  1. Chaque caractère non admis est converti dans le codage de caractères UTF-8 [RFC 2279] sur un ou plusieurs octets ;

  2. Les octets résultants sont échappés selon le mécanisme d'échappement des adresses URI (c'est-à-dire qu'ils sont convertis dans la forme %HH, où HH représente la valeur d'octet en notation hexadécimale) ;

  3. Le caractère original est remplacé par la séquence de caractères résultante.

D. L'échappement XML

Si un pointeur apparaît dans un document XML ou une entité analysée externe, tous les caractères non exprimables dans le codage de caractères employé doivent être échappés sous la forme de références de caractères, et tous les caractères significatifs pour le traitement XML à l'endroit où ils se trouvent doivent être échappés selon un mécanisme approprié, tels que celui des références de caractères ou des références d'entité. Cet échappement sera inversé lorsque le document ou l'entité XML seront analysés. Il n'est pas recommandé de placer des adresses URI (au lieu d'adresses IRI qui sont plus générales) dans les documents XML. Si, pour une raison quelconque, on ne peut pas l'éviter, alors le même mécanisme d'échappement s'applique.

Puisque le processeur XPointer inversera seulement l'échappement des caractères significatifs pour XPointer (cf. section A), l'application devra inverser tous les autres codages ou échappements (tels que ceux des sections B, C ou D) dont le pointeur aura fait l'objet. Si le résultat passé au processeur XPointer n'est pas conforme aux règles syntaxiques pour les pointeurs XPointer dans cette spécification, il y a condition d'erreur.

4.2 Exemples d'échappement

Le tableau suivant illustre, dans divers contextes, les méthodes d'échappement d'un pointeur XPointer contenant une parenthèse non équilibrée, des guillemets doubles et des espaces. Ces exemples font appel au système xpointer (cf. [XPtrXPointer]), car celui-ci admet les chaînes littérales en données de système.

ContexteNotation
Données de système initiales Les données de système xpointer telles que créées initialement :
string-range(//P,"ma binette favorite :-)")
A. XPointerLa parenthèse non équilibrée dans les données de système est échappée, comme l'exige cette spécification :
xpointer(string-range(//P,"ma binette favorite :-^)"))
B. Pointeur dans une adresse IRI Idem que pour A (aucun signe pourcentage trouvé nécessitant un échappement) :
#xpointer(string-range(//P,"ma binette favorite :-^)"))
C. Adresse IRI convertie en adresse URI Les occurrences de guillemets doubles (%22), d'espaces (%20) et de carets (%5E) sont échappées :
#xpointer(string-range(//P,%22ma%20binette%20favorite%20:-%5E)%22))
D. Adresse IRI dans un document XML Guillemets doubles échappés en utilisant la référence d'entité XML prédéfinie &quot; (à supposer que le pointeur apparaisse dans une référence d'IRI dans une valeur d'attribut entre guillemets doubles) :
#xpointer(string-range(//P,&quot;ma binette favorite :-^)&quot;))

Le tableau suivant montre, dans divers contextes, les méthodes d'échappement d'un pointeur XPointer contenant des caractères accentués. Le document XML est supposé codé dans le codage de caractères US-ASCII, qui n'admet pas la présence directe de la lettre é.

ContexteNotation
Données de système initiales Les données de système xpointer telles que créées initialement :
id('résumé')
A. XPointer Le pointeur XPointer (aucun caret ni parenthèse non équilibrée dans les données de système nécessitant un échappement) :
xpointer(id('résumé'))
B. Pointeur dans une adresse URI Idem que pour A (aucun signe pourcentage nécessitant un échappement) :
#xpointer(id('résumé'))
C. Adresse IRI convertie en adresse URI Les occurrences de la lettre é (%C3%A9) sont échappées :
#xpointer(id('r%C3%A9sum%C3%A9'))
D. Adresse IRI dans un document XML Représenté dans le codage de caractères US-ASCII ; les lettres accentuées sont échappées par des références de caractères XML :
#xpointer(id('r&#xE9;sum&#xE9;'))

A Références

A.1 Les références normatives

Infoset
John Cowan et Richard Tobin, rédacteurs. L'ensemble d'information XML. World Wide Web Consortium, 2001.
RFC 2119
Scott Bradner, RFC 2119 : Les mots-clés à utiliser dans les RFC pour indiquer les niveaux d'exigence.Internet Engineering Task Force, 1997.
RFC 2396
Tim Berners-Lee, Roy Fielding et Larry Masinter, RFC 2396 : Les identificateurs de ressource uniformes. Internet Engineering Task Force, 1995.
RFC 2732
Robert Hinden, Brian Carpenter et Larry Masinter, RFC 2732 : Les format des adresses IPv6 littérales dans les URL. Internet Engineering Task Force, 1999.
RFC 2279
François Yergeau RFC 2279 : UTF-8, un format de transformation de ISO 10646. Internet Engineering Task Force, 1998.
RFC 3023
MURATA Makoto, Simon St.Laurent et Dan Kohn, RFC 3023 : Les types de média XML. Internet Engineering Task Force, 2001.
XML
Tim Bray, Jean Paoli, C.M. Sperberg-McQueen et Eve Maler, rédacteurs. Le langage de balisage extensible (XML) 1.0 (2ème édition). World Wide Web Consortium, 2000.
XML-Names
Tim Bray, Dave Hollander et Andrew Layman, rédacteurs. Les espaces de nommage dans XML. World Wide Web Consortium, 1999.
XMLSchema
Henry Thompson et al., rédacteurs. XML Schema - Tome 1. World Wide Web Consortium, 2001.
Unicode
The Unicode Consortium La norme Unicode.

A.2 Les références non normatives

HTML
Dave Raggett, Arnaud Le Hors et Ian Jacobs. La spécification HTML 4.01. World Wide Web Consortium, 1999.
IRI
Martin J. Dürst et Michel Suignard Les identificateurs de ressource internationalisés IRI Projet draft-duerst-iri-01, Internet Engineering Task Force, 2002. Travaux en cours.
RDF
Dave Beckett, rédacteur. La spécification de la syntaxe XML de RDF. World Wide Web Consortium, 2001.
SOAP12
Nilo Mitra et al., rédacteurs. SOAP version 1.2 Parties 0, 1 et 2. World Wide Web Consortium, 2001. Travaux en cours.
XInclude
Jonathan Marsh et David Orchard, rédacteurs. Les inclusions XML (XInclude) version 1.0. Travaux en cours. World Wide Web Consortium, 2001.
XLink
Steve DeRose, Eve Maler et David Orchard, rédacteurs. Le langage de liaison XML (XLink). World Wide Web Consortium, 2001.
XPtrXmlns
Paul Grosso, Eve Maler, Jonathan Marsh et Norman Walsh, rédacteurs. Le système xmlns() de XPointer→vf World Wide Web Consortium, 2003.
XPtrXPointer
Steven DeRose, Eve Maler et Ron Daniel Jr., rédacteurs. Le système xpointer() de XPointer. World Wide Web Consortium, 2002. Travaux en cours.