Web-Autoren haben, wenn sie einen avantgardistischen Einschlag nicht scheuen, schon vor Monaten angefangen, mit Cascading Style Sheets (CSS) zu arbeiten (siehe [[#lit1 1], [#lit2 2]]). Für SGML-Daten existiert bereits eine Formatierungssprache, von der eine abgespeckte Variante demnächst als Stilbestandteil von XML, der Extensible Markup Language, dienen dürfte.
Im Gegensatz zu HTML bietet XML die Möglichkeit, strukturierte Daten gemeinsam mit ihren Metadaten vorzuhalten, sei es in einer Datenbank oder einem 'flat file'. Selbst wenn die großen Browser eines Tages ohne externe Hilfe XML-fähig sind, kann eine Wandlung nach HTML noch sinnvoll sein, denn vielleicht will man nicht Hunderte von KByte übertragen, wo es auch zwanzig täten ...
Sinn solcher Transformation ist, aus einer großen XML-Datei verschiedene Sichten zu generieren. Umfangreiche Datenbestände dürften meist in Datenbanken vorliegen, und von dort extrahieren zukünftig Tools Daten, die dann in XML-Notation existieren und einen Zugriff ermöglichen, der sich auch auf die Metadaten (Elementnamen, Attribute) beziehen kann. HTML-Look&Feel ist nur eine Display-Variante, noch dazu eine, die nicht die Metainformationen enthält beziehungsweise nutzen kann.
Derzeit ist für die Extensible Markup Language nur die Syntax festgeschrieben. Ein zweiter Teil, das Linking, ist momentan ebenso in Arbeit wie der dritte: die Stilkomponente. Klar ist bereits jetzt, daß SGML- und XML-Daten sich mit Hilfe von Style Sheets in HTML wandeln lassen. Dabei ist zu bedenken, daß die Struktur des Originaldokuments nicht erhalten bleibt - nicht bleiben kann -, weil ein solches Wandeln aus beliebig komplex strukturiertem Markup gemeines HTML macht.
Ein fünfbuchstabiges Akronym schreckt manchen ab. Mindestens eine einfache Aussprache muß dafür her. So könnte es der Document Style Semantics and Specification Language gegangen sein: das Akronym ist logischerweise DSSSL, zu sprechen ist es 'dissel'. Und obwohl noch nicht feststeht, wie genau die Stilsprache von XML aussehen wird, kann man bereits jetzt mit DSSSL-Tools XML-Daten be- und verarbeiten und - nach HTML gewandelt - im Browser darstellen.
Was an SGML und XML so angenehm ist: es handelt sich um offene Standards in dem Sinne, daß sie nicht von einem oder mehreren Herstellern abhängig sind. SGML als ISO 8879:1986, DSSSL als ISO/IEC 10179:1996 - beide Sprachen sind internationale Standards (die letzten vier Ziffern bezeichnen das Jahr der Festlegung). Und so wie XML wesentlich einfacher ist als SGML (ein Subset vom im Dezember 97 aktualisierten), wird auch der Stilbestandteil von XML eine Untermenge von DSSSL sein. Im Gespräch waren bis vor kurzem zwei Vorschläge: XSL (www.microsoft.com/xml/xsl/) und das von Jon Bosak vorgestellte XS. Mittlerweile scheint das World Wide Web Consortium den von Microsoft, Inso und Arbortext eingereichten XSL-Vorschlag als Grundlage für die künftigen Stilkomponenten zu betrachten (mit Bosaks Unterstützung). Microsoft hat bereits eine erste Version eines kostenlosen Style-Sheet-Prozessors (msxsl) ins Web gestellt. Zur Arbeit mit diesem Tool folgt ein Artikel in einem der nächsten Hefte.
Um mit XML-Dateien etwas anfangen zu können, braucht man einen entsprechenden Browser (circa sechs Monate warten auf Netscape und Microsoft) oder Tools, die das Wandeln in HTML unterstützten. Dazu gibt es, grob gesagt, zwei Möglichkeiten: entweder kommt Microsofts Style-Sheet-Prozessor (msxsl) zum Einsatz oder ein Werkzeug wie Jade oder COST - im hier vorgestellten Beispiel James Clarks Jade (für James' DSSSL Engine). In beiden Fällen ist Arbeit auf der Kommandozeile vonnöten. In diesem Artikel kommt nur Jade zum Einsatz, eine parallele Darstellung von msxsl würde den Rahmen sprengen ...
DSSSL ist ein Scheme-Dialekt, eine funktionale Programmiersprache aus der Lisp-Familie. Oberflächlich betrachtet sind DSSSL-Konstrukte beliebig geschachtelte Klammerausdrücke. Ein paar Basics sind dem gleichnamigen Kasten zu entnehmen.
Voraussetzung für den Einsatz von Jade sind SGML-/XML-Daten und Style Sheets - für Jade außerdem ein paar Document Type Definitions (DTDs, die liegen dem Jade-Paket bei) und die XML-Deklaration in SGML (wenn es XML-Daten sind). Letztere ist beispielsweise beim University College Cork (www.ucc.ie/xml/sgmlxml.dec) zu finden.
Neben der Tatsache, daß Jade erst einen Teil von DSSSL beherrscht, ist die Auswahl der möglichen Ausgabeformate nicht besonders groß. Einzig das 'Backend' für das Rich Text Format (RTF) liefert akzeptable Ergebnisse. Für den TeX-Output gibt es erste Ansätze.
Von grundsätzlich anderer Art sind die Anforderungen bei der Umwandlung in HTML. Dies ist kein Formatierungsprozeß, sondern eine Transformation, also eine Umwandlung von einer SGML/XML-DTD in eine andere (in diesem Fall HTML).
Die dafür konzipierte Transformation Language von DSSSL versteht Jade (noch) nicht, jedoch bietet James Clark eine komfortable proprietäre Lösung an. Er definiert eigene Flow Objects speziell für den SGML-Output. Das wichtigste davon ist das element. Ein DSSSL/Jade-Style-Sheet beginnt deshalb mit den ersten vier Zeilen aus Listing 1.
Die erste Zeile macht nichts weiter, als die Datei als Style Sheet zu identifizieren. Nach der zweiten steht ein Flow Object namens element zur Verfügung. Es besitzt zwei Charakteristika: einen Namen (gi = Generic Identifier) und die Attribute (attributes).
Möchte man mit Jade beispielsweise ein Element namens lithist in eine h1-Überschrift transformieren, so erledigt die Anweisung
(element lithist (make element gi: 'H1'))
diese Aufgabe. Analog dazu stellt Jade alle für SGML wichtigen Dinge zur Verfügung. Leere Elemente wie HTMLs br und Entity-Referenzen wie Umlaute (ä) deklariert man mit entity-ref aus Listing 1. Auch in diesem Fall ist die Anwendung recht einfach:
(element zeilenumbruch
(make empty-element gi: 'BR'))
(element copyright
(make sequence
(make entity-ref name: 'copy') ; ©
(process-children)))
Im letzten Beispiel wird das Copyright-Symbol vor den Inhalt des Elements (process-children) gestellt. Umlaute und andere Sonderzeichen lassen sich im eigenen (XML-)Dokument verwenden, wenn die Definition der Zeichen in der Document Type Definition (DTD) enthalten ist; für den ISO-8859-1-Zeichensatz findet sich die Liste, die in der DTD stehen muß, in der HTML-4.0-Spezifikation beim W3C (http://www.w3.org/TR/REC-html40/sgml/entities.html). DTDs legen außerdem vor allem die Struktur von SGML- oder XML-Dokumenten fest. Auf sie geht dieser Artikel nicht ein.
Gerade wenn man die HTML-Ausgabe im Hinterkopf hat, bietet es sich an, in eigenen DTDs gleiche Elementnamen zu verwenden (soweit sinnvoll). Benutzt man also STRONG, EM oder TABLE, ist bei der Transformation nichts zu tun. Dies gestattet Jade mit einer Default-Anweisung (Ende von Listing 1). Dadurch wird ein Element gleichen Namens erzeugt (weil für gi kein Wert genannt ist), und die Attribute werden kopiert. Die Funktion copy-attributes ist kein Bestandteil von DSSSL, sondern von Clark definiert (siehe Listing 1).
In den Style Sheets selbst stehen Anweisungen, wie bestimmte Elemente zu formatieren sind. Als Miniaturanwendung diene hier eine Sammlung von Autor(inn)en der Weltliteratur, die den Inhalt einer kleinen Literaturgeschichte bilden sollen. Ein Beispiel aus dieser Autorenliste ist in Listing 2 wiedergegeben. Spätestens der zweite Blick zeigt, daß es sich hier nicht um HTML handelt. Genau deswegen ist es notwendig, Elemente wie author, fname und lname in HTML-konforme Elemente zu wandeln.
Durch die in XML streng geregelte Schachtelung sehen Elemente und Attribute etwas komplizierter aus als HTML. Ist lediglich ein Kopieren gewünscht, braucht man sich um die Feinheiten nicht zu kümmern. Für eigene Wertzuweisungen an Attribute erwartet Jade Listenpaare. Um in der Behandlung des Autorennamens dem h3-Element ein aussagekräftiges class-Attribut zu geben, kann man beispielsweise folgende DSSSL-Anweisung einsetzen:
(element (lithist author)
(make element gi: 'H3'
attributes: (cons (list 'class' 'eng')
'())))
Dies liefert im Zieldokument <h3 class="eng">...</h3> und heißt: ein Cascading Style Sheet kann vorschreiben wie h3.eng auszusehen hat. Alles in allem sind Clarks proprietäre Erweiterungen schnell zu lernen und erlauben eine bequeme Transformation von SGML/XML nach HTML.
Zunächst kurz zur Arbeit mit jade: das Kommando
jade -d<stylesheet.dsl>-t sgml xml.decl<datei xml>><datei HTML>
macht aus den XML-Daten (.xml) durch das Style Sheet (.dsl) und die Umleitung (>) eine HTML-Datei. Vor der XML-Datei muß die SGML-Deklaration für XML (xml.decl) stehen, denn -t sgml wandelt nach SGML, und wenn die Deklaration fehlt, gibt jade Fehlermeldungen aus, was zum Abbruch des Prozesses führt ...
Das wichtigste bei dieser Umwandlung von strukturierten Daten in 'plattes' HTML ist das Style Sheet (DSSSL). Wie kompliziert das sein kann, deutet Listing 3 an, vor allem deshalb, weil alles, was das Style Sheet letztlich tut, nichts anderes ist, als eine Art Inhaltsverzeichnis anzulegen - die Liste der vorhandenen Autoren aus der 'Sammlung' (siehe Abbildung 1).
Dazu ist es notwendig, eine (vollständige) HTML-Datei zu generieren. Das beginnt in Zeile 44, ab der festgelegt wird, was mit dem (Top-Level-)Element lithist zu geschehen hat. Zunächst schreibt das Style Sheet den Dokumententyp und anschließend das html-Element, in das head und body eingebettet sind: die html schließende Klammer ist die drittletzte auf Zeile 77, die davor schließt das make sequence aus Zeile 50 und die davor den body ...
Innerhalb dieser DSSSL-Funktion steht auch, was mit den Elementen geschehen soll, die sich in der Hierarchie unterhalb des gegenwärtigen befinden; also lithead und author. Die übrigen läßt dieses Style Sheet explizit aus, indem es für sie definiert:
(element<mein_element>(empty-sosofo))
Dieses wahrlich schöne Akronym (SOSOFO) heißt 'Specification Of a Sequence Of Flow Objects' und stellt oben - durch empty - eine Leeranweisung dar. Ein nicht leeres Gegenstück steckt in Zeile 52 ((with-mode prolog (process-matching-children 'lithead)))) und sorgt dafür, daß mit Hilfe des weiter oben definierten Modus prolog der HTML-head zustande kommt und - durch die if-Abfrage nach dem ersten Vorkommen dieses Elements - eben den ersten lithead als Titel enthält.
Sollte eine Funktion wie die oben genannte SOSOFO-Anweisung häufig vorkommen, kann man statt der vielen eine Funktion aufnehmen, die genau dies zum Default macht:
(default (empty-sosofo))
Im direkt darauf folgenden body (Zeile 55 bis 79) sind fünf Bestandteile enthalten:
Kopf und Fuß bildet hier jeweils ein Absatz (p), beiden sind unterschiedliche Klassen zugeordnet, weil das HTML-Dokument auf ein Cascading Style Sheet verweist (ab Zeile 13 in Listing 3). Die Zeilen 62 und 69 leiten den Weg in die Tiefe der Elementhierarchie ein, indem die benannten lithead und author verarbeitet werden. Das Style Sheet behandelt die beiden lithead-Elemente nicht gleich, indem es ihnen unterschiedliche CSS-Klassen zuweist. Wer mehr als zwei Sprachen für Dokumente verwendet, kann statt nach den siblings zu fragen, die Darstellung vom Attribut lang des lithead abhängig machen. Das bedeutete eine Frage nach dem Attributinhalt, wie sie weiter unten in anderem Zusammenhang vorkommt.
Für author bildet der dritte der fünf Bestandteile den Rahmen: ein Formular, in das das Style Sheet für den eigentlichen Autor nur noch eine option für die select-Anweisung bereitstellen muß (Zeile 99 bis 101). Dort wiederum findet sich ebenfalls ein Verweis auf die nächsttiefere Hierarchieebene, denn author enthält name, der enthält fname und lname (siehe Listing 2, Zeile 6).
Um ins von der Hierarchie her letzte Detail zu gehen: ab Zeile 105 sind die am tiefsten angesiedelten Elemente zu finden. name enthält die Anweisung, die Kind-Elemente zu verarbeiten, lname ebenfalls, und für fname ist es notwendig, dem Vornamen ein Leerzeichen folgen zu lassen, damit Vor- und Nachname voneinander getrennt bleiben.
(process-children)
in Elementen wie fname heißt, daß die einzelnen Buchstaben, aus denen es besteht, verarbeitet werden sollen. Auch characters sind Flow Objects im Dokumentenbaum.
Angesichts der Tatsache, daß das Style Sheet in Listing 3 eine form für das HTML-Dokument vorsieht, ist klar, daß außer dem Inhaltsverzeichnis noch etwas ausgegeben werden soll. Schließlich ist es einer der Vorteile, die XML gegenüber HTML bietet, daß aus den semantisch strukturierten Daten - per Style Sheet - beliebig viele Ansichten erzeugt werden können. Zeile 65 enthält deshalb den Aufruf eines CGI-Scripts (in diesem Falle in Perl geschrieben), das beim Klick auf okay das Attribut des jeweiligen author-Elements übergeben bekommt.
Auf das Perl-Script sei hier nicht im Detail eingegangen. Im wesentlichen schreibt es Listing 1 und Listing 4 sowie dazwischen eine DSSSL-Funktion, die sich
print ThisF "\n(define thisAuthor \"$fields{'AUTHOR'}\")\n\n";
liest, in ein temporäres Style Sheet. Der Grund hierfür ist, daß Jade die Übergabe von Parametern nicht erlaubt (außer per define eine Variable auf true zu setzen), hier aber innerhalb des temporären das Attribut des Autors vorhanden sein muß. Genau das erledigt Perl mit obiger Zeile. Ansonsten schickt das Script Daten und Style Sheet durch Jade (Kommando [#jade siehe oben]) und produziert das HTML-Dokument auf die Standardausgabe.
Da es in diesem Fall nicht um das Inhaltsverzeichnis geht, sondern darum, die Information über einen Autor darzustellen, muß das Style Sheet insbesondere zu author anders aussehen als das vorherige. Listing 4 beinhaltet deshalb nur die für die Ausgabe relevanten Elemente.
Zeile 12 ist diejenige, auf die oben schon verwiesen wurde: hier ist die im Perl-Script definierte Variable thisAuthor das Kriterium dafür, ob die Informationen über den Autor ausgeben werden - oder nicht. Nur wenn der Inhalt des Attributs id (siehe den Anfang von Listing 2) mit dem der übergebenen Variable übereinstimmt, sorgt das Style Sheet dafür, daß eine Tabelle angelegt und in die nächsttiefere Elementebene verzweigt wird.
Falls ja, geht es durch eine waagerechte Linie getrennt in den Zeilen 25 und 30 jeweils in die hierarchisch nächste Ebene, wo sich die Lebensdaten und die Werke finden. Allerdings gilt hier wie für das Inhaltsverzeichnis, daß erst der Gang in die Blätter des Dokumentbaums zur Ausgabe der konkreten Daten führt. Deshalb sind Funktionen für vita und works nicht einmal vorhanden. Offenkundig setzt Jade voraus, daß nicht existierende Funktionen aus (process-children) bestehen.
Erst weiter 'unten' in der Hierarchie ist die Darstellung vorgegeben: die Elemente born, died und where müssen deshalb die entsprechenden Formatierungen enthalten. In allen drei Fällen heißt das, die in author geöffnete (und mit der vorletzten Klammer in Zeile 30 geschlossene) Tabelle mit Inhalt, also Zeilen und Spalten, zu füllen.
Wenn jemand Edgar Allan Poe im Inhaltsverzeichnis wählt, sieht das Ergebnis aus wie Abbildung 2.
Über die hier vorgestellten beiden Sichten auf die XML-Daten hinaus sind natürlich weitere denkbar: eine Liste der Autor(inn)en, die in einem bestimmten Jahrhundert oder Land geboren sind; alle Selbstmörder oder Nobelpreisträger et cetera.
Literatur
[1] Stefan Mintert; Web-Design; Der Weg der Tugend; Style Sheets: Make-Up für WWW-Dokumente
[2] Henning Behme;Web-Design; Böse Buben; Inkompatibel: CSS bei Netscape und Microsoft
[3] Ingo Macherius; Web-Sprachen; Revolution der Experten; XML: Professionelle Alternative zu HTML
| iX-TRACT |
|
Dieser Text ist der Zeitschriften-Ausgabe 03/1998 von iX entnommen.
iOS, Android, Windows Phone 7 und HTML5 - das neue Sonderheft von heise Developer führt Einsteiger und Profis in die Programmierung mobiler Geräte ein.
