Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

19.05.2000 - 

W3C sieht XSL Transformations als Standard vor

XML-Datenaustausch benötigt Konvertierung

MÜNCHEN (ws) - Laufend neu entstehende Dokumenttypen würden zu einer babylonischen Sprachenverwirrung führen, wenn sich die davon abgeleiteten XML-Daten nicht ohne weiteres zwischen den verschiedenen Vokabularen konvertieren ließen. Die vom W3C dafür empfohlene Sprache XSL Transformations (XSLT) erfreut sich großer Herstellerunterstützung, weist in der Praxis aber noch reichlich Defizite auf.

Die Erfinder der Extensible Markup Language (XML) verfolgten das Ziel, die Bedeutung von Inhalten mit Hilfe von Markup zu beschreiben. In der Tradition von SGML unterscheidet sich diese Metasprache darin von präsentationsorientierten Sprachen wie HTML oder Postscript. Die semantische Auszeichnung von Content ist dabei nicht auf Dokumente beschränkt. Die einfache Syntax von XML erlaubt es vielmehr, fast beliebige Daten auf diese Weise zu qualifizieren. Deshalb nutzen sie immer mehr Hersteller als Vehikel zum Datenaustausch zwischen unterschiedlichen Systemen. Dabei lassen sich die aus einem Warenwirtschaftssystem exportierten Daten durch Tags wie <produktnummer> oder <preis> auf die syntaktisch gleiche Weise beschreiben wie die Abschnitte eines technischen Handbuchs.

Beiden Anwendungsfällen ist gemeinsam, dass der Nutzen von XML-codierten Informationen häufig davon abhängt, dass sich diese relativ leicht in andere Formate umwandeln lassen. Ganz offensichtlich wird dieses Bedürfnis beim Datenaustausch, der im Rahmen von E-Commerce zunimmt und die Grenzen zwischen inkompatiblen Systemen überschreiten muss. Zwar sollen zahlreiche branchenübergreifende Initiativen sicherstellen, dass nicht gleich jede Geschäftsbeziehung zur Definition einer eigenen XML-Anwendung führt (dazu zählen beispielsweise Oasis, Rosettanet oder Biztalk, siehe CW 16/00, Seite 60). Aber auch diese Bemühungen sind inzwischen von Konkurrenz geprägt, zudem werden viele Anwender für spezifische Fälle ihre eigenen Dokumenttypen definieren.

Entsprechende Anforderungen bestehen auch beim Publizieren von Dokumenten. Das semantisch orientierte Markup gibt Zielsystemen keinerlei Information darüber, wie die Inhalte dargestellt werden sollen. Notwendig ist daher die Umwandlung von XML-Dokumenten in Präsentationsformate wie HTML und RTF oder die Generierung eines Zieldokuments, das Formatierungsangaben auf Basis von Cascading Style Sheets (CSS) oder XSL Formatting Objects (XSL:FO) enthält.

Für beiderlei Zwecke empfiehlt das W3-Consortium XSL Translations. Es handelt sich dabei um eine deklarative Sprache, die unter Nutzung der Xpath-Syntax speziell auf Manipulation von Dokumentenbäumen ausgelegt ist.

XSLT-Stylesheets folgen selbst der XML-Syntax und müssen daher wohlgeformt sein. Deshalb eignet sich XSLT besonders für die Transformation zwischen verschiedenen XML-Anwendungen.

XSLT beschränkt sich keineswegs auf das Austauschen eines Elementnamens durch einen anderen. Vielmehr lassen sich damit Zieldokumente generieren, in denen die ursprünglichen Informationen völlig anders angeordnet, nach bestimmten Kriterien gefiltert oder sortiert werden.

Von Nutzen ist diese Fähigkeit insbesondere deshalb, weil mit der zunehmenden Zahl an Ausgabemedien auch die Inhalte individuell aufbereitet werden müssen. Ein und dasselbe XML-Dokument lässt sich mittels unterschiedlicher Stylesheets für Web-Browser, WAP-Handys oder den Druck aufbereiten. Ähnliches gilt auch beim Datenaustausch: Die aus einem R/3-System im XML-Format abgerufenen Daten lassen sich mit einem Stylesheet in eine CRM-Anwendung von Siebel einfüttern, mit einem anderen in eine solche von Clarify.

