Channel WebTech

Haben Sie es schon gemacht? Ein Stylesheet in XSLT 2.0 programmiert? Oder eine Abfrage mit XQuery 1.0 geschrieben? Zumindest haben Sie doch schon einmal XPath 2.0 verwendet oder etwa nicht? Dann wissen Sie: es geht auch besser, besser als mit XPath 1.0 und XSLT 1.0.

Note mangelhaft
XSLT war in seiner ersten Version nicht zu gebrauchen, zumindest nicht ohne Hersteller-spezifische Erweiterungen. Denn die Funktionalität von XSLT 1.0 war mehr als beschränkt. Und so packte jeder Anbieter eines XSLT-Prozessors seine eigenen Funktionen oben drauf.

An sich kein Problem, wäre zumindest das "Draufpacken" standardisiert. Doch hierzu fehlte den Editoren der XSLT-Spezifikation der Wille. Immerhin gab es mit dem freien und vom W3C unabhängigen EXSLT-Projekt den Versuch, eine begrenzte Menge an Erweiterungsfunktionen zu standardisieren. Auch hier wurde allerdings noch drauf gepackt oder auch mal weggelassen, das heißt bestimmte EXSLT-Funktionen wurden erst gar nicht implementiert.

Die Folge dieses Draufpackens und Weglassens: ein Standard (XSLT) wurde ad absurdum geführt. Ein Stylesheet lief eben nicht mehr auf allen XSLT-Prozessoren gleichermaßen. Wofür braucht es dann aber noch einen Standard?

Mitschuldig
Keine Frage, dies war nicht die Schuld von XSLT allein. Das Übel steckte schon in XPath, auf dem XSLT aufbaute. Vor XML Schema geboren, kannte es keine Typen und wusste somit beispielsweise auch nichts mit einem Datum anzufangen. Listen – auch das kannte XPath 1.0 nicht.

Ganz anders XPath 2.0:
for $i in (2, 4, 6) return item[$i]

Was überhaupt nicht wie XPath aussieht, ist XPath in der Version 2.0 – und die Grundlage für XSLT 2.0 und XQuery 1.0.

Auf die harte Tour
Doch selbst XPath 2.0 kann weder die Ergebnisknoten sortieren noch diese umstrukturieren. Dafür musste erst XQuery erfunden werden. Das kann all dies und noch viel mehr:

<zahlen>{
  for $item in /items/item
  let $value := -$item/@value
  where $value mod 2 eq 0
  order by $value
  return <zahl>{$value}</zahl>
}</zahlen>

Angewandt auf:

<items>
  <item value="1"/>
  <item value="2"/>
  <item value="3"/>
  <item value="4"/>
</items>

Ergibt:

<zahlen>
  <zahl>-4</zahl>
  <zahl>-2</zahl>
</zahlen>

Okay, das ging auch mit XSLT, fragt sich nur wie. Die Antwort ist etwas länger:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/items">
    <zahlen>
      <xsl:for-each select="item[@value mod 2 = 0]">
        <xsl:sort select="@value" data-type="number" order="descending"/>
        <zahl>
          <xsl:value-of select="- @value"/>
        </zahl>
      </xsl:for-each>
    </zahlen>
  </xsl:template>
</xsl:stylesheet>

Durch die Blume
Keine Frage, XQuery macht es einfach, XML-Datenquellen abzufragen. Es verzichtet dafür auf XML zugunsten einer kompakten und leicht verständlichen Syntax. Die erinnert ein wenig an SQL und tatsächlich stand die etablierte Datenbankabfragesprache Pate für das FLOWR-Konstrukt. "FLOWR", das steht für

for $variable in xpath
let $temp := "wert"
order by $variable/@attribut
where $variable/teil = bedingung
return $variable/ergebnis

Also für die Anfangsbuchstaben der wesentlichen Schlüsselwörter von XQuery:

• for lässt eine Variable der Reihe nach alle Ergebnisknoten eines XPath-Ausdruckes xpath durchlaufen.
• let definiert währenddessen eine temporäre und schreibgeschützte Variable.
• order by bestimmt die Reihenfolge, in der die Knoten (mittels return) ausgegeben werden.
• where filtert die Ergebnismenge: nur diejenigen Knoten, für welche die Bedingung zutrifft, landen in der return-Anweisung.
• return bestimmt die Elemente in der Ergebnismenge der XQuery-Abfrage.

XQuery ist nicht genug
Genug – für heute. Doch reicht das? Keineswegs, denn XQuery kann mehr, viel mehr: verschachtelte Abfragen, multiple Eingabedokumente, eigene Funktionsdefinitionen und und und. Es gibt aber auch Dinge, die XQuery nicht kann: zum Beispiel mehrere Ausgabedokumente erzeugen. Das und vieles mehr kann wiederum XSLT 2.0, weshalb es in zwei Wochen hier seinen großen Auftritt hat. Bis dahin viel Freude und Erfolg mit XQuery wünscht Ihnen

Martin Szugat

Martin Szugat hat schon seit längerem einen Blick auf XQuery geworfen und ist der Meinung: das hätte es schon viel früher geben müssen. Über XQuery hat er bereits ausführlich in seinem Blog aboutxml.de und im dot.net magazin berichtet.