Discussion :

[LGnord]

J'ai un document XML qui ressemble à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
<c>
  <a id='1'>xx</a>
  <a id='2'>yy</a>
  <b id='3'>yy</b> 
</c>

//c[a = b] sélectionne le nœud c. En effet, le toString des nœuds '2' et '3' sont égaux (à yy). Par contre, //c[contains(a, b)] ne le sélectionne pas. Pourtant 'yy' est contenu dans 'yy'.

Si maintenant je réduis mon document à:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
<c> 
</c>

//c[a = b] ne sélectionne plus le nœud c. Désormais, //c[contains(a, b)] le sélectionne.


Je ne trouve pas ni dans la Spécification de XPath ni dans la doc de Saxon, la raison de cette différence entre = et contains.

Merci de votre aide.

PS. j'utilise XPath 2.0 avec le 'backward compatibilty mode'

[thelvin]

Je ne trouve pas ni dans la Spécification de XPath ni dans la doc de Saxon, la raison de cette différence entre = et contains.

http://www.w3.org/TR/xpath/#booleans :

An EqualityExpr [...] or a RelationalExpr [...] is evaluated by comparing the objects that result from evaluating the two operands. Comparison of the resulting objects is defined in the following three paragraphs. First, comparisons that involve node-sets are defined in terms of comparisons that do not involve node-sets; this is defined uniformly for =, !=, <=, <, >= and >. [...]

If both objects to be compared are node-sets, then the comparison will be true if and only if there is a node in the first node-set and a node in the second node-set such that the result of performing the comparison on the string-values of the two nodes is true.

Alors que :

http://www.w3.org/TR/xpath/#section-String-Functions

Function: boolean contains(string, string)

http://www.w3.org/TR/xpath/#section-Function-Calls

An argument is converted to type string as if by calling the string function.

http://www.w3.org/TR/xpath/#section-String-Functions

Function: string string(object?)

The string function converts an object to a string as follows:

- A node-set is converted to a string by returning the string-value of the node in the node-set that is first in document order. If the node-set is empty, an empty string is returned.

Nous pouvons donc en déduire :

- Qu'en utilisant un opérateur, les deux node-sets sont comparés en comparant leurs contenus deux à deux. La comparaison globale est évaluée vraie si au moins une de ces comparaisons est vraie.

- Qu'en utilisant une fonction, chaque node-set se réduit au premier node qu'il contient, le convertit en string, et la fonction s'applique sur les deux strings obtenues.

[LGnord]

Merci, tes citations m'ont aidées à généraliser mon cas particulier aux opérateurs/fonctions.

Par contre, je ne comprends pas la logique de ce choix.

[thelvin]

Je ne sais pas, mais j'imagine que :

- Ce fonctionnement pour l'opérateur = est très bon. Ça simplifie beaucoup l'écriture de conditions XPath.

- Quelqu'un a dû penser que ce serait aussi utile pour les autres opérateurs relationnels, ou du moins que ce ne serait pas gênant si les autres opérateurs relationnels marchent comme ça aussi. Et donc ils fonctionnent pareil par cohérence avec =
Personnellement j'aurais plusieurs choses pas très flatteuses à dire aux génies qui ont décidé ça pour !=

- Les appels de fonctions ont ce mécanisme par cohérence avec les autres fonctions qui prennent aussi des string en paramètres, mais ne sont pas des opérateurs relationnels (ne prennent pas 2 opérandes ou renvoient autre chose qu'un booléen.)