Start

Unternehmen

Buch-Katalog

Seminare

Leserservice

Comelio-Blog

Datenbanken SQL MS SQL Server Oracle PHP UML C#.NET XML Schema XSLT Alternativen zu XSLT Beispielanwendung HTML-Formulare SQL DDL aus XML SQL DDL aus XML Schema Vorteile von XSLT XML/XSLT-Anwendung

ERP / PPS / Prozesse

Business Intelligence

Server-Technologien

Software-Technologien

Technologie-Beratung

Individual-Software

Produkte

Comelio GmbH
Rellinghauser Straße 10
D-45128 Essen
Deutschland
Fon: 0201-437517-0
Fax: 0201-437517-10
info@comelio.com

Comelio GmbH
Goethestraße 34
D-13086 Berlin
Deutschland
info@comelio.com

Comelio GmbH (Ecos)
Glockengießerwall 17
D-20095 Hamburg
Deutschland
info@comelio.com

Comelio GmbH (Ecos)
Mainzer Landstraße 27-31
D-60329 Frankfurt
Deutschland
info@comelio.com

Comelio GmbH (Ecos)
Stiglmaierplatz/Dachauer Str. 37
D-80335 München
Deutschland
info@comelio.com

Comelio GmbH (Ecos)
Liebknechtstr. 33
D-70565 Stuttgart
Deutschland
info@comelio.com

Comelio GmbH
Nevinghoff 16
D-48147 Münster
Deutschland

Comelio GmbH
Friedrich - List - Platz 1
D-04103 Leipzig
Deutschland

Comelio GmbH
St. Johanner Strasse 41-43
D-66111 Saarbrücken
Deutschland

Comelio GmbH
Kaiser-Wilhem-Ring 27–29
D-50672 Köln
Deutschland

Comelio GmbH
Münsterstraße 248
D-40470 Düsseldorf
Deutschland

Comelio GmbH
Fürther Strasse
D-90429 Nürnberg
Deutschland

Comelio GmbH

Bremen
Deutschland

Comelio-Blog > XSLT > Alternativen zu XSLT

Alternativen zu XSLT

XSLT ist natürlich nicht die einzige Möglichkeit, mit XML-Daten umzugehen und sie für die Präsentation oder für die Umwandlung in präsentationsferne Formate zu verarbeiten. Die Alternativen DOM und SAX sind sowohl in vielen Programmiersprachen als auch in Datenbanksystemen vorhanden. Zusätzlich lässt sich auch noch für die reine Präsentation CSS einsetzen. Mit dieser Technik und DOM liegen zwei W3C-Standards vor, währen SAX dagegen nur ein Quasi-Standard ist. Dieser Artikel stellt die drei Alternativen vor und vergleicht sie miteinander und mit XSLT.

Kontakt Anrede* Herr Frau Vorname* Nachname* Firma E-Mail* Tel-Nr. Bereich* Comelio-Blog > XSLT > Alternativen zu XSLT Freitext

XSLT und seine Alternativen

Mit XSLT besitzt man eine sehr gute und in vielen Fällen auch die beste Möglichkeit, XML zu verarbeiten. Allerdings stellt diese Technologie bei weitem nicht die einzige Option dar, die im Rahmen einer Anwendung zum Einsatz kommen kann. Die Alternativen zu XSLT sollen in diesem Abschnitt vorgestellt werden. Einige von ihnen sind durchaus ernst zu nehmende Konkurrenten, andere dagegen führen ein Nischendasein und sind nicht häufig anzutreffen. Bisweilen kann es sogar sein, dass XSLT nicht notwendigerweise die geeignete Lösung zur Entwicklung und Umsetzung eines Algorithmus ist, weil zusätzliche Anforderungen an die verwendete Technik gestellt werden, die von XSLT noch nicht oder vermutlich niemals erfüllt werden.

Kriterien zur Bewertung

Als Leitmotiv für die Bewertung dieser Alternativen sollen drei Kriterien gelten. Mit ihrer Hilfe ist es möglich, wenigstens eine Diskussionsgrundlage zu besitzen, auf deren Basis eine Entscheidung mit guten Gründen für die eine oder andere Alternative bzw. natürlich auch für XSLT getroffen werden kann. Zusätzlich stellen sie in unseren Augen auch besonders wichtige Kriterien dar, die uns selbst in Kundengesprächen immer wieder helfen, herauszufinden, welche der möglichen Techniken tatsächlich die geeignete für ein bestimmtes Problem ist.

