Gibt es einen XPath-Prozessor für das SAX-Modell?

Ich suche nach einem XPath-Evaluator, der nicht das gesamte DOM-Dokument neu erstellt, um nach den Knoten eines Dokuments zu suchen: Eigentlich besteht das Ziel darin, eine große Menge an XML-Daten (idealerweise über 2 GB) mit dem SAX-Modell zu verwalten, was sehr gut für die Speicherverwaltung und bieten die Möglichkeit, nach Knoten zu suchen.

Vielen Dank an alle für die Unterstützung!

Für alle, die sagen, es geht nicht: Ich habe vor kurzem nach der Frage ein Projekt namens “saxpath” gefunden (http://www.saxpath.org/), aber ich kann kein Implementierungsprojekt finden.

Meine aktuelle Liste (zusammengestellt aus den Ergebnissen der Websuche und den anderen Antworten) ist:

• http://code.google.com/p/xpath4sax/
• http://spex.sourceforge.net/
• https://github.com/santhosh-tekuri/jlibs/wiki/XMLDog (enthält auch ein Leistungsdiagramm)
• http://www.cs.umd.edu/projects/xsq/ (Hochschulprojekt, seit 10 Jahren tot, GPL)
• MIT-lizenzierter Ansatz http://softwareengineeringcorner.blogspot.com/2012/01/conveniently-processing-large-xml-files.html
• Andere Parser/Speichermodelle, die schnellen XPath unterstützen:
  • http://vtd-xml.sourceforge.net/ (“Die schnellste XPath 1.0-Implementierung der Welt.”)
  • http://jaxen.codehaus.org/ (enthält http://www.saxpath.org/)
  • http://www.saxonica.com/documentation/sourcedocs/streaming/streamable-xpath.html

Der nächste Schritt besteht darin, die Beispiele von XMLDog zu verwenden und die Leistung all dieser Ansätze zu vergleichen. Anschließend sollten die Testfälle auf die unterstützten XPath-Ausdrücke erweitert werden.

Wir analysieren regelmäßig mehr als 1 GB komplexe XML-Dateien, indem wir einen SAX-Parser verwenden, der partielle DOM-Bäume extrahiert, die bequem mit XPath abgefragt werden können. Ich habe hier darüber gebloggt: http://softwareengineeringcorner.blogspot.com/2012/01/conveniently-processing-large-xml-files.html – Quellen sind verfügbar auf github – MIT-Lizenz.

XPath funktioniert mit SAX, und die meisten XSLT-Prozessoren (insbesondere Saxon und Apache Xalan) unterstützen die Ausführung von XPath-Ausdrücken in XSLTs in einem SAX-Stream, ohne die gesamte dom zu erstellen.

Dies gelingt ihnen grob wie folgt:

1. Untersuchen der XPath-Ausdrücke, die sie abgleichen müssen
2. Empfangen von SAX-Ereignissen und Testen, ob dieser Knoten benötigt wird oder von einem der XPath-Ausdrücke benötigt wird.
3. Ignorieren des SAX-Ereignisses, wenn es für die XPath-Ausdrücke nicht von Nutzen ist.
4. Puffern, wenn es nötig ist

Sehr interessant ist auch, wie sie es puffern, denn während einige einfach hier und da DOM-Fragmente erstellen, verwenden andere sehr optimierte Tabellen für schnelles Nachschlagen und reduzierten Speicherverbrauch.

Wie viel sie optimieren, hängt weitgehend von der Art der XPath-Abfragen ab, die sie finden. Wie die bereits veröffentlichte sächsische Dokumentation deutlich macht, erfordert das Dokument bei Abfragen, die sich “nach oben” bewegen und dann “horizontal” durchlaufen (Geschwister für Geschwister), offensichtlich das gesamte Dokument, aber die meisten von ihnen erfordern nur wenige Knoten, in denen gehalten wird RAM jederzeit.

Ich bin mir ziemlich sicher, denn als ich noch jeden Tag Webapp mit Cocoon erstellte, hatten wir jedes Mal das Problem des XSLT-Speicherbedarfs, wenn wir einen “//etwas”-Ausdruck in einem XSLT verwendet haben, und oft mussten wir XPath-Ausdrücke überarbeiten um eine bessere SAX-Optimierung zu ermöglichen.

SAX ist nur vorwärts, während XPath-Abfragen das Dokument in jede Richtung navigieren können (beachten Sie parent::, ancestor::, preceding:: und preceding-sibling:: Achse). Ich sehe nicht, wie das generell möglich wäre. Die beste Annäherung wäre eine Art Lazy-Loading DOM, aber abhängig von Ihren Abfragen kann dies Ihnen Vorteile bringen oder auch nicht – es gibt immer eine Worst-Case-Abfrage wie //*[. != preceding::*].

Entschuldigung, eine etwas späte Antwort hier – es scheint, dass dies für eine Teilmenge von XPath möglich ist – im Allgemeinen ist es sehr schwierig, da XPath vom “aktuellen” Punkt sowohl vorwärts als auch rückwärts abgleichen kann. Mir sind zwei Projekte bekannt, die es mithilfe von Zustandsautomaten bis zu einem gewissen Grad lösen: http://spex.sourceforge.net & http://www.cs.umd.edu/projects/xsq. Ich habe sie mir nicht im Detail angeschaut, aber sie scheinen einen ähnlichen Ansatz zu verwenden.

Ich werde einen Stecker für ein neues Projekt von mir namens AXS einwerfen. Es ist bei https://code.google.com/p/annotation-xpath-sax/ und die Idee ist, dass Sie Methoden mit XPath-Anweisungen (nur Vorwärtsachsen) annotieren und sie werden aufgerufen, wenn sich der SAX-Parser an einem Knoten befindet, der ihm entspricht. Also mit einem Dokument

<doc>
<nodes>
  <node name="a">text of node 1</node>
  <node name="b">text of node 2</node>
  <node otherattr="I have attributes!">text of node 3</node>
</nodes>
</doc>

du kannst Dinge tun wie

@XPath("/nodes/node")
void onNode(String nodeText)
{
  // will be called with "text of node [123]"
}

oder

@XPathStart("//node[@name=""]")
void onNode3(Attrs node3Attrs) { ... }

oder

@XPathEnd("/nodes/node[2]")
void iDontCareAboutNode3() throws SAXExpression
{
  throw new StopParsingExpression();
}

Natürlich ist die Bibliothek so neu, dass ich sie noch nicht einmal veröffentlicht habe, aber sie ist MIT-lizenziert, also probieren Sie sie einfach aus und sehen Sie, ob sie Ihren Anforderungen entspricht. (Ich habe es geschrieben, um HTML-Screenscraping mit ausreichend geringem Speicherbedarf durchzuführen, damit ich es auf alten Android-Geräten ausführen kann…) Wenn Sie Fehler finden, lassen Sie es mich bitte wissen, indem Sie sie auf der Googlecode-Site einreichen!

Es gibt SAX/StAX-basierte XPath-Implementierungen, aber sie unterstützen nur eine kleine Teilmenge von XPath-Ausdrücken/-Achsen, hauptsächlich aufgrund der Vorwärtsnatur von SAX/StAX. Die beste Alternative, die mir bekannt ist, ist Extended VTD-XML, es unterstützt vollständiges xpath, partielles Laden von Dokumenten über Mem-Map.. und eine maximale Dokumentgröße von 256 GB, aber Sie benötigen 64-Bit-JVM, um das volle Potenzial auszuschöpfen