Existe-t-il un processeur XPath pour le modèle SAX?

Question

Je suis à la recherche d'un XPath évaluateur qui n'a pas de reconstruire l'ensemble du document DOM chercher les nœuds d'un document: en fait l'objet est de gérer une grande quantité de données XML (idéalement plus de 2 go) avec SAX modèle, qui est très bon pour la gestion de la mémoire, et de donner la possibilité de faire des recherches pour les nœuds.

Merci à vous tous pour le soutien!

Pour tous ceux qui disent que c'est pas possible: j'ai récemment, après avoir posé la question, un projet nommé "saxpath" (http://www.saxpath.org/), mais je ne trouve pas la mise en œuvre du projet.

Answer 1

Ma liste actuelle (compilé à partir de web les résultats de recherche et les autres réponses) est:

• http://code.google.com/p/xpath4sax/
• http://spex.sourceforge.net/
• https://code.google.com/p/jlibs/wiki/XMLDog (contient également un tableau des performances)
• http://www.cs.umd.edu/projects/xsq/ (uni versité de projet, morts depuis 10 ans, GPL)
• MIT de Licence en approche http://softwareengineeringcorner.blogspot.com/2012/01/conveniently-processing-large-xml-files.html
• D'autres analyseurs/mémoire les modèles prenant en charge rapide de XPath:
  • http://vtd-xml.sourceforge.net/ ("Le plus rapide du monde XPath 1.0 mise en œuvre.")
  • http://jaxen.codehaus.org/ (contient http://www.saxpath.org/)
  • http://www.saxonica.com/documentation/sourcedocs/streaming/streamable-xpath.html

L'étape suivante consiste à utiliser les exemples de XMLDog et de comparer les performances de toutes ces approches. Ensuite, les cas de test devrait être étendue de la prise en charge des expressions XPath.

Answer 2

Nous avons régulièrement analyser 1GO+ complexe de fichiers XML à l'aide d'un analyseur SAX qui extrait partiel DOM arbres qui peuvent être commodément interrogé à l'aide de XPath. Je stagne à ce sujet ici: http://softwareengineeringcorner.blogspot.com/2012/01/conveniently-processing-large-xml-files.html - les Sources sont disponibles sur github - Licence MIT.

Answer 3

XPath est le travail avec le SAX, et la plupart des processeurs XSLT (surtout Saxon et Apache Xalan) prennent en charge l'exécution des expressions XPath à l'intérieur de Xslt sur un SAX flux sans la construction de l'ensemble des dom.

Ils parviennent à le faire, en très gros, comme suit :

1. En examinant les expressions XPath dont ils ont besoin pour correspondre à
2. La réception d'événements SAX et de tester si ce nœud est nécessaire ou seront nécessaires par l'une des expressions XPath.
3. Ignorant le SAX cas si il n'est d'aucune utilité pour les expressions XPath.
4. Mise en mémoire tampon si c'est nécessaire

Comment ils tampon, il est aussi très intéressant, la cause de certains de créer simplement DOM fragments ici et là, d'autres utilisent très optimisé tables pour la recherche rapide et la consommation de mémoire réduite.

Combien ils parviennent à optimiser dépend en grande partie du type de requêtes XPath qu'ils trouvent. Comme l'a déjà posté Saxon documentation expliquer clairement, les requêtes de ce mouvement "vers le haut" et puis traverse "à l'horizontale" (de frère en frère, sœur) le document nécessite évidemment l'ensemble du document pour y être, mais la plupart d'entre eux nécessitent seulement quelques nœuds pour être gardé en mémoire vive à tout moment.

Je suis assez sûr de cela parce que, quand j'étais encore à faire de chaque jour une webapp à l'aide de Cocon, nous avons eu le XSLT de mémoire, problème chaque fois, nous avons utilisé un "//" expression à l'intérieur d'une transformation XSLT, et, assez souvent, nous avons dû retravailler des expressions XPath pour permettre une meilleure SAX optimisation.

Answer 4

SAX est orienté uniquement vers l'avant, tandis que les requêtes XPath peuvent parcourir le document dans n'importe quel sens (voir les axes parent:: , ancestor:: , preceding:: et preceding-sibling:: ). Je ne vois pas comment cela serait possible en général. La meilleure approximation serait une sorte de DOM à chargement paresseux, mais en fonction de vos requêtes, cela peut vous apporter ou non un avantage - il existe toujours une requête dans le pire des cas, telle que //*[. != preceding::*] .

Answer 5

Désolé, un peu en retard de réponse ici -, il semble que cela est possible pour un sous-ensemble de XPath - en général, il est très difficile en raison du fait que XPath peut correspondre à la fois en avant et en arrière à partir de la "en cours". Je suis conscient de deux projets qui permettent de résoudre dans une certaine mesure, à l'aide de machines à états: http://spex.sourceforge.net et http://www.cs.umd.edu/projects/xsq. Je n'ai pas regardé en détail, mais ils semblent utiliser une approche similaire.