Diese drei Kriterien sind:

Wiederverwendbarkeit

Das Kriterium der Wiederverwendbarkeit bzw. die Möglichkeit, bereits erledigte Arbeit wie z.B. die Entwicklung eines Transformationsalgorithmus auch in anderen Zusammenhängen bzw. mit anderen Systemen oder Programmiersprachen ebenso zu verwenden, besitzt für uns eine besonders große Bedeutung. Dies ist möglicherweise bereits an anderen Stellen deutlich geworden. Da XSLT im Gegensatz zu einigen Alternativen nicht objektorientiert ist, sind einige verfeinerte Techniken von Wiederverwendung nicht gegeben, grundsätzliche dagegen sehr wohl. Da die Entwicklung eines Algorithmus für die Transformation von Daten allerdings teilweise das Kernstück einer Anwendung sein kann, in der XML-Daten nicht nur flüchtig erzeugt und verwendet, sondern ganz bewusst Stück um Stück angereichert, validiert oder aus unterschiedlichen Quellen zusammengefügt werden, kann es regelmäßig geschehen, dass die gleiche Transformation in anderen Zusammenhängen (insbesondere in anderen Programmiersprachen) erneut durchgeführt werden soll. In solchen Fällen ist es natürlich ein großer Vorteil, wenn eine Technik gewählt wurde, die exakt eine solche Anforderung unterstützt.

Komplexität

XML-Strukturen können sehr einfach aufgebaut sein. Sie können jedoch auch aus unterschiedlichen Gründen sehr komplex werden. Diese Komplexität spiegelt sich dann für gewöhnlich auch in der Transformationslogik wider. Einige Techniken unterstützen die Durchführung von komplexen Transformationen mit Fallunterscheidungen, Vergleichen oder Reaktionen auf bestimmte Datenvorkommnisse oder Strukturerscheinungen im XML-Strom, andere dagegen weisen eine geringe Fähigkeit auf, geeignete Aktivitäten auszuführen. Sollen komplexe Transformationen umgesetzt werden, benötigt man für gewöhnlich auch eine Technik, die überhaupt solche Transformationen abbilden kann.

Lernkosten

Wie man sehen kann, ist es möglich, über die Technik von XSLT große Bücher oder mehrere kleine Bücher zu verfassen. Andere Alternativen lassen sich auf wenigen Seiten darstellen und in kürzester Zeit vermitteln. Dies hängt natürlich mit der Fähigkeit der entsprechenden Alternative zusammen, komplexe oder weniger komplexe Algorithmen umzusetzen. Allerdings bestimmt diese Komplexität auch, wie hoch die Kosten sind, die entsprechende Technologie zu erlernen. Teilweise kann es an diesem Kriterium liegen, dass in einem konkreten Fall der Verwendung einer Alternative deswegen der Vorzug gegeben wird, weil sie besonders leicht oder in verhältnismäßig kurzer Zeit zu erlernen und sicher einzusetzen ist.

Wie gerade schon kurz angedeutet, lassen sich wie in vielen Fällen eine große Zahl an weiteren Kriterien finden, die ebenfalls im Rahmen der Entscheidungsfindung herangezogen werden können. Zu diesen gehören beispielsweise folgende:

Einsatzkosten

Wie jede Technik erfordert auch die Durchführung einer XML-Transformation gewisse Kosten, die letztlich auch alle monetär erfasst werden können. Ob es sich dabei um Lizenzkosten für Parser, Server, Entwicklungsumgebungen oder Personalzeit für die Bereitstellung, Administration und Pflege der beschafften Technik handelt, lässt sich letztlich in irgendeiner Form in Geldströmen umsetzen. Dieses Kriterium ist sicherlich ein wichtiges, doch lassen sich bei Auswahl einer bestimmten Alternative auch immer wieder unterschiedliche Unteralternativen für ihren Einsatz finden, die dann jeweils individuelle Kosten für ihren Einsatz bedeuten. Daher sollte dieses Kriterium als zusätzliches gesehen werden, weil es eine tiefer gehende Analyse erfordert.
Im Hinblick auf XSLT darf allerdings kurz gesagt werden, dass sein Einsatz sehr kostengünstig ist, in allen gängigen Programmiersprachen zur Verfügung steht und es auch kostenlose Parser gibt. Diese Kostengünstigkeit gilt allerdings auch für die unterschiedlichen Alternativen, wenn die Programmiersprache, mit der sie umgesetzt werden sollen, bereits genutzt wird.

