Webapplikationen mit Unterstützung von XML

Navigation:

Inhalt -> 4 Webapplikationen und XML -> 4.4 Trennung von Datenstruktur, Daten und deren Darstellung

Neues und Änderungen << Vorheriges Kapitel | Nächstes Kapitel >>

Andererseits liegen die Daten in einer einfach zu verarbeitenden Form vor. Nämlich in Form von XML-Dokumenten, die idealerweise einem Dokumenttyp entsprechen. Diese Quell-Dokumente können somit entweder einfach erstellt oder beliebig weiterverarbeitet werden. Z.B. aus anderen Anwendungen importiert oder in andere Anwendungen exportiert werden. Beispielsweise kann ein weiteres XSLT-Script daraus XSL-FO-Dokumente erstellen, aus denen dann wiederum PDF- oder Postscript-Dokumente entstehen.58

Für professionelle Anwendungen

Die Verwendung von CSS zum Festlegen des Layouts ist bezüglich der Komplexität mit HTML zu vergleichen. Nicht so jedoch die Verwendung von XSLT. XSLT ist eine funktionale Programmiersprache, die etwas gewöhnungsbedürftig ist, da viele nur prozedurale oder objektorientierte Programmiersprachen kennen. XSLT-Scripts sollen aus den XML-Quelldokumenten XHTML-Dateien erstellen. Das XSLT-Script gibt daher zumindest die grobe Darstellung der Webseite vor. Im Idealfall allerdings nur jene Dinge, die mit CSS nicht möglich sind.

Normalerweise sind für das Design einer Webseite Webdesigner zuständig. Diese sind aber teilweise bereits mit HTML überfordert und werden großteils nicht in der Lage sein, XSLT-Scripts zu schreiben. So gesehen müssen hier fast immer mindestens zwei Personen eingesetzt werden. XSLT erleichtert also nicht die Arbeit der Webdesigner. Es wird daher hauptsächlich für größere professionelle Systeme oder für Webseiten mit einfachem Design interessant sein.

Serverseitige XSLT-Verarbeitung

Die Erzeugung der XHTML-Seiten aus den XML-Daten mit Hilfe von XSLT kann entweder am Server oder am Client erfolgen. Erfolgt die Erzeugung am Server, werden nur die XHTML-Seiten, inkl. CSS Stylesheets an den Client gesendet. Der Client sollte damit in jeden Fall umgehen können.

Mit Apache Cocoon steht bereits eine leistungsfähige, Java-basierte Umgebung zur Verfügung, die diese Vorgangsweise serverseitig unterstützt. (Siehe Kapitel 2.4.5 Programmierumgebungen für Webapplikationen.) Natürlich ist das auch mit anderen Programmiersprachen möglich.

Problematisch ist allerdings, dass die Verarbeitung mit XSLT - vor allem bei großen Quelldokumenten - viele Ressourcen (Prozessor, Speicher) benötigt. Daher werden hier meist Caches eingesetzt, sodass die Seiten nicht bei jedem Abruf generiert werden müssen. Alternativ können die XHTML-Seiten vorgeneriert und wie statische HTML-Seiten auf einer Festplatte gespeichert werden. Dadurch kann das Abrufen der Seiten besonders ressourcenschonend - wie bei statischen HTML-Seiten üblich - erfolgen. In regelmäßigen Abständen - oder bei Änderungen der Quelldaten - werden dann die XHTML-Seiten neu generiert. IBM ist bei seinem Webauftritt auf diese Methode umgestiegen, nachdem sich gezeigt hatte, dass das dynamische Generieren der Seiten beim Aufruf derselben die Server zu sehr belasten würde. [Goldfarb 2000]

