[XPath] Des node-sets comme des path-sets ?

Version imprimable

11/07/2007, 02h31
Hibou57

[XPath] Des node-sets comme des path-sets ?
Bonsoir :)

Avec XPath, il est possible de créer des expressions, comparables à des expressions à choix multiple, ... plus précisement, un choix parmis un ensemble de chemin, comme dans l'expression :
Code:

1 2 /document/chapitre/paragraphe | /document/titre
Je me demande, car j'ai un doute à ce sujet, si de la même manière, il est autorisé de créer des expressions de choix multiple, mais sur des noeuds, comme par exemple :
Code:

1 2 /document/(chapitre|notes)/titre
Est-ce que cette dernière expression est légale ?

J'ai constaté qu'Internet Explorer la reconnais, tandis qu'elle est refusée par XSLTProc, d'où la cause de mon doute. Doute emplifié par le fait que je n'ai pas trouvé de telles exemple dans les tutoriels du W3C.

Si quelqu'un(e) a une certitude à ce sujet ...

Bonne nuit :)
11/07/2007, 10h05
GrandFather

Bonjour,

cette construction est en principe interdite par la grammaire XPath définie par le W3C. Pour ton exemple, on pourra utiliser cette expression :

Code:

/document/*[self::chapitre or self::notes]/titre
11/07/2007, 17h53
Hibou57

Citation:

Envoyé par GrandFather

Bonjour,

cette construction est en principe interdite par la grammaire XPath définie par le W3C. Pour ton exemple, on pourra utiliser cette expression :

Code:

/document/*[self::chapitre or self::notes]/titre

Ok, mais comme la grammaire XPath dit aussi que « | » est une autre manière d'écrire « or », je suppose que c'est l'emploie des parenthèses qui est interdite ?

Pour le coup, ça me met une épine dans le pied ça :(
11/07/2007, 18h07
GrandFather

Citation:

Envoyé par Hibou57

Ok, mais comme la grammaire XPath dit aussi que « | » est une autre manière d'écrire « or », je suppose que c'est l'emploie des parenthèses qui est interdite ?

Ce n'est pas l'usage des parenthèses qui est interdit, c'est leur position dans l'expression XPath qui fait l'objet de contraintes. Selon la grammaire XPath, elles ne peuvent apparaître qu'en début d'expression (ou n'importe où dans les prédicats, bien entendu). Ainsi, l'expression suivante est elle tout à fait valide :

Code:

(/document/chapitre|/document/notes)/titre

Petite précision, le | ne désigne pas un 'ou' mais 'union', ce qui n'est pas du tout la même chose. En l'occurrence, cette union se fait entre deux nodesets pour en constituer un seul, sans doublons et dont les noeuds sont ordonnés (dans le sens de lecture du document XML).
11/07/2007, 18h19
Hibou57

Merci, je vais pencher sur la question, mais quoiqu'il en soit, il me faudra trouver une syntaxe plus simple que des choses du genre « *[self::chapitre or self::notes] », parce que ça ne convient pas du tout :roll:il me faut vraiment un syntaxe plus lègère et plus « naturelle ».
11/07/2007, 22h53
Hibou57

J'ai vérifié, et effectivement, l'opérateur « | » est un opérateur d'union. Mais comme il est un opérateur d'union, il n'a pas le même effet si on voit l'expression dans le contexte d'une requête (qui produit un ensemble de noeud), ou si on voit l'expression comme un pattern vis-à-vis duquel on test un chemin (un élément unique). Dans le second cas, on peut le confondre avec un opérateur de choix ordinnaire... ce que j'ai fait.

J'ai confondu un peu avec la syntaxe des DTD SGML.

Si je trouve tout de même une syntaxe plus simple que « *[self::element1 or self::element2 or ...] », alors j'en parlerai ici. Malheureusement, je n'ai rien trouvé pour le moment.
12/07/2007, 00h17
Hibou57

Même s'il ne semble pas avoir trouvé de solution, je marque tout de même le sujet comme « résolu », parce que je me suis résolu à utiliser une syntaxe spécifique, et tant pis si elle ne correspond à rien de standard. Cette syntaxe aura ses avantages propres (notament la simplicité, pour les non-spécialistes), et l'air de rien, elle permettra même d'exprimer des choses apparement impossibles à exprimer en XMLSchema (la surcharge sémantique, par exemple, ou même la redéfinition sémantique).

Voilà, problème c'était, problème ce n'est plus :D (aprés tout, il n'y a pas que les standards dans la vie, il y a aussi la cuisine personelle... tant qu'elle est ouverte est lisible, ça va)
12/07/2007, 09h38
GrandFather

Citation:

Envoyé par Hibou57

Même s'il ne semble pas avoir trouvé de solution, je marque tout de même le sujet comme « résolu », parce que je me suis résolu à utiliser une syntaxe spécifique, et tant pis si elle ne correspond à rien de standard.

Je ne vois pas trop l'intérêt d'établir des normes et des standards, alors... :roll:

D'autant plus que je ne vois pas trop ce qui te gêne dans les deux expressions alternatives que je t'ai données, et qui remplissent la même fonction. Mais ce qui me paraît plus grave, c'est qu'en procédant ainsi tu rends ton code dépendant d'une implémentation particulière, et donc non transportable sur une autre plateforme.

D'autre part, comme cette écriture constitue plus une "anomalie" qu'une "fonctionnalité" selon la norme, tu n'as absolument aucune garantie que cela fonctionnera également dans les versions de MSXML ultérieures à celle que tu utilises et qui peuvent corriger cela. Certes, cela est peu probable, mais je me permets de te rappeler la Loi de Murphy : "Si une erreur identifiée a une chance de se produire, même infime, elle se produira immanquablement". ;)
12/07/2007, 10h42
Hibou57

Citation:

Envoyé par GrandFather

Je ne vois pas trop l'intérêt d'établir des normes et des standards, alors... :roll:

Mon chat est un chat, mais il n'est pas le chat du voisin. Un standard est un outil, et non pas une obligation. Je veux dire que ce n'est pas un dogme, et que comme toute chose : une chose est d'autant mieux utilisé qu'on l'utilise à raison et à bon escient. Utilisé un standard pour utilisé-un-standard n'est d'aucune utilité. Mais utilisé un standard pour de bonnes raisons est une bonne chose, de même que ne pas utilisé un standard pour de bonne raison est aussi une bonne chose. Et enfin, un standard, tout comme une lois, c'est fait pour empêcher de faire des bétises, et on doit y obéir aveuglément quand on ne saurait pas éviter les bétises autrement... mais quand on sait ce que l'on fait...

Citation:

Envoyé par GrandFather

D'autant plus que je ne vois pas trop ce qui te gêne dans les deux expressions alternatives que je t'ai données, et qui remplissent la même fonction.

Leur syntax n'est pas assez naturelle : ces expressions seront le plus souvent destinées à des non-spécialistes, et le seront même probablement fréquement à des « non-féru-d'informatique ».

Citation:

Envoyé par GrandFather

Mais ce qui me paraît plus grave, c'est qu'en procédant ainsi tu rends ton code dépendant d'une implémentation particulière, et donc non transportable sur une autre plateforme.

Ce code, qui utilisera cette syntax, n'existera qu'en petite quantité, et sera totalement indépendant des fichiers XML. De plus, il n'y a même pas lieu de parler de portage sur une plateforme vers une autre, puisque la plateforme est le web, et derrière, un serveur.... totalement transparent donc.

Citation:

Envoyé par GrandFather

D'autre part, comme cette écriture constitue plus une "anomalie" qu'une "fonctionnalité" selon la norme, tu n'as absolument aucune garantie que cela fonctionnera également dans les versions de MSXML ultérieures à celle que tu utilises et qui peuvent corriger cela. Certes, cela est peu probable, mais je me permets de te rappeler la Loi de Murphy : "Si une erreur identifiée a une chance de se produire, même infime, elle se produira immanquablement". ;)

Rien que ça ?! Holala GrandFather... tu me fais le GrandJeux là ? :king: Tu ne trouve pas que tu y va un peu fort et que tu en fais un peu trop ? Ce n'est pas parce que j'ai été piqué par un moustique sur le bord d'un étang qu'à coup sûre je vais mourrire de la fièvre jaune ;)

Rassure toi... il n'y a rien de si grave. Mais en tous cas, merci beaucoup pour tes attentions quand-même :)

Allez, À++
12/07/2007, 11h39
GrandFather

Citation:

Envoyé par Hibou57

Un standard est un outil, et non pas une obligation.

En l'occurrence, il s'agit d'un standard définissant un langage, dont le fonctionnement doit être prévisible et reproductible indépendamment de l'implémentation utilisée. On s'attend, et c'est légitime, à ce que tous les compilateurs Java et C++ correspondent à la syntaxe définie par leurs spécifications respectives, je ne vois pas en quoi cela serait différent pour XPath...

Citation:

Envoyé par Hibou57

De plus, il n'y a même pas lieu de parler de portage sur une plateforme vers une autre, puisque la plateforme est le web, et derrière, un serveur.... totalement transparent donc.

Comme a priori cette syntaxe n'est acceptée que par Internet Explorer, cela signifie que cela doit être le processeur XPath (MSXML) utilisé par ce navigateur qui devra être installé sur le serveur et de préférence dans la même version. Tu introduis donc une contrainte là où il ne devrait pas y en avoir.

Citation:

Envoyé par Hibou57

Tu ne trouve pas que tu y va un peu fort et que tu en fais un peu trop ?

Disons que j'ai un peu d'expérience avec les projets utilisant des outils XML. Je me suis suffisamment battu avec des implémentations qui ne respectaient pas totalement les normes et qui me donnaient donc des résultats différents de ceux que j'attendais, pour m'étonner de la démarche consistant à introduire soi-même et sciemment des variations par rapport à ces normes, parce qu'un produit développé en dépit du bon sens le permet...

En ce qui concerne XPath en particulier, mon expérience est un peu plus étendue puisque j'ai développé ma propre implémentation de processeur XPath, en Python. Je me sens autorisé à l'appeler "Processeur XPath" parce que je me suis justement efforcé de respecter la norme à la lettre, et ainsi je peux garantir à mes éventuels utilisateurs que mon code réagira exactement comme ils s'y attendent. ;)
12/07/2007, 14h18
Hibou57

Re-Coucou,

Citation:

Envoyé par GrandFather

On s'attend, et c'est légitime, à ce que tous les compilateurs Java et C++ correspondent à la syntaxe définie par leurs spécifications respectives, je ne vois pas en quoi cela serait différent pour XPath...

Mais, mais.... je n'ai jamais dit que j'écrivais une application d'interprétation de XPath. Qu'un compilateur d'un langage XYZ doivent respecter le langage XYZ, c'est bien normal, mais le compilateur du langage ABCD n'a que faire de respecter le langage XYZ.

Je crois que je me suis mal exprimé ou que j'ai été ambigü : je pensais utiliser XPath pour certaines fonctionnalités de l'application, mais je me suis décidé à ne finalement pas utiliser XPath, mais quelque chose de similaire dans l'esprit (mais beaucoup plus simple) et avec une syntax qui y ressemble (mais une syntaxe qui exprime des chemins... il y en a foisson dans le monde de l'informatique, XPath n'en a pas le monopol).

De plus il n'y a rien ici de spécifique à Internet Explorer, puisque que ce n'est pas le navigateur qui interprétera ces expressions, mais un programme CGI sur le serveur : c'est pour cela que je parlais de transparence.

Je crois que si je me suis fait tirer l'oreille, c'est parce que je l'ai bien cherché, mais involontairement dans le fond, par la faute d'avoir été trop ambigü ou pas assez explicite.

Milles excuses GrandSage :)

Voilà, j'ai peut-être fait une erreur en donnant l'impression de donner le mauvais exemple, mais ce n'est pas le cas, et je n'encourage pas à ne pas respecter les standard, bien au contraire. Mais je disais seulement que quand un standard ne convient pas à une application, alors il ne faut pas toujours avoir peur de mettre en place sa propre solution, mieux adaptées en vertue de critères pertinant. Surtout que là, ça ne pèse pas trés lourd.
12/07/2007, 15h49
GrandFather

Citation:

Envoyé par Hibou57

Je crois que je me suis mal exprimé ou que j'ai été ambigü : je pensais utiliser XPath pour certaines fonctionnalités de l'application, mais je me suis décidé à ne finalement pas utiliser XPath, mais quelque chose de similaire dans l'esprit (mais beaucoup plus simple) et avec une syntax qui y ressemble (mais une syntaxe qui exprime des chemins... il y en a foisson dans le monde de l'informatique, XPath n'en a pas le monopol).

Ah effectivement, je n'avais pas compris cela... Cela dit, tant que tu n'intègres pas les prédicats, ton interpréteur de "pseudo-XPath" devrait être assez simple à implémenter. Dans le cas inverse, tu te retrouveras confronté aux mêmes difficultés que celles qu'ont rencontrées les concepteurs de XPath, et qui expliquent sa syntaxe actuelle. ;)

Citation:

Envoyé par Hibou57

Mais je disais seulement que quand un standard ne convient pas à une application, alors il ne faut pas toujours avoir peur de mettre en place sa propre solution, mieux adaptées en vertue de critères pertinant.

Absolument d'accord avec toi. :)