Herstellerunabhängigkeit

Neben möglichen Lizenzkosten sollte jeweils bei Verwendung einer Technik überlegt werden, inwieweit man sich mit ihrem Einsatz in die Fänge des Herstellers begibt, der die Technik bereitstellt. Im Rahmen einer einfachen XML-Anwendung, so wie sie hier angenommen wird, existieren prinzipiell keine speziellen Probleme der Herstellerabhängigkeit, denn fast alle Techniken werden vom W3C entwickelt.
Allerdings kann es bei sehr fortgeschrittenen Anwendungen, für die das W3C noch keine Standards verabschiedet hat und für die unterschiedliche Ersatzlösungen existieren, dazu kommen, dass ein Einsatz sehr wohl in eine ungewünschte Abhängigkeit von einem Hersteller mündet. Als typisches Beispiel ist hier die Modellierung und Verarbeitung von Ontologien zu nennen, für die vom W3C zurzeit (Ende 2004) noch keine geeigneten Techniken bereitgestellt werden und XSLT und XQuery noch nicht alle Wünsche erfüllen.
Da allerdings die Hürden oder – besser gesagt die komplexen Fragestellungen – bei Ontologieprojekten viel mehr in der Datenmodellierungsphase liegen, muss man hier ohnehin sehr viel Zeit darauf verwenden, die geeigneten Techniken auszuwählen. Dabei ist die Auswahl der Transformationstechnik wichtig, aber tatsächlich nicht entscheidend für die Anwendung.

Technische Unterstützung

In Zusammenhang mit den Einsatzkosten und der Herstellerunabhängigkeit kann man als weiteres Kriterium auch die technische Unterstützung anführen, die bei der Auswahl aus der Vielzahl an Alternativen vom Hersteller geleistet wird. Dies ist allerdings ein Kriterium, das weniger auf das Ziel, XML zu transformieren, bezogen ist, sondern mehr ein allgemeines Kriterium zur Bewertung eines Einsatzes einer bestimmten Technologie darstellt und wegen seiner Allgemeinheit nicht notwendigerweise beachtet werden muss.
In den folgenden Absätzen werden wir auf die einzelnen Alternativen und XSLT selbst unter Hervorhebung seiner Vorteile zu sprechen kommen. Wenn Sie sich für eines dieser Themen interessieren, dann sollten Sie entsprechende Fachliteratur für das jeweilige Thema bzw. in der von Ihnen benutzten Programmiersprache einholen.

CSS

Die einfachste Möglichkeit für Entwickler, die bereits Erfahrung mit HTML und CSS (Cascading Stylesheets) haben, stellt natürlich die Verarbeitung von XML mit Hilfe von CSS dar. Auf der technischen Seite sind allerhand Vorkehrungen zu treffen. Zu diesen zählen ein Browser, der am besten mindestens CSS 2 unterstützt, und ein XML-Dokument, das nur die Inhalte besitzt, die tatsächlich auch ausgegeben werden sollen, und dessen Struktur linear verarbeitet werden kann. Zusätzlich kann man sich die Arbeit sehr erleichtern, wenn man sich zwar ausführlich mit der Technik und dem Grundkonzept von CSS (ebenfalls vom W3C) beschäftigt, aber die genaue Syntax weitestgehend außer Acht lässt und sich vielmehr die Erstellung derselben von einem Webdesignprogramm mit CSS-Unterstützung abnehmen lässt. In Adobe GoLive®, MS Frontpage® oder Macromedia Dreamweaver® lassen sich CSS-Stile auf eine hervorragende Art und Weise wie Formatvorlagen in MS Word® über leicht verständliche und intuitive Benutzeroberflächen zusammenstellen, die auch hervorragenden Quelltext erzeugen. In vielen Programmen sind auch heute noch nicht alle Syntaxregeln von CSS zu finden, und leider sind die Dekorationsmöglichkeiten teilweise so umfangreich, dass sie in nur wenigen oder auch keinen Browsern umgesetzt werden können, doch im Großen und Ganzen findet man schnell heraus, welche Attribute verwendbar sind und welche nicht.

