18.2 Cocoon

Unter dem Namen Cocoon wurde von Stefano Mazzocchi und anderen im Rahmen des Java Apache Project ein Java-Servlet zum XML-basierten Web-Publishing entwickelt. Mittlerweile gibt es ein eigenes Apache XML Project (http://xml.apache.org/). Die Idee hinter Cocoon ist die gleiche wie zuvor: XML-Fähigkeit in den Server übertragen. Genauer heißt das, dass ein Dokument unter Trennung seiner Komponenten Inhalt (Text, Grafik usw.), logische Struktur (etwa Gliederungen) und Darstellung (z.B. Formatierung am Bildschirm oder für Print-Ausgabe) verarbeitet wird. Dies ist genau die Idee, die in SGML und letzlich auch in XML eingeflossen ist. Die Grundfunktionen von Cocoon entsprechen ungefähr der zuvor beschriebenen CGI-Variante. Im Gegensatz dazu ist Cocoon jedoch (als Servlet) ein Bestandteil des Servers und baut außerdem auf offenenen W3C-Standards auf. Der modulare Aufbau erlaubt außerdem weitergehende Anwendungen, wie sich später zeigen wird.

Abbildung 67: Vereinfachtes Verarbeitungsmodell von Cocoon

Der Ablauf der Verarbeitung in Cocoon ist recht einfach und in Abbildung 67 dargestellt. Ein als Datei vorliegendes XML-Dokument wird von einem Parser in eine interne Baumdarstellung, das Document Object Model (DOM), überführt. Auf dieser Datenstruktur arbeitet ein XSL(T)-Prozessor und erzeugt eine Ausgabe. Diese allgemeine Beschreibung ist auch tatsächlich so allgemein implementiert. Durch die Verwendung von Standardschnittstellen lassen sich die verwendeten Programme austauschen — sie müssen allerdings in Java geschrieben sein. Als Parser unterstützt Cocoon zurzeit (Februar 2000) Apache XercesXerces basiert auf dem Parser von IBM. und Sun ProjectX. Als XSLT-Prozessoren stehen zur Verfügung Apache Xalan und James Clarks XT. Zur PDF-Erzeugung dient James Taubers Fop, der mittlerweile als Apache Fop auch Teil des Apache-Projekts ist.

Um lediglich XML-Dateien on the fly in HTML zu wandeln, kann man genau so vorgehen, wie oben bei der CGI-Lösung beschrieben. In die XML-Dateien wird die Processing Instruction für das Stylesheet eingetragen, und Cocoon wandelt, zusammen mit dem Parser und dem XSLT-Prozessor, die Daten in HTML. Allerdings hat Cocoon noch mehr zu bieten. Die W3C-Empfehlung zur Verknüpfung von Dokumenten mit Stylesheets (Anhang B ) definiert für die Processing Instruction ein Pseudoattribut namens media. Damit lässt sich eine Ausgabe für verschiedene Browser realisieren. In der XML-Datei sieht das zum Beispiel so aus:

<?xml version="1.0"?>
<?xml-stylesheet href="graphics.xsl" type="text/xsl"?>
<?xml-stylesheet href="textonly.xsl" type="text/xsl" media="lynx"?>

...

Mit diesen Anweisungen benutzt Cocoon das Stylesheet textonly.xsl für den Browser lynx und für alle anderen Browser das Stylesheet graphics.xsl. Um den Browser zu erkennen, analysiert das Programm die HTTP-Header-Zeile User-Agent. In Abhängigkeit der darin enthaltenen, vom Browser an den Server übermittelten Informationen erfolgt dann die Zuordnung zu einem Stylesheet. Folgende Browsernamen sind in Cocoon voreingestellt:

explorer

für Microsoft Internet Explorer; sucht nach MSIE

opera

für Opera

lynx

für Lynx

java

für Java-Programme, die Standard-URL-Klassen verwenden (aus java.net.*)

wap

für den Nokia WAP Toolkit Browser

netscape

für Netscape Navigator; sucht nach Mozilla

Diese Zuordnungen lassen sich in der Konfiguration leicht ändern. Die nötigen Einträge stehen in der Datei cocoon.properties.

Mit dem bis hier beschriebenen System kann man nun also statische XML-Dateien an einen HTML-Browser ausliefern. Vor dem Hintergrund von Erweiterungen wie Server Side Includes (SSI), PHP u.a, die zum Standardrepertoire gehören, stellt sich bald die Frage, wie man denn dynamisch erzeugte Dokumentteile mit XML/Cocoon realisieren kann. Cocoon bietet als Rahmensystem die Möglichkeit, als mittlere Komponente in der Verarbeitungskette verschiedene so genannte Prozessoren einzusetzen. Diese Prozessoren arbeiten auf einer DOM-Datenstruktur. Es lassen sich mehrere solcher Prozessoren in Reihe schalten, vergleichbar zum Einsatz der Pipe in Unix-Shells (vgl. Abbildung 68). Einen der Prozessoren wollen wir hier noch näher betrachten, nämlich den XSP-Prozessor.

Abbildung 68: Cocoon: Verschiedene Prozessoren, die auf DOM-Daten arbeiten

Zuvor noch ein Wort dazu, wie Cocoon bestimmt, welcher Prozessor (und später welcher Formatierer) benutzt werden soll. Zu diesem Zweck gibt es zwei spezielle Processing Instructions der folgenden Form:

<?cocoon-process type="xxx"?> 

<?cocoon-format type="yyy"?>

Die erste Zeile legt fest, welcher Prozessor benutzt werden soll und die zweite Zeile bestimmt den Formatierer. Dazu nur zwei kleine Beispiele aus der Cocoon-Dokumentation:

<?cocoon-process type="xslt"?>

<?cocoon-format type="text/xslfo"?>

In diesem Beispiel wird das Dokument vom XSLT-Prozessor verarbeitet (erste Zeile) beziehungsweise vom Formatierer für text/xslfo (Formatting Objects) formatiert (zweite Zeile).

Wir wollen hier nicht zu sehr auf die Vor- und Nachteile der Cocoon-PIs eingehen. Einerseits haben wir uns bereits an anderer Stelle über grundsätzliche Schwächen von PIs ausgelassenNicht vergessen: PIs sind böse :-) und andererseits sehen selbstverständlich auch die Cocoon-Entwickler die Probleme. Als Folge davon wird bereits jetzt in der Cocoon-FAQ angekündigt, dass die PIs durch eine saubere Lösung ersetzt werden. Das heißt nicht, dass die heutige Realisierung nicht mehr funktionieren wird, sondern, dass es mit Cocoon 2 hoffentlich eine bessere Alternative gibt. Für die sofortige Verwendung sind die PIs eine schnelle und pragmatische Lösung, aber eben nicht mehr. Da nicht abzusehen ist, wann Cocoon 2 erscheint, sollten Sie unbedingt auf der Website nachsehen.

18.2.1 Extensible Server Pages (XSP)

18.2.2 Beispiel: Formatierung in PDF mit XSL

18.2.3 Beispiel: Simuliertes XLink mit Dynamic HTML/JavaScript

18.2.4 Installation