Discussion :

[chronos]

Bonjour,

Je suis à la recherche d'une lib xpath qui serait contruite eu dessus d'expat en gardant le mode SAX c'est à dire sans utiliser expat pour construire un DOM.

Le but de la manoeuvre est de pouvoir repondre à des requetes xpath sans passer par un DOM.

Merci pour les eventuelles reponses (Google seche litteralement sur le sujet )

[Gruik]

Salut,

LibXml est une usine a gaz mais integre des fonctionnalités xpath

[chronos]

Salut,

LibXml est une usine a gaz mais integre des fonctionnalités xpath

Oui mais libxml travail sur du DOM pour les query xpath

Bonjour,

je serais très étonné qu'une telle librairie existe.

Le langage XPath est conçu pour des requêtes sur une structure XML arborescente, que l'implémentation sous-jacente de cet arbre soit DOM ou autre chose. Une expression XPath ne peut être évaluée progressivement au même rythme que le parsing SAX d'une instance XML, ou alors au prix de telles contraintes et sur des schémas tellement triviaux que c'en oterait tout intérêt à une tell librairie...

C'est bien le probleme, l'idee d'une librairie xpath/sax est de ne buffurisé que les candidats elligibles de la query xpath. La chose est diffcile je te l'accorde, mais il existe des travaux sur ces problemes.
Constructions de sous arbres DOM avec sax par exemple. ou des solutions sans DOM avec un buffer de travail => http://portal.acm.org/citation.cfm?id=872810

Toutes mes recherches aboutissent à libxml2 (trop lourd pour ce que je veux en faire) ou tinyxml+tinyxpath...

[Gruik]

Non en fait LibXml n'est pas une implementation DOM, ca crée un arbre mais libxml ne propose pas les methodes du dom

[chronos]

Non en fait LibXml n'est pas une implementation DOM, ca crée un arbre mais libxml ne propose pas les methodes du dom

C'est cela oui, un tit abus de language :p, libxml fait des arbres c'est ce qu'il fallait comprendre. Et les arbres sont pas les bienvenus chez moi
Merci pour l'eclaicissement

@grandfather
http://chronosite2.free.fr/XPath.pdf

[Gruik]

Si tu trouves un outil xpath basé sur expat, ça m'interesse

[GrandFather]

C'est bien le probleme, l'idee d'une librairie xpath/sax est de ne buffurisé que les candidats elligibles de la query xpath. La chose est diffcile je te l'accorde, mais il existe des travaux sur ces problemes.

Je n'en doute pas, mais je suis assez sceptique sur les avantages que ça peut comporter. Qu'à la limite il existe un genre de "pattern matching" pour vérifier qu'un élément remonté par SAX soit élligible, je le conçois, mais quid des axes XPath à "mouvement rétrograde" (ancestor, preceding), des prédicats complexes, de l'axe namespace, de tout ce qui va exiger un tel volume de données à bufferiser que l'avantage concurrentiel face à une modélisation en arbre ne va plus être significatif... Ce qui explique d'ailleurs, je pense, qu'il n'existe pas d'implémentation pour un usage industriel de cette techno, sinon ç'aurait fait du bruit.

Il existe effectivement des wrappers PULL autour de parseurs SAX qui génèrent des sous-arbres DOM à partir d'évènements SAX sélectionnés par le développeur, et qui permettent des requêtes XPath sur ces sous-arbres, mais ça reste du DOM (Je ne sais pas s'il en existe pour expat).

Constructions de sous arbres DOM avec sax par exemple. ou des solutions sans DOM avec un buffer de travail => http://portal.acm.org/citation.cfm?id=872810

Je n'ai pas accès au document. Dommage, ç'avait l'air intéressant...

[GrandFather]

Bonjour,

je serais très étonné qu'une telle librairie existe.

Le langage XPath est conçu pour des requêtes sur une structure XML arborescente, que l'implémentation sous-jacente de cet arbre soit DOM ou autre chose. Une expression XPath ne peut être évaluée progressivement au même rythme que le parsing SAX d'une instance XML, ou alors au prix de telles contraintes et sur des schémas tellement triviaux que c'en oterait tout intérêt à une telle librairie...