Informationen zu CSS findet man neben unzähligen Darstellungen in Webdesign- und Entwicklerbüchern für Internetanwendungen natürlich insbesondere beim W3C. Hier lässt sich – wie bei allen Standards – auch sehr genau nachvollziehen, was technisch oder theoretisch möglich wäre und was möglicherweise zwar in einigen Webdesignprogrammen angeboten, aber ebenso möglicherweise in diesem und jenen Browsern (noch) nicht funktioniert.

• Cascading Style Sheets, level 1, W3C Recommendation 17 Dec 1996, revised 11 Jan 1999 unter http://www.w3c.org/TR/CSS1
• Cascading Style Sheets, level 2 revision 1, CSS 2.1 Specification, W3C Candidate Recommendation 25 February 2004 unter http://www.w3.org/TR/CSS21/
• CSS3-Diskussionspapiere, Vorschläge etc. unter http://www.w3c.org/Style/CSS/current-work

Grundsätzlich stellt die Darstellung von XML-Daten mit Hilfe von CSS eine einfache Dekoration und Auszeichnung der in der Datei auffindbaren XML-Tags und Attributen dar. Dabei lassen sich mit Hilfe von CSS fast überhaupt keine komplexen Abläufe umsetzen. Schon gar nicht ist es möglich, Reihenfolge, Fallunterscheidungen oder Verarbeitungen wie z.B. in Form von Berechnungen durchzuführen. Dies ist nicht von prinzipieller Bedeutung für den Einsatz von CSS, doch zwingt diese Tatsache die Dokumente in eine besonders einfache Form, da sie nur linear von oben nach unten zu verarbeiten sind und »hier und da« typische Formateigenschaften wie Block-, Absatz- und Zeichenformate anzugeben sind. Über die Blockstrukturen von CSS lassen sich dann auch Formate wie Absätze, Blöcke und Rahmen erstellen.

Ein so genannter Selektor greift über die allgemeine Syntax Selektor {Eigenschaft: Wert} auf Elemente im XML-Dokument zu und weist ihnen aus den zahlreichen Möglichkeiten der Formatierung geeignete Formate zu. Dabei lassen sich letztendlich allerdings nur dekorative Eigenschaften für die Textgestaltung verwenden und bei Weitem keine anspruchsvollen Transformationen durchführen, wie sie gerade mit dem DOM oder natürlich XSLT möglich sind.

Die geringe Komplexität der Syntax geht verständlicherweise mit einer geringen Komplexität der Transformationsmöglichkeiten einher. Wenn dies gerade sinnvoll ist oder die XML-Dateien derart einfach strukturiert sind und die Daten ohnehin nur in ein lesbares Format ohne XML-Tags und Attribute gebracht werden sollen, kann CSS eine denkbare Alternative sein. Dieser Umstand verringert auch die Lernkosten auf ein Minimum bzw. für Entwickler, die mit HTML/CSS bereits umgehen können, auf die bloße Erkenntnis, dass Element-Selektoren, wie sie für HTML-Tags verwendet werden können, auch für ein XML-Dokument nützlich sind. In CSS 2 sind sogar Attribut-Selektoren nötig, sodass die Dokumente nicht mehr auf Attribute verzichten müssen, sondern auch diese Strukturen aufweisen können. Zusätzlich besteht auch die Möglichkeit, die aus HTML bekannten Klassenselektoren über das Attribut class und die Wertzuweisung einer mit einem Punkt zu Beginn ausgezeichneten CSS-Vorlage zu verwenden. Dies erzeugt dann im XML-Dokument die Form <elementname class="cssvorlage"> und erfordert im CSS-Dokument die Syntax .Selektor {Eigenschaft: Wert}. Zu beachten ist an der zuletzt gezeigten allgemeinen Syntax der Punkt vor dem Selektornamen. Er stellt damit einen neuen Bezeichner dar und repräsentiert nicht einen Elementnamen, der als Bezeichner bereits vom XML-Dokument zur Verfügung gestellt wird.

