XPointer Framework
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.
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 :
Les notes de traduction se présentent dans le texte sous deux formes :
Les liens vers un document du W3C sont doublés vers une traduction quand elle existe :
un document du W3C →vf
Cf. les archives disponibles pour les traductions hébergées sur ce site.
Le World Wide Web Consortium tient un répertoire des traductions disponibles.
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.
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.
Copyright © 2003 W3C® (MIT, ERCIM, Keio), tous droits réservés. Les règles de responsabilité, de nom de marque, d'utilisation des documents et de licence des logiciels du W3C s'appliquent.
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.
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.
A Références
A.1 Les références normatives
A.2 Les références non normatives
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.
[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].
Une chaîne conforme à cette spécification. Cette spécification définit la syntaxe et la sémantique des pointeurs.
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.
Un format spécialisé de données de pointeur qui a un nom et qui est défini dans une spécification.
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.
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.
Une violation des règles syntaxiques de cette spécification, ou bien l'échec d'un pointeur à identifier une sous-ressource.
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.
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).
De la spécification de l'ensemble d'information XML [Infoset] :
item d'information du document
propriété [élément document]
Remarquez que si la ressource XML n'est pas un document mais une entité analysée externe,
alors cette propriété ne sera pas signalée. En réalité, l'ensemble d'information s'agrandira plutôt pour signaler
le (ou les) élément(s) de niveau supérieur dans l'entité comme des propriétés élément racine
ordonnées de l'entité.
propriété [attributs]
propriété [enfants]
propriété [type d'attribut]
propriété [valeur normalisée]
De l'ensemble d'information après validation du schéma (PSVI) de la spécification XML Schema [XMLSchema], les propriétés suivantes des items d'information d'attribut et des items d'information d'élément :
propriété [valeur normalisée de schéma]
Soit :
propriété [définition de type de membre]
propriété [définition de type]
ainsi que les valeurs de leurs propriétés [nom], [espace de nommage cible] et définition de type de base]
Ou bien :
propriété [espace de nommage de la définition de type de membre]
propriété [nom de la définition de type de membre]
propriété [espace de nommage de la définition de type]
propriété [nom de la définition de type]
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.
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.
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].
[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.^^
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 :
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 ;
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 ;
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.
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 :]
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
;
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] ;
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] ;
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
;
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
.
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
n'est pas comprise, ou bien échoue à identifier une
sous-ressource, la partie de pointeur xpointer
sera évaluée. Par contre, si la partie de pointeur element
identifie des sous-ressources, la partie de pointeur xpointer
ne sera pas évaluée.element
#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).
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
(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 xmlns
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.
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.
Les contextes suivants exigent l'application de divers types d'échappement sur les pointeurs 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.
[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 :
Chaque caractère à échapper est converti dans le codage de caractères UTF-8 [RFC 2279] sur un ou plusieurs octets ;
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) ;
Le caractère original est remplacé par la séquence de caractères résultante.
Par exemple, le caractère %
devient %25
.
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 :
Chaque caractère non admis est converti dans le codage de caractères UTF-8 [RFC 2279] sur un ou plusieurs octets ;
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) ;
Le caractère original est remplacé par la séquence de caractères résultante.
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.
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
(cf. [XPtrXPointer]), car celui-ci admet les chaînes littérales en données de système.xpointer
Contexte | Notation |
---|---|
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. XPointer | La 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 " (à supposer que le pointeur apparaisse dans une référence d'IRI dans une valeur d'attribut entre guillemets doubles) :
#xpointer(string-range(//P,"ma binette favorite :-^)")) |
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 é
.
Contexte | Notation |
---|---|
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ésumé')) |
xmlns()
de XPointer →vf World Wide Web Consortium, 2003.xpointer()
de XPointer. World Wide Web Consortium, 2002. Travaux en cours.