Das Problem beim Zwischenspeichern oder Vorgenerieren ist allerdings, dass das nur funktioniert, wenn einzelne Seiten nicht zu viele verschiedene Ausprägungen haben. Falls z.B. jede Seite in mehreren Sprachen vorhanden sein soll, sollte es kein Problem sein, diese für jede Sprache extra zu generieren. Sind Seiten allerdings personalisiert - dass also verschiedene Benutzer verschiedene Inhalte sehen - so ist das Vorgenerieren oder Zwischenspeichern kompliziert bis gar nicht möglich. Bei Webapplikationen sind Seiten oft komplett an den Benutzer angepasst, sodass dies unmöglich ist. Bei vielen Webseiten sind aber nur bestimmte Teile personalisiert und ein großer Teil für alle Benutzer gleich. Hier könnte also ein hybrides System eingesetzt werden. Bestimmte Teile werden zwischengespeichert, andere werden bei jedem Abruf neu generiert. Einige namhafte Hersteller wie IBM oder Oracle haben eine XML-basierte Spezifikation namens "Edge Side Includes" (ESI) entwickelt, die unter anderem erlaubt, Webseiten in Fragmente aufzuteilen, die jeweils extra zwischengespeichert bzw. neu generiert werden. (www.esi.org/.) Auch z.B. für PHP gibt es so ein System, das partielles Caching innerhalb eines PHP-Scripts erlaubt (siehe: www.zend.com/store/products/performance_partial_output_caching.php). Solange sich aber noch keine Standards durchgesetzt haben, könnte man so etwas auch manuell implementieren. Auch für andere Programmiersprachen, insbesondere bei der Verwendung von XSLT, wäre das äußerst interessant.

Clientseitige XSLT-Verarbeitung

Der große Vorteil einer clientseitigen Verarbeitung von XSLT-Scripts wäre, dass der Server nur die Quelldaten und das XSLT-Script ausliefern muss. Die Verarbeitung läuft am Client ab, für den das - insbesondere bei PCs - kein Performanzproblem sein sollte. Somit sind auch vollständig personalisierte Seiten möglich.

Zur Zeit ist das Problem an der clientseitigen Verarbeitung allerdings eines der Webbrowser: Alte Browser, wie z.B Netscape 4.x, aber auch der aktuelle Opera 7.03, können XSLT noch überhaupt nicht verarbeiten. Und Microsofts Internet Explorer hat bis zur Version 5.5 einen XSLT-Prozessor integriert, der noch nicht auf die endgültige W3C-Empfehlung von XSLT basiert ist. Da sich aber bei der Empfehlung noch einiges geändert hat, sind diese Browser, die noch sehr verbreitet sind, nicht kompatibel mit der aktuellen XSLT-Empfehlung und damit mit den neuen Browsern, wie IE 6.0 und Mozilla [Kay 2001]. So gesehen kann eine clientseitige XSL-Verarbeitung noch nicht öffentlich eingesetzt werden.

Bei der clientseitigen Verarbeitung enthält das XML-Dokument, das an den Browser gesendet wird, einen Verweis auf das XSL-Stylesheet. Dieses enthält den XSLT-Code, der das XML-Dokument in eine XHTML-Seite transferieren soll. Dieser XHTML-Code wird schließlich am Browser angezeigt. Das XSL-Stylesheet muss daher - wie auch CSS-Stylesheets - zusätzlich geladen werden. Soll das XML-Dokument mit einem anderen XSL-Stylesheet dargestellt werden, so muss dieses andere Stylesheet im XML-Quellcode angegeben, und somit sowohl das XML-Dokument, bei dem sich nur die Stylesheet-Angabe geändert hat, als auch das neue Stylesheet, neu geladen werden.

Es könnte aber praktisch sein, die Verknüpfung von XML-Dokument und Stylesheet in der URL definieren zu können. So wäre es möglich, ein XML-Quelldokument einmal zu laden und mit verschiedenen XSL-Stylesheets verschiedene Teile oder in verschiedenen Ansichten darzustellen. Es hat zwar in W3C-Mailinglisten Anfragen zu diesem Thema gegeben, auf diese wurde aber nicht näher eingegangen.

Vermutlich ist das in der Praxis deswegen nicht besonders interessant, weil dabei große XML-Dokumente an den Browser gesendet werden, aus denen dann die XSLT-Scripts clientseitig die Information für eine XHTML-Seite entnehmen. Wenn aber sowieso nur die Informationen im XML-Dokument enthalten sind, die in der zu generierenden XHTML-Seite angezeigt werden sollen, dann kann dieses Dokument problemlos jedesmal - mit dem entsprechenden XSL-Stylesheet - neu geladen werden. Es könnte aber sein, dass der Bedarf an einer anderen Zuordnungsmöglichkeit zwischen XML-Dokument und XSL-Stylsheet steigt, falls die clientseitige XSLT-Verarbeitung vermehrt zum Einsatz kommt. Zur Zeit wird das - wie oben erwähnt - noch von zu wenig Webbrowsern standardgemäß unterstützt.

58So entstand übrigens auch diese Arbeit. Siehe Anhang Metadaten.