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.

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

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.

[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].

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.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.

string-range(//P,"ma binette favorite :-)")

xpointer(string-range(//P,"ma binette favorite :-^)"))

#xpointer(string-range(//P,"ma binette favorite :-^)"))

#xpointer(string-range(//P,%22ma%20binette%20favorite%20:-%5E)%22))

#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 é.

id('résumé')

xpointer(id('résumé'))

#xpointer(id('résumé'))

#xpointer(id('r%C3%A9sum%C3%A9'))

#xpointer(id('résumé'))