Messerscharf

Anfang April hat das World Wide Web Consortium (W3C) gleich zwölf neue Texte veröffentlicht, die sich mit XSLT, XPath und XQuery beschäftigen. Umfang und Mächtigkeit von XSLT und XPath sind damit deutlich angestiegen: Ließ sich die XSLT-1.0-Spezifikation noch auf 75 Seiten und XPath 1.0 auf 30 Seiten drucken, sieht es nun ganz anders aus: Mit 74 Seiten schlägt XPath 2 zu Buche. XSLT 2 bringt es auf 204 Seiten. Das ist allerdings nur die halbe Wahrheit. Waren in der Version 1 die Funktionen, Operatoren und das Datenmodell noch innerhalb von XPath beschrieben, so sind sie nun ausgelagert. Die Folge: Weitere 159 + 82 Seiten. Ergänzt man die 135 Seiten der neuen Volltext-Features von XPath, ergibt sich ein Verhältnis von 30 Seiten (Version 1) zu 449 Seiten (Version 2). Bei XSLT fällt es bescheidener aus: 75 zu 204. Alle Angaben beziehen sich selbstverständlich auf dieselben Schriftarten- und -größeneinstellungen im Browser.

Hierbei ist hervorzuheben, dass es große Überdeckungen zwischen XPath 2 und XQuery 1 gibt. XPath 2 ist eine Teilmenge von XQuery und deshalb teilen sich beide Sprachen die Funktionen, Operatoren und das Datenmodell. Wer sich zusätzlich in XQuery einlesen möchte, muss sich auf lediglich 167 weitere Seiten einstellen (eventuell noch 60 für die XML-Syntax von XQuery).

Angesichts dieses Umfangs ist klar, dass der vorliegende Artikel nicht in alle Details eintauchen kann. Schwerpunkt soll deshalb die Frage sein, was XSLT 2 gegenüber Version 1 mehr bietet. Den Zusammenhang zwischen den drei genannten Sprachen beschreibt die XPath-Spezifikation wie folgt: „XPath wurde entwickelt, um in einer Wirtssprache [Host Language] wie XSLT 2.0 oder XQuery 1.0 eingebettet zu werden. XPath besitzt eine natürliche Teilmenge, die für das Matching benutzt werden kann (der Test, ob ein Knoten zu einem Muster passt oder nicht); diese Verwendung von XPath ist in XSLT 2.0 beschrieben. XQuery Version 1.0 ist eine Erweiterung von XPath Version 2.0. [...]“

Praktische Erweiterungen

Die Neuerungen in XSLT 2 scheinen vor allem durch zwei Dinge beeinflusst zu sein: Einerseits handelt es sich um Einflüsse aus anderen Spezifikationen, andererseits sind viele praktische Bedürfnisse in den neuen Standard eingeflossen. Nach der Veröffentlichung von XSLT 1 sind schnell Erweiterungen jenseits der W3C-Spezifikation erschienen. Eine der ersten unterstützte mehrere Ausgabedokumente.

Ursprünglich sah das Verarbeitungsmodell so aus, dass XSLT genau ein Eingabedokument in genau ein Ausgabedokument transformiert (siehe die Abbildung). Die automatische Erzeugung von ganzen Websites aus einer XML-Instanz verlangte jedoch nach der Erzeugung vieler Dateien. Hier gab es bislang zwei Optionen: Entweder steuert man den XSLT-Prozessor von außen mit einem Parameter und lässt für jede auszugebende Seite eine eigene Transformation laufen - oder man verwendet eine proprietäre Erweiterung. Zwei bekannte XSLT-Engines, Xalan und Saxon, erlauben Letzteres in der Form

<!-- Saxon: -->
<saxon:output href="dateiname">...</saxon:output>
<!-- Xalan: -->
<redirect:write select="dateiname">...</redirect:write>

In XSLT 2 sieht die Ausgabe von Dokumenten nun so aus:

