Ein Blick zurück auf die vergangenen vier Jahre offenbart den raschen Wandel des Online-Publishing. Während die "Standard Generalized Markup Language" (SGML) nur langsam in die Gänge kam, startete die "Hypertext Markup Language" (HTML) gleichsam wie eine Rakete. Ein Katalysator, der die Akzeptanz von HTML noch beschleunigte, war deren einfache Struktur: HTML ist leicht zu erlernen, so daß selbst Laien damit nach kurzer Zeit umfangreiche Dokumente ansprechend layouten können.
Schon bald wurde jedoch der Ruf laut, über die fundamentalen HTML-Elemente hinaus auch typische Publishing-Funktionen einzubinden, etwa solche zur genaueren Positionierung einzelner Elemente. Dabei spielten und spielen immer noch die beiden Kontrahenten Microsoft und Netscape eine Schlüsselrolle - schließlich macht nur Sinn, was deren Browser auch "verstehen". Über den fortgesetzten Debatten, in denen sich die beiden Widersacher bislang nicht einigen konnten, geriet eine Frage fast in Vergessenheit: Wie muß eigentlich ein Format aussehen, das beliebig strukturierte Daten medienunabhängig und also getrennt von der späteren Darstellung verwaltet? Es geht, mit anderen Worten, um nichts Geringereres als das künftige, einheitliche Datenmodell für Dokumente.
Ein solches Modell sollte beispielsweise interessante Informationen, die zuvor in irgendwelchen Aktenordnern verstaubten, elektronisch zur Verfügung stellen - trotz all der angehäuften Serverpracht ein Problem für viele Firmen. Außerdem sollten die Mitarbeiter Daten miteinander austauschen können, und zwar ohne den Umweg über ausgedruckte Formulare. Das Zauberwort heißt hier "Server/Server-Computing" (siehe auch den gleichnamigen Kasten).
Die "Extended Markup Language" (XML), die wir bereits in [1] vorgestellt hatten, könnte den entscheidenden Anstoß geben, die notwendigen Schritte endlich anzugehen. Bis sich XML allerdings auf breiter Front durchsetzen wird, dürfte noch ein Weilchen vergehen. Dies liegt nicht zuletzt an der erhöhten Komplexität und den bereits jetzt kaum zu überblickenden Ergänzungen, Erweiterungen und Standardisierungsvorschlägen. Dennoch: Wer bei XML zu spät kommt, den bestraft das Leben. Sie sollten sich also vorzeitig damit beschäftigen - am besten jetzt gleich!
Wo anfangen?
Wie bereits angedeutet, präsentiert sich XML nicht gerade als überschaubare Unbekannte. Insbesondere versperren ein Gestrüpp aus unzähligen Tools und Utilities sowie etliche Derivate für die verschiedensten Einsatzzwecke den Blick in das eigentlich so klare Wasser. Gut zugängliche Ankerplätze bieten lediglich die zentralen Anlaufstellen (siehe auch den gleichnamigen Kasten) und die Web-Sites der Schlüsselfiguren des Marktes: IBM (Alphaworks), Microsoft und Sun Microsystems.
Zum Eintauchen in die Materie ist allerdings etwas mehr als nur das bloße Beherrschen von XML Voraussetzung. Zwar lassen sich mit der Sprache Dokumente beschreiben, jedoch weder umsetzen noch verwalten; beides geschieht sozusagen "außerhalb" von XML und nicht selten mit Skriptsprachen wie Perl oder Phyton. Als zentrale Programmierumgebung dürfte sich jedoch schon bald Java herauskristallisieren.
Als neue Fähigkeit gefeiert, erlaubt XML die Definition eigener Tags. Dabei existiert bereits seit längerem die Möglichkeit, "private" HTML-Tags von einer der vielen Instanzen zwischen Dokumentenursprung und Anwender verarbeiten zu lassen. Ein Beispiel ist die "Coldfusion Markup Language" (CFML), die HTML hauptsächlich um datenbankspezifische Funktionen erweitert: Ein am HTTP-Server angebundener Prozessor interpretiert die CFML-Tags und wandelt sie in HTML-Code um. Weitere Beispiele sind die "Active Server Pages" (ASP), die "Java Server Pages" (JSP), "interactive HTML" (iHTML) und Perlscript.
Aber natürlich bietet XML mehr. Erstmals können die Autoren beliebige Tags definieren, und zwar aus einem Standard heraus, der schlank und stringent ist. Und in Kombination mit den bereits jetzt frei verfügbaren XML-Tools kommen die PS endlich auch auf die Straße.
Parsen durch logische Bäume
Ein XML-Dokument ist eine auf den XML-Regeln basierende, strukturierte Datei. Die Interpretation der Tags wird von DTD-Files (DTD = Document Type Definition) vorgeschrieben, die man schon zu HTML-Zeiten im Header mitführen konnte. Darin befinden sich die Definitionen der einzelnen Tags sowie die logische Struktur der Tags untereinander. Beispiel:
</p> <p><!LEMENT ADRESSE (FIRMA*)></p> <p><!LEMENT FIRMA (NAME, PLZ, ORT)></p> <p><!LEMENT NAME (#PCDATA)></p> <p><!LEMENT PLZ (#PCDATA)></p> <p><!LEMENT ORT (#PCDATA)></p> <p>
Ein XML-basierendes Dokument, das auf diese DTD zurückgreift, könnte so aussehen:
</p> <p><ADRESSE></p> <p>...</p> <p><NAME>Hinz&Kunz</NAME></p> <p><PLZ>0815</PLZ></p> <p><ORT>Mount Pardorf</ORT></p> <p></ADRESSE></p> <p>
In komplexeren Dokumenten können so unterschiedliche logische Inhalte eingebettet werden, die von der einen DTD so, von der andern so und von manchen überhaupt nicht festgelegt werden. Die logische Grundstruktur ist relativ flexibel: Ein und dasselbe Dokument kann etwa als Adreßdatenbank oder als komplexes Redaktionssystem interpretiert werden. Ja, nicht einmal die Daten müssen im XML-Format vorliegen. Vielmehr wäre es die Aufgabe einer geeigneten Datenbankschnittstelle, den Tabelleneintrag "Ort" in ein Tag-Konstrukt ... einzubetten und dann als Teil eines I/O-Streams auszugeben.
Tools, Tools, Tools!
Und auch das funktioniert: XML-Dokumente können von selbstgestrickten Codegeneratoren und unter Berücksichtigung der DTDs in beliebige Ausgabeformate gewandelt werden. Dazu liest zunächst ein Parser die Datei ein, durchsucht sie schrittweise nach DTD-Notationen und erstellt einen Baum mit den logischen Bestandteilen (Namensfelder, Überschriften et cetera) als Knoten. Er kann von einem Codegenerator durchkämmt werden, der wiederum das gewünschte Ausgabeformat erzeugt, beispielsweise DOC, PDF, HTML oder HTML mit CSS.
Je nach Typ entdeckt und meldet der Parser Fehler im Dokument (validierender Parser), falls keine stringente DTD-Notation vorliegt, oder er übergeht diese Schwäche dezent und ohne Widerrede. Bei all denen, die sich einmal dem Hobby des Compiler-Baus hingaben, dürften spätestens jetzt die Erinnerungsglocken läuten: Kompliziert und langwierig, oder? Glücklicherweise ist der Weg vom XML- zum fertigen HTML- oder PDF-Dokument aufgrund der zur Verfügung stehenden Tools nur kurz - der Ballast des Parser- oder Compiler-Baus darf also ruhig zurückgelassen werden.
DOM-Werkzeuge und XML-Beans
Der logische Dokumentenbaum muß im übrigen von anderen Institutionen ausgewertet (traversiert) werden. Wichtig ist etwa das "Document Object Model" (DOM) des World Wide Web Consortium (W3C): Es definiert spezielle Schnittstellen, über die der Anwender die Semantik der Knoten programmieren kann. Basierend auf einer ebenfalls in XML erstellten Spezifikation für das jeweilige DOM erzeugen verschiedene Tools fertigen Java- oder IDL-Code (IDL = Interface Definition Language). Zu den Parsern, die DOM unterstützen, gehören:
- "XML-Parser" von Sun,
- "XML4J" von IBM-Alphaworks und
- "XP" von James Clark.
Und von Docuverse kommt "DOM SDK", das sogenannte SAX-Parser (siehe unten) DOM-fähig macht.
Beim Verarbeiten der Bäume kommt häufig der Wunsch auf, "on the fly" Manipulationen vorzunehmen. Ihn erfüllen die "XML-Beans", mit denen beliebige Knoten um eigene Programmobjekte ergänzt werden können. Der Name lehnt sich an die "Java-Beans" an, zumal in beiden solche Grundklassen eine zentrale Rolle spielen, die auf den Methoden get, notification/is und set aufbauen. Die grundlegenden Methoden zum Einhängen von Knoten in den Bearbeitungsbaum heißen Factory.
SAX und XML-Namespaces
Etwas einfacher gestrickt und derzeit sicherlich das meistgenutzte Tool ist das "Simple API for XML" (SAX), eine universelle Schnittstelle zu unterschiedlichen XML-Parsern. Die oben aufgelisteten Programme unterstützen SAX unmittelbar; für andere, etwa "MS-XML", stehen externe Treiber zur Verfügung. SAX eignet sich vorzüglich als Umgebung für lineare Konvertierungen, bei denen jedes XML-Tag genau einem Output zugeordnet ist (1:1-Verknüpfung). Entdeckt der Parser einen Knoten, so ruft er eine dafür zuständige Callback-Routine auf, die eine Konversion durchführt oder eine Aktion auslöst. Sie kann entweder einfachen HTML-Code erzeugen - und beispielsweise einen Textvorspann als rechtsbündig angeordnete Tabelle mit einer relativen Breite von 75 Prozent definieren - oder Platzhalter durch aktuelle Informationen aus einer Datenbank ersetzen. Im Gegensatz zur Baumstruktur des DOM arbeitet SAX also mit einem linearen Daten-Stream.
Zu den praktischen Tools im SAX-Umfeld gehört "SAXON". Hiermit lassen sich XML-DTDs ineinander überführen oder automatisch neue DTDs erzeugen. Darüber hinaus kann SAXON auch in der DOM-Welt zum Einsatz kommen. Einen Konverter zwischen SAX und DOM bietet IBM mit dem "XML Productivity Kit" (XPK4J) an.
Vieldiskutiert wird derzeit ein Vorschlag des W3C, der den Aufbau komplexer Dokumente vereinfachen soll und eine Kombination mehrerer Tag-Familien in einem Dokument zuläßt. Das setzte bislang voraus, daß sich die Tag-Familien nicht überschneiden, es also innerhalb eines Dokuments nicht Tags ein und desselben Names jedoch verschiedener Autoren gibt. Sonst nämlich hätte der Parser die Tags in der Tat "mißverstehen" können. Die sogenannten "Namespaces" lösen das Problem. Darin fassen alle Autoren, jeder für sich, ihre eigenen Tags zusammen. Belegen zwei Autoren ein Tag mit dem gleichen Namen aber unterschiedlicher Struktur, so stellt der Parser deren Herkunft anhand eines Prefix fest, das wie eine Art "Ortsvorwahl" dient. Tools, welche die XML-Namespaces-Erweiterung nicht unterstützen, ignorieren einfach die Erweiterung.
Derzeit noch in Arbeit und deshalb ein bewegliches Ziel ist die "Extensible Style Language" (XSL). Damit kann das Layout von XML-Dokumenten beschrieben werden. XSL ist in gewisser Hinsicht vergleichbar mit parametrisierbaren "Cascading Style Sheets" (CSS) und nutzt mit einem vorangestellten "xsl:"-Prefix bereits eine XML-Namespaces-Notation.
XSL und Skriptsprachen
Unter den Skriptsprachen hat Perl derzeit am meisten zu bieten. Kaum eine Woche vergeht ohne neue Erweiterungen. Die Web-Site des "Perl Institute" (http://www.perl.org) bietet einen guten Überblick über neu hinzugekommene Perl-Module. Im Zentrum steht momentan "XML::Parser", eine Schnittstelle zu dem in C geschriebenen Event-basierenden Parser "Expat".
XML::Parser registriert zunächst alle notwendigen Event-Handler. Falls es später ein Tag aufspürt, ruft es drei Event-Routinen auf:
- start,
- character und
- stop
Der start-Handler nimmt alle Initialisierungen nach dem Start-Tag vor. Die character-Routine verarbeitet die "Nutzdaten", die zwischen den Tags stehen. Und die stop-Routine räumt alles wieder auf. Benötigt man keinen speziellen Handler für ein Start- oder Ende-Tag, so erledigt die generische Routine default die Aufgabe, die der Parser auch dann als "Fallback" aufruft, wenn keine spezielle Handler-Routine bekannt ist.
Zu den Firmen, die derzeit die XML-Liga anführen, gehört ohne Zweifel IBM. Auf der Technik-Web-Site (Alphaworks) findet sich ein ganzes Sammelsurium von Tools, angefangen bei "XML Parser for Java" bis hin zu "Bean Maker", einem Programm, das aus einer DTD gleich die passenden XML-Beans erzeugt. Mit letzteren läßt sich übrigens auch ein grafischer XML-Editor generieren, der die gewünschte DTD "versteht" - idealer Ausgangspunkt für ein internes Redaktionssystem!
Ebenfalls recht interessant ist "Dynamic XML for Java" (DXMLJ), ein Programm, das den Status beliebiger Knoten zur Laufzeit analysiert, um auf Basis der aktuellen Werte (Tageszeit, Aktienkurs, Attribute) die verschiedensten Datenströme zu erzeugen. Alle IBM-Programmpakete stehen mit einer kommerziellen Lizenz kostenlos zur Verfügung, ein Besuch bei Alphaworks lohnt also in jedem Fall.
Die Firmen hinter XML
Natürlich hat auch Sun den Braten gerochen und versucht, mit einer Programmbibliothek das eigene Gewächs Java gegen alle Angriffe aus Seatle in Position zu bringen. Der validierende XML-Parser ist DOM-konform und erlaubt bereits das Einbinden von XML-Beans; zudem unterstützt er den XML-Namespaces-Vorstoß des W3C. Derzeit dürfen allerdings nur eingetragene "Java Developer" (man kann sich kostenlos registrieren lassen) den Code nutzen, und zwar ausschließlich zu internen Zwecken, weil es sich um eine Vorabversion handelt.
"Xosl" ist eine Microsoft-spezifische Lösung. Das Programm greift über die momentan von Microsoft favorisierte Schnittstelle "OLE DB" auf Datenbanken zu und integriert die recherchierten Informationen zur Laufzeit in ein Dokument. Hinsichtlich der Philosophie ähnelt Xosl XSL. Entstanden aus einer Mischung von ADO 2.0, Microsoft Script Control, OLE-DB, Visual Basic und dem MS-XML-Parser steht Xosl als "Proof of Concept" im Quelltext zur Verfügung.
Wo bleiben die Browser?
Alles wartet gespannt auf XML-fähige Browser, die den neuen Metadialekt des Internets auch darstellen können. Und obwohl Microsoft und Netscape entsprechende Produkte bereits angekündigt haben, liegt vieles noch im argen. Beide haben längst nicht alle Hausaufgaben gemacht, so daß es sein könnte, daß die Zeit der XML-fähigen Editoren anbricht und sich die Browserriesen erstmal ausruhen. Wen wundert’s da, wenn sich die großen Datenbankhersteller selbst Gedanken über eine nahtlose Integration ihrer Produkte ins XML-Umfeld machen? Es bleibt spannend. (sk)
Literatur
[1] Schlüter, K.: Websperanto. Gateway 2/99, S. 56 ff.