 |
| Figure 14 : Représentation des axes de localisation en tant qu'ensembles. |
Mentionner un axe de localisation dans
une étape de localisation permet d'obtenir un node-set
initial, qui sera ensuite progressivement élagué sous
l'action du déterminant (Node Test) puis des prédicats.
L'idée est donc qu'un axe de localisation représente une
première approximation de ce que l'on veut, en se basant sur
la notion de voisinage du nœud contexte : les enfants,
les frères, les ascendants, etc. : on choisit ce qui se
rapproche le plus du node-set souhaité, quitte ensuite à
filtrer les nœuds en trop. L'approximation doit
toujours se faire par excès, puisqu'il est possible de
filtrer, mais pas d'ajouter.
Etant donné un nœud-contexte, un axe est donc un
ensemble de nœuds, partageant une propriété commune
vis-à-vis du nœud contexte.
Le standard XPath définit treize axes de localisation. Les onze premiers sont construits à partir du nœud contexte sur la base de la relation parent-enfant, ce qui donne un arbre généalogique presqu'identique à l'arbre XML du document source : il ne manque que les nœuds de type attribute et namespace. Précisément, les deux derniers axes correspondent aux attributs et domaines nominaux du nœud contexte, mais ils sont un peu à part, puisqu'il n'y a pas de relation parent-enfant complète entre un nœud et ses attributs ou domaines nominaux (revoir à ce sujet les sections Nœud de type attribute et Nœud de type namespace ).
Voici la liste de ces 13 axes :
On peut représenter graphiquement (voir Figure 14) les ensembles de nœuds que forment les axes (les axes attribute et namespace ne sont pas montrés, et l'un des nœuds element est pris arbitrairement comme nœud contexte).
|
| Figure 14 : Représentation des axes de localisation en tant qu'ensembles. |
| Note |
| La Figure 14 est très largement inspirée d'un schéma extrait de "Practical Transformation Using XSLT and XPath", un support de cours et un livre sans nom d'auteur (copyright 1998-2001 Crane Softwrights Ltd.) dont un extrait est disponible sur www.cranesoftwrights.com/training/. |
On voit sur la Figure 14 que l'axe child d'un élément peut contenir des nœuds de type element, mais aussi de type processing instruction, text, ou comment. Afin de pouvoir trier, on dispose de possibilités de tests adéquats (voir Déterminant (Node Test) ).
D'autre part, les numéros des nœuds sur cette figure correspondent à l'ordre d'apparition de leur balise ouvrante, lors de la lecture séquentielle du document XML correspondant, qui ressemble donc à ceci (le nœud 9 est le nœud contexte) :
<1>
<2>
<3/>
<4/>
<5>
<6>
<7/>
</6>
<8/>
<9>
<? processing-instruction ?>
<10>
<11/>
<12/>
</10>
<!-- commentaire -->
<13>
<14/>
<15/>
<13/>
un texte
</9>
<16/>
<17>
<18/>
</17>
</5>
<19/>
<20/>
</2>
</1>
|
| Remarque |
| Sur la Figure 14, on voit le node-set self, qui ne comporte qu'un seul élément. Pourtant, cet élément possède une descendance assez nombreuse : il est important de réaliser qu'un node-set peut très bien contenir un élément sans pour autant contenir les enfants ou la descendance de cet élément. Mais ce n'est pas interdit non plus : voir par exemple le node-set descendant-or-self. |
Les axes parent, ancestor, ancestor-or-self, preceding, et preceding-sibling ne contiennent
que des nœuds situés avant
(par rapport au nœud contexte) dans l'ordre de lecture
du document : on les nomme axes
rétrogrades.
Tous les autres axes (y compris les axes attribute et namespace) ne contiennent que
des nœuds situés après (par rapport au nœud
contexte) dans l'ordre de lecture du document : on les nomme
axes directs.
L'ordre de lecture du document, pour les attributs et les domaines nominaux, est un peu arbitraire par certains côtés. La règle est celle-ci : les attributs et domaines nominaux viennent après leur élément parent, et avant les enfants de ce parent (ce qui est somme toute parfaitement logique, et correspond effectivement à l'ordre de lecture du document). Ce qui est arbitraire, c'est que les domaines nominaux viennent avant les attributs (c'est une simple convention). Mais aucun ordre de lecture de document n'est défini pour classer les attributs entre eux, ni les domaines nominaux entre eux, car l'ordre dans lequel ils apparaissent n'est pas censé être signifiant (cette propriété est imposée par XML).
On définit aussi une numérotation des nœuds relative à un axe, dont les numéros, appelés indices de proximité, commencent toujours à 1.
Pour un axe direct (par. ex. child ), les indices de proximité augmentent quand on s'éloigne du nœud contexte en suivant l'ordre de lecture du document, alors que pour un axe rétrograde (par. ex. preceding-sibling ), les indices de proximité augmentent quand on s'éloigne du nœud contexte dans l'ordre inverse de lecture du document.
A titre d'exemple, reprenons la Figure 14 , et montrons les indices de proximités pour deux axes rétrogrades (preceding, ancestor-or-self), et pour 2 axes directs (descendant, following). Ces indices de proximité sont montrés sur la Figure 15 (les anciens numéros sont rappelés en plus petit, à l'extérieur de chaque cercle).
 |
| Figure 15 : Indices de proximité. |
| Remarque |
| Ces indices de proximité
servent (entre autres) à fournir, quand besoin est, un
ordre d'énumération. Un node-set, rappelons-le, est un
ensemble, et à ce titre, n'est pas ordonné. Pas
ordonné, cela signifie que l'ordre d'énumération des
éléments n'est pas une propriété discriminante
lorsqu'on cherche à distinguer deux ensembles : les
ensembles {x,y} et {y,x} sont indiscernables. Ceci étant, lorsqu'on énumère un node-set, par exemple pour traiter chacun de ses éléments un par un, il faut bien choisir un premier, un deuxième, etc. jusqu'à un dernier. Donc même si un node-set n'est pas ordonné, il est certainement utile, dans la pratique, d'avoir à sa disposition un algorithme d'énumération. |
La règle, pour un node-set intervenant dans une étape de localisation, est que les indices de proximité donnent l'ordre d'énumération.