<!-- XSLT 2: -->
<xslt:result-document href="dateiname">...</xslt: result-document>

In allen gezeigten Fällen geben die Prozessoren den Inhalt der jeweiligen Elemente in die mit href beziehungsweise select bezeichnete Datei aus. Notwendig ist diese Vorgehensweise nicht. Es gibt nach wie vor einen primären Ausgabestrom wie in XSLT 1. So erklärt sich die unterschiedliche Darstellung der Ausgabeeinheiten in der Abbildung 1.

Von Exslt.org beeinflusst

Neben den proprietären Erweiterungen, die einige XSLT-Engines unterstützen, hat sich vor einigen Jahren Exslt.org formiert. Die von Entwicklern getriebene Initiative bemüht sich um eine Standardisierung und Dokumentation von XSLT-Erweiterungen. Einige der durch Exslt.org dokumentierten und schon implementierten Erweiterungen der Version 1 sind in XSLT 2 als Einflüsse wiederzufinden. Eine derartige Neuerung ist die Möglichkeit, Funktionen zu definieren. In XSLT-2-Syntax sieht eine Funktionsdefinition wie Listing 1 aus.

<xslt:function name="str:reverse" as="xs:string">
  <!-- Dreht die Reihenfolge der Worte von 'sentence' um -->
  <xslt:param name="sentence" as="xs:string"/>
  <xslt:choose>
    <xslt:when test="contains($sentence, ' ')">  
      <xslt:sequence 
        select="concat(str:reverse(substring-after($sentence, ' ')), ' ',
                substring-before($sentence, ' '))"/>
    </xslt:when>
    <xslt:otherwise>
      <xslt:sequence select="$sentence"/>
    </xslt:otherwise>
  </xslt:choose>
</xslt:function>

str:reverse (str ist ein wählbares Namensraumpräfix) erwartet einen Parameter sentence vom (XML-Schema-)Typ string und liefert ein Ergebnis dieses Typs. Wie das Listing zeigt, können XPath-Ausdrücke die selbstgeschaffenen Funktionen schlicht verwenden. Letztere erweitern die Bibliothek der Grundfunktionen.

Exslt.org umfasst unter anderem eine Reihe von Funktionen für die Verarbeitung von Datum und Zeit. Der Entwurf für XQuery- und XPath-Funktionen sowie -Operatoren führt im Inhaltsverzeichnis nun 67 Funktionen und Operatoren zu diesem Bereich. Sie arbeiten auf den korrespondierenden Datentypen aus XML-Schema. XSLT 2 ergänzt die große Sammlung um drei Funktionen zur Formatierung von Datum und Zeit: format-dateTime, format-date und format-time. Das W3C hat hier umfangreiche Steuermöglichkeiten zur Anpassung der Datumsausgabe an nationale, sprachliche und kulturelle Besonderheiten definiert. So sind beispielsweise für die Wahl des zugrunde liegenden Kalenders 28 Bezeichner vorgegeben, die von „AD“ (Anno Domini, christlicher Kalender) über „AM“ (Anno Munid, jüdischer Kalender) bis zu „VS“ (Vikrama-Samvat-Ära, siehe www.w3.org/TR/2005/WD-xslt20-20050404/) führen. Wie ein Datum in einer gewählten Sprache auszugeben ist, darf immer noch die Implementierung bestimmen. Als Beispiel nennt die Spezifikation explizit die deutschen Bezeichnungen Samstag versus Sonnabend. Das W3C gibt des Weiteren nicht vor, welche Sprachen und Kalender eine Software tatsächlich implementieren muss.

Den vollständigen Artikel finden Sie in der Print-Ausgabe der 8/2005. Ausserdem enthält das August-Heft einen Artikel zu den unterschiedlichen Möglichkeiten, XML zu nutzen, sowie einen zu XML innerhalb von .Net 2.0. (hb)