Discussion :

[Hibou57]

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 XPath :

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

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 XPath :

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

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

[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 :

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

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

[Hibou57]

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 :

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

/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

[GrandFather]

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 :

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

(/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).

[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 il me faut vraiment un syntaxe plus lègère et plus « naturelle ».

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

[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 (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)

[GrandFather]

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

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

[Hibou57]

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

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

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

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.

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à ? 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, À++

[GrandFather]

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

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.

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.

[Hibou57]

Re-Coucou,

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.

[GrandFather]

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.

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.