Insgesamt ist die Anwendung von CSS für die XML-Darstellung sehr einfach, kann schnell realisiert werden und erfordert letztendlich nur einen geeigneten Browser, der das Dokument darstellt. Problematisch wird es, wenn doch einmal etwas anspruchsvollere Darstellungen notwendig werden oder aus einem Dokument Daten gefiltert, sortiert bzw. anders verarbeitet werden sollen, als sie nur dekorativ darzustellen. Dann gibt es überhaupt keine Möglichkeit, dieses Ziel mit CSS zu erreichen, und man muss eigentlich notwendigerweise auf XSLT umsteigen, wenn man weiterhin eine schnelle Transformation im Browser durchführen möchte.

SAX

SAX (Simple API for XML) zählt zu den berühmten Quasi-Standards, die weniger auf den Rückhalt einer starken Organisation wie das W3C oder die ISO vertrauen dürfen, sondern mehr auf die Popularität ihrer Webseite (http://www.saxproject.org/) hoffen. In sehr vielen Programmiersprachen ist der SAX-Parser implementiert und lässt sich auf unterschiedliche Weise ansprechen und nutzen. In einigen Systemen ist er auch nicht mehr verfügbar, weil mehr auf das DOM und XSLT – also W3C-Standards – gesetzt wird als auf proprietäre Umsetzungen von Quasi-Standards.

Die Verwendung in z.B. PHP ist relativ simpel, wenn auch im Vergleich zu anderen Möglichkeiten der XML-Verarbeitung die Anzahl benötigter Quelltextzeilen bei der Verwendung von SAX etwas umfangreicher ist. Das Kernstück des ereignisorientierten Transformationsprozesses ist eine Fallunterscheidung, in der den öffnenden und geschlossenen Tags, den Attributen und Textknoten geeignete Verarbeitungsanweisungen mit auf den Weg gegeben werden. Der Parser übersetzt dann den gesamten XML-Strom anhand der verschiedenen Fallunterscheidungen für die Ereignisse »Tag offen«, »Tag geschlossen« oder »Textknoten gefunden« in einen Ausgabestrom, der z.B. aus HTML-Tags bestehen kann.

DOM

Das Document Object Model ist wiederum ein vom W3C entwickelter Standard, der unterschiedliche Schnittstellen für die Bearbeitung von XML-Dateien bietet. Man muss deswegen von Bearbeitung sprechen, weil die verwendbaren Methoden gerade über eine bloße Transformation bzw. eine Umwandlung von einem Eingabe- in einen Ausgabestrom hinausgehen. Vielmehr gibt es auch solche Methoden, die man dafür einsetzen kann, ganz neue XML-Dokumente zu entwickeln, ohne dass die dabei eingesetzten Daten in irgendeiner Form aus einer anderen XML-Quelle stammen müssten.

Nähere Informationen zu diesem Standard erhält man nicht in Büchern zu diesem Standard alleine, sondern nur in Kombination mit einer Programmiersprache. Möchte man also das DOM mit Java verwenden, so benötigt man ein entsprechendes Fachbuch zum Thema XML-Verarbeitung mit Java, in dem die einzelnen Methoden und typischen Programmstrukturen vorgestellt werden. Die offizielle Dokumentation ist in den Fällen interessant, in denen man beispielsweise die in einer Programmiersprache zur Verfügung stehenden Schnittstellen/Klassen des Parsers und ihre jeweiligen Methoden mit den theoretisch verfügbaren vergleichen möchte. Informationen findet man z.B. im Dokument Document Object Model (DOM) Level 3 Core Specification, Version 1.0, W3C Recommendation 07 April 2004 unter http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/.

Die Verwendung des DOM ähnelt sich in den unterschiedlichen Programmiersprachen, doch ist eine Übertragung eines einmal entwickelten Algorithmus nur möglich, indem er in einer anderen Programmiersprache nachgebildet wird. Letztendlich verhält es sich mit dem DOM-Parser so, als würde man eine neue Funktionsbibliothek/Paket/Klasse oder Ähnliches verwenden. Die Transformation an sich ist direkt mit der Programmiersprache verwoben, wie dies auch bei SAX der Fall ist.

Vorteilhaft sind die sehr hohe Komplexität und die Vielfalt im Einsatz des DOM. Es lassen sich neue Dokumente erzeugen, bestehende verändern und natürlich in andere Formate umwandeln. Dabei mag eine Veränderung auch eine Umwandlung sein, wenn XML nach XML gebracht wird. Da die Syntax sehr umfangreich ist, fügen wir einige kurze Ausschnitte aus einer allgemeinen Syntaxstruktur für die Schnittstelle zur Knoten-/Elementverarbeitung an, damit Sie sehen können, welche Möglichkeiten alleine für die Knotenverarbeitung existieren. Die verfügbaren Methoden wurden aus Platzgründen zusammengestrichen, aber es lässt sich dennoch gut nachvollziehen, wie umfangreich das Angebot ist.

Attribute eines Elements verarbeiten in Form von Auslesen, Setzen, Löschen:

interface Element : Node {
  readonly attribute DOMString       tagName;
  DOMString          getAttribute(in DOMString name);
  void               setAttribute(in DOMString name, 
                                  in DOMString value)
                                        raises(DOMException);
  void               removeAttribute(in DOMString name)
                                        raises(DOMException);
  Attr               getAttributeNode(in DOMString name);
  Attr               setAttributeNode(in Attr newAttr)
                                        raises(DOMException);
  Attr               removeAttributeNode(in Attr oldAttr)
                                        raises(DOMException);
  NodeList           getElementsByTagName(in DOMString name);
...
};    

Eine Herausforderung für das Erlernen des DOM – erhöhte Lernkosten im Vergleich zu SAX – stellt die Vielzahl der verfügbaren Methoden und Datentypen dar. Insbesondere die Datentypen, die von Methoden zurückgegeben und von Methoden erwartet werden, erzeugen vorgegebene Programmstrukturen, die man zunächst erlernen muss, um zum gewünschten Ziel zu kommen. Dennoch erweist sich das Erlernen des DOM dann als sehr einfach, wenn man bereits gut mit einer anderen Programmiersprache vertraut ist. Dies erzeugt verständlicherweise niedrigere Lernkosten.

Was die Komplexität anbetrifft, so haben wir bereits erwähnt, dass die Verwendung des DOM wesentlich über die Möglichkeiten von SAX (die Variante CSS kann hier praktisch gar nicht zum Vergleich herangezogen werden) hinausgeht. Zusätzliche Vorteile, die sich auch gegenüber XSLT ergeben, finden sich dann, wenn man während einer längeren Transformation Programmaktivitäten ausführen möchte, die nicht direkt mit der Transformation zusammenhängen, sondern z.B. Informationen aus einer Datenbank abrufen oder ergänzende Protokolltextdateien erstellen sollen. Da die Verarbeitung mit Hilfe des DOM direkt innerhalb einer anderen Programmiersprache erfolgt, lassen sich naturgemäß alle anderen Bibliotheken der Sprache verwenden.

Gerade in solchen Fällen, in denen in einer Anwendung während einer Transformation noch zusätzliche Aktivitäten gleichzeitig ausgeführt werden sollen, bietet sich der Einsatz des DOM an. Zwar könnte man auch mit XSLT jeweils Teiltransformationen durchführen oder versuchen, Informationen, die zusätzlich aus Datenbankabfragen etc. benötigt werden, von vorneherein zu beschaffen und dem Prozessor als globale Parameter zu übergeben. Oftmals ist dies allerdings umständlich oder wird als Alternative nicht gewählt. XSLT eignet sich – kurz gesagt – insbesondere für solche Programmabläufe, in denen eine Quelle in ein Ziel umgewandelt werden soll und dieser Weg komplett und in einem einzigen Schritt durchgeführt werden soll. Einzelne Teiltransformationen durchzuführen ist zwar technisch eine ebenfalls gangbare Option, wird aber normalerweise nicht unbedingt ausgewählt, sofern nicht gerade andere Vorteile von XSLT höher bewertet werden als diese des DOM.