Channel WebTech

Sie haben die Qual der Wahl: XSLT 2.0 oder XQuery 1.0 – eine schwierige Entscheidung. Oder doch nicht? Beide haben ihre Vor- und ihre Nachteile und damit ihre ganz eigenen Einsatzgebiete.

Mensch oder Maschine
XML ist leicht lesbar – für eine Maschine und selbstverständlich nicht für den Menschen. Der kann es zwar verstehen, tut sich aber schwer, mit den vielen spitzen Klammern, den Metainformationen und der tiefen Verschachtelung.

Die Maschine tut sich leicht: keine Doppeldeutigkeiten und wenig Entscheidungsmöglichkeiten. Und so ist auch XSLT: wohlgeformt, aber unverständlich. Das erleichtert zwar die Werkzeugunterstützung, macht aber das Schreiben von Stylesheets mühselig.

Ganz anders XQuery. Seine Devise lautet: "Humans first!" Dem entsprechend verzichtet XQuery auf XML zugunsten der bekannten FLOWR-Syntax und das liest sich dann wesentlicher einfacher, weil es näher an der natürlichen Sprache ist.

Bäume oder Muster
Ganz fair war das jetzt nicht. XSLT hat es ja auch schwerer. Statt einfacher Funktionen nutzt es komplexe Vorlagen und Muster – template-Elemente mit XPath-Ausdrücken. Auch darin unterscheiden sich XQuery und XSLT fundamental: die atomaren Einheiten von XQuery sind Funktionsausdrücke, die von XSLT eben die Templates.

Dadurch ergibt sich ein weiterer Unterschied zwischen XQuery und XSLT, der des Verarbeitungsmodells. XQuery wertet verschachtelte Funktionsaufrufe aus: von oben nach unten. Die Eingabe ist XML, die Ausgabe ist XML und die Verarbeitungsreihenfolge bestimmt der XQuery-Ausdruck.

Das Modell ist verständlich und dementsprechend einfach in der Anwendung – solange die Aufgabe es ebenfalls ist. Doch gerade bei einer umfangreichen Restrukturierung der XML-Daten kann es dagegen mit XQuery schwierig werden, denn dann wird auch der Funktionsausdruck umfangreich und damit unhandlich. Neue Anwendungsfälle müssen zudem sorgsam in das Geflecht aus Funktionsaufrufen eingeführt werden – ein steter Quell für Fehler.

XSLT dagegen vergleicht das Eingabedokument mit den Mustern aus den Vorlagen: eines nach dem anderen, bis eines zutrifft. Das nennt sich Pattern-Matching und ist eine elegante Technik, um komplexe Daten zu verarbeiten, also beispielsweise in ein anderes Format zu transformieren. Getrieben wird der Prozess von den Eingabedaten. Das Stylesheet sagt dem XSLT-Prozessor nur, wie er zu reagieren hat.

Jede Vorlage funktioniert dabei als abgeschlossener (Building-)Block – das reduziert die Komplexität. Zudem ist aus dem Inhalt der Vorlage meist unmittelbar ersichtlich, wie die Ausgabe aussieht. Variabilität in der Eingabe begegnet der Stylesheet-Entwickler mit Mustern unterschiedlicher Spezifität – vom Speziellen zum Allgemeinen ordnet er die Vorlagen an. Neue Fälle lassen sich einfach abdecken, durch ein weiteres Template.

Optimierung oder Flexibilität
Erweiterbarkeit und Wartbarkeit sind wichtige Faktoren, denn sie beschleunigen die Entwicklung beziehungsweise Fehlerbereinigung. Geschwindigkeit gewinnt. Doch wer gewinnt bei der Ausführungsgeschwindigkeit? Ein direkter Vergleich zwischen XSLT und XQuery ist unfair, denn es kommt auf den konkreten Fall und die jeweilige Implementierung an.

Einer, der es wissen muss, weil er selbst am Bau eines XQuery-Prozessors beteiligt war, ist Michael Rys, Mitglied der W3C-Arbeitsgruppe für XQuery und bei Microsoft verantwortlicher Programmmanager für XML im SQL Server. Er sagt:

XSLT-Templates werden in komplexe if-then-else-Bäume umgesetzt. Die sind schwierig zu optimieren. XQuery ist auf Grund seiner Art einfacher zu optimieren.

Optimierbarkeit ist ein Unterschied, der zwar im besten Fall messbar, aber eben nicht offensichtlich ist. Ganz anders sieht es bei der Ein- und Ausgabe eines XSLT- beziehungsweise Query-Prozessors aus: In beiden Fällen geht mindestens ein XML-Dokument rein (es darf auch eine XML-Datenbank oder jede andere Datenquelle sein, die sich als XML InfoSet darstellt) und raus kommt bei XQuery genau ein XML-Dokument oder zumindest ein XML-Fragment.

Bei XSLT kann es dagegen ein XML-Dokument oder jedes andere textbasierte Format sein. Das ist ein Alleinstellungsmerkmal von XSLT, aber es ist nicht das einzige: Dank des result-document-Elements ist XSLT im Unterschied zu XQuery in der Lage, mehr als ein Ausgabedokument zu erzeugen.

Transformation oder Aggregation
In einem weiteren, wesentlichen Punkt unterscheiden sich die beiden Sprachen: in ihrem Anwendungszweck. Laut Spezifikation "ist [XSLT] eine Sprache, um XML-Dokumente in andere XML-Dokumente zu transformieren".

Die Vorlagen-basierte Funktionsweise, die Möglichkeit, sowohl XML als auch reinen Text sowie mehr als ein Dokument auszugeben und die XML-Syntax machen es einfach, für ein Format ein Stylesheet zu entwerfen, welches beispielsweise die Anzeige in HTML übernimmt. Im besten Fall existiert für das Format ein XML-Schema, sodass direkt aus der XSD-Datei eine erste Grobvorlage für das Stylesheet generiert werden kann – natürlich mittels eines weiteren XSLT-Stylesheets.

Bei der Spezifikation von XML Query heißt es dagegen: "[XQuery] wurde derart entworfen, dass es auf viele Arten von XML-Datenquellen anwendbar ist."

Dank seiner einfachen Syntax können XML-Datenbankabfragen ad-hoc formuliert werden und liefern selbst bei umfangreichen Datenmengen dank der guten Optimierbarkeit schnell Ergebnisse, die sich dann in einer XML-Pipeline zum Beispiel mit XSLT weiterverarbeiten lassen.

Sieg auf ganzer Linie
And the winner is: der Anwender, denn er kann je nach Anforderung das passende Werkzeug wählen. Und Qualen entstehen dabei nur, wenn die Anforderungen unklar sind. Die Entscheidung für XSLT 2.0 oder für XQuery 1.0 ergibt sich dann ganz von alleine.

Martin Szugat hat sich bereits entschieden, für ein Sowohl-Als-Auch und träumt von einem XSLT 3.0 mit integriertem XQuery 2.0. Oder doch anders herum?