Die Extensible Markup Language (XML) ist von ihrem Konzept her auf die Trennung von Inhalt und Layout ausgelegt. XSLT-Prozessoren setzen diesen Anspruch um, indem sie aus dem Input, bestehend aus XML-Dokumenten und Stylesheets, darstellbare Formate erzeugen. Hinzu kommt aber noch, dass dieser Ansatz auch die Trennung von der Programmlogik erlaubt. Kritiker von XSLT wie Michael Leventhal (http://www.xml.com/pub/1999/05/xsl/xslconsidered_1.html) vertreten nämlich die Ansicht, dass sich die Aufbereitung von XML-Daten für das Web besser über das Document Object Model (DOM) via Scripts plus CSS bewerkstelligen ließe. Allerdings führt dieses Vorgehen dazu, dass gerade bei komplexeren Web-Anwendungen Layoutinformationen mit Programmcode vermischt und dieser dadurch schlechter wartbar wird. Demgegenüber lassen sich XSLT-Stylesheets getrennt von der Applikation entwickeln und anpassen.

Motiviert sind derartige Einwände häufig auch dadurch, dass XSLT im Vergleich mit prozeduralen Sprachen wie Javascript oder Perl zum Umdenken zwingt. Programmierer, die sich bei Letzteren zu Hause fühlen, sehen es nicht selten als umständlich oder kompliziert an. Ihnen wollen Anbieter von alternativen Transformationstechniken wie Decisionsoft mit "XML-Script" (http://www.xmlscript.org) entgegenkommen. Dabei kann jedoch die Rolle von XSLT für XML-Dokumente durchaus mit jener von SQL bei relationalen Daten verglichen werden.

Schwächen derzeit noch bei W3C-Standards

Handfestere Argumente gegen die Nutzung von XSLT entspringen indes immanenten Schwächen der aktuellen W3C-Empfehlung (http://www.w3.org/TR/xslt) sowie dem Angebot an standardkonformen Prozessoren. Als Defizit des Standards gilt insbesondere, dass sich XSLT-Engines nicht über ein einheitliches API ansprechen lassen, so wie dies bei XML-Parsern mit DOM der Fall ist. Entsprechend umständlich ist es, in Programmen einen XSLT-Prozessor gegen einen anderen auszutauschen. Die unfreiwillige Treue zu einem solchen Produkt kann dann noch die Nutzung von nicht standardkonformen Funktionen verstärken. Dazu zählen beispielsweise die Möglichkeit, den Output in mehrere Zieldateien zu schreiben oder externe Programme aufzurufen. Beides sind relativ oft benötigte Features, Ersteres vor allem beim Web-Publishing. Dort sollen häufig lange XML-Dokumente auf mehrere HTML-Seiten verteilt werden. Die aktuelle W3C-Empfehlung definiert derartige Erweiterungen nicht, allerdings reagierte die zuständige Arbeitsgruppe bereits auf die Debatten in den betreffenden Mailing-Listen (http://www.mulberrytech.com/xsl/xsl-list). Aus der Entwicklergemeinde liegt mit "Trax" auch schon ein Vorschlag für eine solche Standardisierung vor (http://trax.openxml.org).

Konkurrenz erhält XSLT auch deshalb, weil viele Implementierungen Schwächen bei der Ausführungsgeschwindigkeit zeigen. Das liegt unter anderem daran, dass XSLT von einem Dokumentenbaum zu einem anderen konvertiert. Deshalb muss zuerst ein Parser Dokumente DOM-konform aufbereiten und diese dann an die XSLT-Engine zur Weiterverarbeitung weitergeben. Gerade bei größeren Datenmengen braucht das Erstellen dieses Baums einige Zeit und benötigt zudem viel Speicher, weil das gesamte Dokument im RAM gehalten werden muss. Als eine Reaktion darauf entwickelte beispielsweise der Perl-Programmierer Matt Sergeant mit "Not XSLT" (http://xml.sergeant.org/notxslt.xml) eine XSLT-ähnliche Sprache, die sich als Apache-Modul nutzen lässt und wesentlich schneller sein soll als die Standardtechnik. Diese Alternative kann beim Funktionsumfang nicht mit XSLT mithalten, aber für das Web-Publishing reichen häufig auch einfachere Werkzeuge.

Abb: Ein XSLT-Stylesheet kann auf mehrere XML-Dokumente angewandt werden, umgekehrt lassen sich einer XML-Datei mehrere Transformationsscripts zuordnen. Quelle: Crane Softwrights