XSL: die Stil-Sprache für XML

Im Gegensatz zur in allen Browsern fest verdrahteten Hypertext Markup Language (HTML) läßt sich für die Extensible Markup Language (XML, siehe dazu [#lit2 [2]]) nicht festlegen, wie Elemente darzustellen sind. Grund: das Hauptmerkmal von XML ist die unendliche Menge möglicher Elemente - wie sollen Browser-Hersteller für all diese ein Layout vorsehen ... Aber schon für HTML ist es eigentlich unerwünscht, das Layout im Web-Dokument vorzuschreiben; dafür sind die Cascading Style Sheets (CSS) seit Ende 1996 spezifiziert - und in den 4er-Versionen beider 'großen' Browser mehr oder weniger implementiert.

Vorab sei betont, daß hinsichtlich XML, vor allem aber XSL noch vieles im Fluß ist. Noch gibt es keinen offiziellen Entwurf für die Stil-Sprache, sondern nur den eingereichten Vorschlag. Ob die ebenfalls dem W3C vorgelegte Sprache Spice (eine ECMAScript-Erweiterung, die von HP kommt) vielleicht noch in XSL integriert wird, steht in den Sternen.

Für XML muß letztlich eine Stil-Sprache her, beziehungsweise es gibt bereits eine - wenn nicht gar mehrere. In der Märzausgabe der iX [#lit1 [1]] war zu lesen, wie James Clarks DSSSL-Engine (DSSSL: Document Style Semantics and Specification Language) Jade XML-Dokumente nach HTML konvertiert beziehungsweise die Sicht auf Teile des Originaldokuments ermöglicht. DSSSL gilt allerdings - ebenso wie SGML, für die die Sprache gedacht ist - als recht kompliziert, was die Akzeptanz deutlich erschweren dürfte.

Noch im Vorschlagsstadium

Im August letzten Jahres haben Vertreter von Microsoft, ArborText, Inso sowie Henry Thompson und James Clark einen Vorschlag für XSL beim W3C eingereicht, den das W3C jetzt offensichtlich diskutiert (Ende Januar hat eine Arbeitsgruppe getagt). Als Technology Preview hat Microsoft ein Tool namens msxsl freigegeben, das XML-Daten per XSL-Anweisungen in HTML konvertiert. Allerdings ist nach MS-eigenen Angaben noch nicht der ganze XSL-Entwurf implementiert; was stimmt: schon ein Umlaut im Style Sheet läßt msxsl abstürzen ...

Auf jeden Fall soll XSL zweierlei beinhalten: eine Implementierung der DSSSL-O-Eigenschaften - einer für Online-Zwecke abgespeckten Version der eigentlichen DSSSL - sowie die Möglichkeiten von CSS. Das heißt aus praktischer Sicht, daß XSL zwar die W3C-Vorgabe erfüllt, in der XML-Stil-Sprache DSSSL-Funktionen zu implementieren, aber gleichzeitig hat die Arbeit an XSL ergeben, daß ein paar Abweichungen und Ergänzungen in Abgrenzung zu DSSSL erforderlich sind: Zum einen sind XSL-Style-Sheets in XML-Notation gehalten. Einfacher ausgedrückt, soll (fast) alles in spitzen Klammern (<mein-element/>) stehen, was bedeutet: keine Scheme- beziehungsweise Lisp-Syntax, wie in [#lit1 [1]] nachzulesen.

Außerdem ist der Flow Object Tree um Elemente erweitert worden, die die Einbeziehung von HTML- und CSS-Objekten erlauben. Schließlich sind Ergänzungen zur Konstruktionssprache ([#down siehe unten]) geplant. Alle drei Abweichungen, so die Entwickler, sind für eine Ergänzung DSSSLs vorgeschlagen; kommen sie zum Tragen, ist DSSSL eine Obermenge von XSL (weil erstere unter anderem natürlich nach wie vor runde Klammern um Elementnamen erlaubt, während die runden Klammern in XSL nur in Scripts vorkommen, siehe auch den Kasten).

Zur Erinnerung: XML ist als Teilmenge von SGML dazu gedacht, beliebig ausgezeichnete Daten ins Web zu transportieren. Angesichts der Komplexität von SGML (Standard Generalized Markup Language) ist XML genau für diesen Zweck entwickelt worden. Zur Sache: XSL ist dazu gedacht, in XML vorliegende Daten in ein Format zu wandeln, das sich leicht darstellen läßt. Momentan heißt das Format HTML, andere sind aber durchaus denkbar.

Stil muß jede Datei haben

CSS als Stil-Sprache ist für XML nicht ausreichend. Zwar läßt sich für beliebige Elemente festlegen, wie sie aussehen sollen, aber XSL enthält nicht nur Funktionen, die über die Möglichkeiten von CSS hinausgehen, sondern die Sprache erlaubt darüber hinaus, eigene Funktionen zu definieren und im Style Sheet zu nutzen ([#down2 siehe unten]).

XSL selbst besteht aus zwei Komponenten: Konstruktionsregeln und Stilregeln. Im einfachsten (eigentlich zu einfachen) Fall kann eine Konstruktionregel aussehen wie Listing 1: hier ist lediglich festgelegt, daß der Inhalt des XML-Dokuments in die für HTML notwendigen Elemente eingefaßt sein soll. Es sagt nichts darüber aus, wie die einzelnen Elemente (<children/>, das Äquivalent zu (process-children) in DSSSL) aussehen sollen, denn dafür wären weitere Regeln notwendig.

Wer XML-Daten nach HTML wandelt, will natürlich Stilvorgaben für einzelne Elemente machen. Um ein halbwegs nachvollziehbares Beispiel zu haben, sei hier auf die in [#lit1 [1]] beschriebene Autorensammlung zurückgegriffen. Im ersten Schritt soll dasselbe geschehen wie in genanntem Artikel: ein Inhaltsverzeichnis zu generieren erfordert nur einen Bruchteil der Daten, und es ist wesentlich schneller zu übertragen als die gesamten Daten, die Megabytes umfassen können. Vorausgesetzt, im XML-Dokument ist keinerlei Überschrift als Element enthalten, sollte man diese für die Webseite im Style Sheet vorsehen - außerdem den üblichen Hinweis auf die letzte Veränderung nicht vergessen. Demnach könnte der Inhalt von BODY im nächsten Schritt Listing 2 sein.

Ohne Muster gibt's keine Aktion

Bei der Verwendung von HTML-Elementen im Style Sheet muß man darauf achten, die XML-Notation zu verwenden: alle leeren Elemente müssen entweder wie nichtleere behandelt werden oder den Schrägstrich vor der schließenden spitzen Klammer enthalten (üblich ist letzteres):

<HR/>
<children/>

Konstruktionsregeln bestehen ihrerseits wiederum aus zwei Teilen: einem Muster (pattern) und einer Anweisung (action). Steht im Style Sheet

<rule>
  <target-element type='name'/>
  <DIV>
  <children/>
  </DIV>
</rule>

sucht der Parser nach dem Element name und faßt dessen Kindelemente in einer <DIV> zusammen: allerdings dergestalt, daß jedes Element in einer Abteilung steht. Eine Anmerkung zur Schreibweise: die Verfasser von Microsofts XSL-Tutorial (www.microsoft.com/xml/xsl/tutorial/contents.htm) weisen darauf hin, daß alle HTML-Objekte in Großbuchstaben, die CSS-Eigenschaften hingegen in Kleinbuchstaben gehalten sein sollen (weil XML - beziehungsweise msxsl zwischen beiden einen Unterschied mache: case sensitive), damit beim Parsing keine Verwirrung entsteht, wenn Attribute beider zufällig denselben Namen haben.

Konstruktionsregel fürs Inhaltsverzeichnis

Muster lassen sich komplizierter schreiben als in obigem Beispiel. Listing 3 enthält die notwendigen Zeilen, um für das genannte Inhaltsverzeichnis die Autorennamen auszugeben. Schon für eine so rudimentäre Ausgabe wie ein Inhaltsverzeichnis ist natürlich etwas mehr erforderlich: eine Konstruktionsregel muß beschreiben, wie mit dem Element NAME umzugehen ist. Listing 3 zeigt eine Möglichkeit.

Auf das Muster Element mit der Bezeichnung name folgt die Aktion DIV, in der die Kindelemente abgearbeitet werden. An dieser Stelle wird es insofern kompliziert, als Scripting ins Spiel kommt. XSL soll Unterstützung für ECMAScript enthalten (vor der Standardisierung als JavaScript bekannt) - und zwar sowohl durch eingebaute Funktionen als auch durch selbstgeschriebene Scripts. Die hier verwendeten ancestor und getAttribute() gehören zu den in XSL schon vorhandenen Funktionen (siehe den Kasten) und ermöglichen es, vom Element name (im Klammerausdruck: this) aus auf ein Attribut des in der Hierarchie darüber stehenden author zuzugreifen (named). Der Ausdruck + '.html' hängt die übliche Dateiendung an das Attribut. Vorsicht ist geboten, weil XSL in der derzeitigen MS-Implementierung nicht mit den Attributen ID und CLASS umgehen kann. Deshalb heißt das in Frage stehende hier named statt id.

Ganz ist es damit nicht getan. Da das Ausgangsdokument, die Autorensammlung, weitere Elemente samt Daten enthält, muß deren Bearbeitung ausgeschlossen sein. Und dem Vornamen sollte ein Leerzeichen folgen ...

Listing 4 enthält neben dieser Vorgabe zwei Varianten, die jeweils verhindern, daß Elemente ausgegeben werden: die Nullanweisung oder ein explizites <empty/>. Die Umschreibung des Leerzeichens durch   ist notwendig, weil die Eingabe eines normalen Leerzeichens im Style Sheet unberücksichtigt bleibt.

Mit Stil um die Ecke nach HTML

Beim Blick auf die XSL-Listings fällt auf, daß jedes aufs Neue vorschreibt, wie die einzelnen HTML-Elemente auszusehen haben. Auch die mit Hilfe der Style Sheets generierten Web-Dokumente enthalten jeweils die Stilanweisungen. Im Grunde handelt es sich hier um einen Rückschritt hinter die Cascading Syle Sheets, denn die bewirkten ja gerade, daß ein Style Sheet (oder mehrere) für beliebig viele Dokumente die notwendigen Vorgaben enthielt.

Zwar sehen die einführenden Dokumente diesen Auszeichnungsschwall in allen mir bekannten Beispielen vor, aber der von Microsoft zur Verfügung gestellte msxsl klagt nicht, wenn ein XSL-Dokument statt der vielen Einzelvorgaben nur eine CSS-Datei als Referenz enthält:

<HEAD> 
<LINK rel="stylesheet" type="text/css" 
    href="toc.css"/> 
</HEAD> 

Wie oben gilt: im Element LINK den Slash vor der schließenden Klammer nicht vergessen. Und: auch in der XSL-Datei kann man Elementen Klassen zuweisen (Unterschiede zwischen verschiedenen Überschriften oder Absätzen machen).

Außer den Konstruktionsregeln können Entwickler Stilregeln vorsehen, aber auch die bewirken, daß die Anweisungen in allen Einzeldokumenten stehen statt zentral verwaltet werden zu können. Für Stilregeln gilt wie für Konstruktionsregeln, daß der Parser sie danach untersucht, wie spezifisch sie sind. Das heißt, es ist möglich, unterschiedliche Formate für ein Element vorzusehen, indem Farben, Schrifttypen et cetera beispielsweise von einem Attributwert abhängig sind. Zum entsprechenden Algorithmus siehe das Microsoft-Papier online.

In Listing 5 steht, daß im Normalfall die Farbe des Elementwertes von begebenheit ein Grauwert (#666666) ist; nur wenn das Attribut kateg den Wert wichtig trägt, soll das Element in Fettdruck und roter Farbe ausgegeben werden.

Mehr als CSS: Scripting-Möglichkeiten

Oben war zu lesen, daß XSL letztlich die Funktionen von DSSSL-O implementieren soll. Momentan heißt das bezogen auf msxsl: ein paar Funktionen sind eingebaut, eigene lassen sich definieren. Die vorhandenen sind im entsprechenden Kasten aufgeführt; wie sie zu verwenden sind, zeigen folgende kurze Beispiele.

Insbesondere für Gliederungen komplexer Dokumente (etwa Bücher) sind ein paar Funktionen da: formatNumberList und hierarchicalNumberRecursive ergeben beide eine Zahl: die Liste der Elemente beziehungsweise Kindelemente ab einer bestimmten Hierarchiestufe.

Auf die Autoren bezogen ließe sich leicht einfügen, der wievielte der jeweils behandelte ist, indem dem Namen die entsprechende Zahl vorangestellt wird (siehe Listing 6). Es zeigt eine von zwei Möglichkeiten, die eingebauten Funktionen zu verwenden: eingebettet in das Element <eval>. Die andere war bereits in Listing 3 zu sehen. Sie wird vor allem dann genutzt, wenn innerhalb von HTML-Elementen Wertzuweisungen vorgenommen werden sollen (wie oben ein Parameter für das href-Attribut). In Listing 6 bedeuten die Parameter '1' und '.', daß es sich um arabische Ziffern mit dem Punkt als Trennzeichen handeln soll (Buchstaben wären ebenfalls möglich).

Schließlich können Entwickler selbgeschriebene Funktionen verwenden. Listing 7 zeigt eine einfache, die voraussetzt, daß ein Element (etwa month) nur Zahlen enthält, die in Wörter zu wandeln sind. Denkbar wäre hier, verschiedene Sprachen vorzusehen. Das würde für die Funktion showMonth() einen zweiten Parameter (die Sprache) und eine gesonderte Abfrage bedeuten.

Ein solches Script muß im Style Sheet durch <define-script>...</define-script> eingeschlossen sein, und darin wiederum in einer CDATA-Sektion stehen (<![CDATA[Script]]>). Dies gewährleistet, daß die Funktion(en) nicht als XML-Daten ausgewertet werden, sondern beim Konvertierungsprozeß zur Ausführung kommen. Sie sind nicht mehr Bestandteil des HTML-Dokuments.

Scripts zu integrieren ist auch auf eine andere Weise möglich: durch das Flow Object SCRIPT, das wie von JavaScript her bekannt im HEAD eingebettet sein soll. Im Unterschied zu oben genannter Variante wird der Inhalt an den Client übertragen (ist Bestandteil der HTML-Datei), damit Inhalt im Sinne von Dynamic HTML interaktiv veränderbar ist.

Literatur

[1] Henning Behme, Stefan Mintert; Web-Programmierung; Klammern gehört zum Handwerk; DSSSL: XML-Dokumente fürs Web formatieren

[2] Ingo Macherius; Web-Sprachen; Revolution der Experten; XML: Professionelle Alternative zu HTML