Die Extensible Markup Language (XML) und verwandte Techniken - etwa Extensible Style Language Formatting Objects (XSL-FO), XForms oder Extensible Business Reporting Language (XBRL) - spielen eine wichtige Rolle in der IT. Doch gerade im Content-Management-Umfeld ist XML etwas in Verruf geraten. Gar zu vollmundig waren die Versprechungen der Hersteller in puncto Kommunikation und Datenaustausch. So verkündeten sie etwa, mit der Auszeichnungssprache sei es quasi auf Knopfdruck möglich, Inhalte aus einem Content-Management-System (CMS) in ein anderes zu übernehmen. Tatsächlich aber erfordert die Migration von Webpages Detailarbeit in mitunter absurdem Umfang. Trotz der versprochenen Offenheit durch XML sind Anwender faktisch abhängig von ihrem Lieferanten.

Abhängigkeiten vermeiden

Richtig konzipiert und realisiert, kann der konsequente Einsatz von XML jedoch durchaus zu leistungsfähigen Online-Publishing-Systemen führen, die trotzdem auch einen Content-Austausch erlauben. Die Abhängigkeit von einzelnen Herstellern lässt sich dabei auf ein Minimum reduzieren.

Der Autor dieses Artikels konnte in einem umfänglichen Migrationsprojekt Erfahrungen mit einem XML-basierenden Content-System bei einem deutschen Konzern sammeln. Dabei wurden Inhalte zunächst in ein Zwischensystem und erst später in die eigentliche Produktivumgebung überführt.

Das resultierende System basiert auf Einzelprodukten dreier verschiedener Anbieter. Offene Standards wie XML, XSL und Cascading Style Sheets (CSS) erlauben es, Systemkomponenten auszutauschen, ohne die Systemarchitektur oder einzelne Funktionsbausteine kräftig ändern zu müssen.

Content-Management-Projekte in Konzernen haben oft eine lange Vorgeschichte, das hier beschriebene macht da keine Ausnahme. Anfangs betrieben verschiedene Abteilungen und Geschäftseinheiten mehr als 40 Websites auf sehr unterschiedlichen technischen Plattformen. Eine solche Situation war - und ist - für Großunternehmen nichts Ungewöhnliches. Gleichwohl wollten sich die Verantwortlichen von diesem Wildwuchs verabschieden.

Das Projekt, an dem die Elephant Seven AG maßgeblich beteiligt war, hatte eine Konsolidierung der Web-Präsenzen zum Ziel, so dass jedes Land, in dem der Konzern vertreten ist, eine eigene Website erhalten und alle Online-Systeme auf einer einzigen Plattform laufen sollten. Folgende Anforderungen waren zu erfüllen:

- Kompatibilität mit bestehenden Produkten von Sun (Hardware), Bea Systems (Applikations-Server) und Oracle (Datenbanken);

- Investitionssicherheit;

- weitgehende Unabhängigkeit von einem CMS;

- Flexibilität hinsichtlich künftiger Anpassungen an Struktur, Layout und Design;

- Berücksichtigung offener Standards speziell beim Austausch zwischen Systemkomponenten.

Projektchronologie

Das ursprünglich vorgesehene Web-Content-Management-Produkt wurde jedoch nicht rechtzeitig zum geplanten Relaunch des Internet-Auftritts fertig. Anstatt den Termin zu verschieben, entschlossen sich die Projektverantwortlichen, eine von Elephant Seven für die Inhaltserfassung entwickelte Software zu erweitern und als Interims-CMS zu verwenden. Auf dieser Basis wurde die neue Website zunächst online gestellt und für eine Übergangszeit betrieben.

Parallel dazu stellte das Team eine Content-Lösung auf Grundlage der Software "Communiqué" des Herstellers Day für den Dauerbetrieb auf die Beine. Dabei wurden unter anderem innerhalb von drei Wochen etwa 7000 Web-Seiten aus der Interimslösung in das finale System überführt.

Neutrales Content-Modell

Möglich war der zweimalige Wechsel der Zielplattform nur durch ein produktneutrales Content-Modell auf der Grundlage einer Document Type Definition (DTD). Bei vielen anderen Projekten - auch solchen, die der Autor dieses Textes begleitet hat - haben sich die Anwender früh auf ein bestimmtes WCM-Produkt festgelegt. Dies führte dazu, dass in der Folge bewusst oder unbewusst alles unternommen wurde, um dieser Software gerecht zu werden. Genau dies wollte das Projektteam vermeiden.

Selbstverständlich war es bei der finalen Migration auf Day Communiqué notwendig, kleine Modifikationen am Content-Modell vorzunehmen. Das ging jedoch bis auf wenige Ausnahmen über eine XML/XSL-Transformation.

Das realisierte WCM speichert alle Inhalte als Plain-Text, also ohne Formatierung oder Auszeichnung. Es gibt einige wenige Ausnahmen für spezielle, nicht systemnah unterstützte Gestaltungselemente, aber auch die legt das System im XML und nicht in HTML ab. Diese konsequente Trennung von Inhalt und Design sollte bei einem CMS eigentlich selbstverständlich sein. Die Praxis sieht jedoch oft anders aus und erschwert daher die Migration oder Zweitverwertung von Inhalten.

Im Gegensatz zu gängigen Lösungen am Markt erzeugen die Schablonen (Templates) die für den Besucher sichtbaren Seiten nicht im HTML-Format, sondern in XML. Die Inhalte übersetzt das System dann mittels eines XSLT-Prozessors und entsprechender XSLs in Hypertext Markup Language (HTML).

Änderungen an der inhaltlichen Struktur der generierten HTML-Seiten sind jederzeit möglich, indem man die XSL- und CSS-Dateien anpasst. Dabei ist es unerheblich, ob es um Details des Designs oder des kompletten Layouts der Seiten geht.

Alle wesentlichen Komponenten des Systems - insbesondere Content-Store und XSLT-Prozessor - können ohne großen Aufwand ausgetauscht werden. Tatsächlich ist dies im Projekt auf den verschiedenen Entwicklungs-, Test- und Produktionsplattformen teilweise geschehen. Umfangreicher war lediglich der Wechsel von der Interimslösung zum finalen WCM. Hierbei wurden unter anderem eine Redakteursoberfläche und ein Workflow-Management eingeführt. Die eigentliche Inhaltsverarbeitung blieb dabei unverändert.

XSLT frisst Rechenleistung

Einerseits bietet XML eine Reihe von Vorteilen, andererseits stellen solche Systeme hohe Anforderungen an die zugrunde liegende Hardwareplattform. So beanspruchen XSLT-basierende Transformationen unter Umständen viel Rechenzeit: Die Lösung benötigte zunächst mehr als 500 Millisekunden für das Rendering einer HTML-Seite und nochmals über zwei Sekunden, um diese auszuliefern. Das ist selbstverständlich inakzeptabel für eine Website mit einigen Millionen Visits im Monat und mit mehr als 1000 gleichzeitigen Benutzersitzungen. Solche Erfahrungen tragen dazu bei, dass sowohl Experten als auch WCM-Anbieter XML und XSLT mit Skepsis begegnen.

Das Projektteam passte die XSL-Stylesheets jedoch an. Häufig benötigte Styles wurden in der Dokumentenstruktur nach oben sowie an den An- fang der XSL-Datei verschoben. In einzelnen Fällen duplizierten die Mitarbeiter diese Abschnitte sogar. Allein dadurch ließ sich die Verarbeitung auf die Hälfte oder ein Drittel der bisherigen Dauer beschleunigen. Die Struktur der XSL-Dateien wurde dadurch allerdings komplexer und musste detailliert dokumentiert werden. Diese Mehrarbeit fällt jedoch in Relation zu den er- zielten Verbesserungen nicht ins Gewicht.

Auch die Caching-Architektur trug zu einer besseren Performance bei. So werden die online angezeigten Seiten selten direkt vom XSLT-Prozess erzeugt, sondern stammen fast ausschließlich aus einem der vorgelagerten Cache-Proxies. Prinzipiell lassen sich Websites auf diese Weise für beliebige Nutzerzahlen skalieren. In der Praxis ist das jedoch nicht ganz so einfach: Ein Cache vermag nur statische Inhalte zwischenzuspeichern, nicht jedoch die von einer Applikation dynamisch erstellten Pages. Letztere machen aber bei dieser Website einen vergleichsweise geringen Anteil am gesamten Content aus. Eine solche Herangehensweise erleichtert es dem Unternehmen derzeit, weiter an der Caching-Architektur zu feilen, um die weltweite Verfügbarkeit der Web-Seiten zu verbessern.

Die konsequente Trennung von Inhalt und Design/Layout machte es relativ einfach, Content-Versionen für verschiedene Browser-Generationen sowie Benutzer mit unterschiedlichen Bildschirmgrößen bereitzustellen. Heute lassen sich nahezu alle Seiten in zwei Versionen abrufen, von denen die eine für neuere Browser und Bildschirme ab 1024 Pixel in der Breite ausgelegt ist, die andere für ältere Browser und schmalere Displays.

Zwei unterschiedliche Sätze von XSL-Stylesheets erzeugen die beiden Versionen der HTML-Seite. Ein größerer Eingriff in die Applikationslogik war dazu nicht notwendig, da die Lösung zunächst für jede Page eine XML-Datei generiert, die der XSLT-Prozessor in nahezu jedes beliebige andere Format transformiert. Somit ließen sich auch Inhalte für mobile Geräte zur Verfügung stellen.

XHTML und CSS

Zurzeit überlegt das Anwenderunternehmen, das barrierefreie (behindertengerechte) HTML nicht mehr über verschiede- ne Varianten der generierten HTML-Seiten, sondern über die heute gängige Kombination aus Extensible HTML (XHTML) und Cascading Stylesheets zu generieren. Auch dieser Schritt würde für die XML-orientierte Systemarchitektur lediglich erfordern, einige XSLs und CSS-Dateien zu ändern und minimale Anpassungen in der Applikation vorzunehmen. So hätte das Unternehmen von Anfang an verfahren können, man sah jedoch davon ab, da noch immer ein großer Teil der installierten Browser in der Firma CSS nur ungenügend unterstützt.

Einer klaren Trennung von In- halt und Layout wirkt das bei vielen Content-Management-Anbietern mittlerweile offerierte "Rich Text Editing" entgegen. Gemeint sind Eingabefunktionen, die es dem Nutzer gestatten, den Inhalten beliebig wählbare Formatattribute zuzuweisen, vergleichbar mit den Formatoptionen von Textverarbeitungsprogrammen. Einerseits klingt das reizvoll, andererseits prallen hier zwei Interessen aufeinander: Die Redakteure wünschen sich möglichst viel Gestaltungsfreiheit, die Systemarchitekten hingegen legen Wert auf Inhaltsstrukturen mit sauberem, sprich standardkonformem HTML-Code.

Rich Text Editing

Mit einem solchen Editor erzeugte Texte sind vor allem dann problematisch, wenn Satzbreiten eingestellt, Formatierungen für Schriftgrößen und -farben formatiert sowie komplexe Strukturen aus Überschriften, Textblöcken und zahlreichen Links eingeführt werden. Diese Gestaltungsmerkmale lassen sich nachträglich nur schwer verändern. Unter Umständen ist es dann günstiger, bei ei- nem Systemwechsel die Web-Seiten erneut anzulegen, statt sie zu migrieren. Die heutigen RTF-Editoren legen die Auszeichnungen typischerweise nicht über CSS-Angaben ab. Dies würde auch die Möglichkeit der direkten Formatierung stark einschränken, da für jede Kombination von Gestaltungsmerkmalen, die dem Anwender in den Sinn kommt, zunächst ein geeigneter Style angelegt werden müsste.

Im Projekt wurde jede Seite modularisiert. Jedes Modul besteht wiederum aus mehre- ren Komponenten, die über simple Texteingabefelder bearbeitet werden. Zum Editieren stehen dem Anwender eine Texterfassung, Auswahllisten und Dialoge zum Einbetten von Bildern und anderen statischen Elementen zur Verfü- gung. In der aktuellen CMS-Lösung ist es möglich, zumindest Auszeichnungen wie fett und kursiv direkt in den Texten vorzunehmen sowie unterschiedliche Links und HTML-Anker anzulegen. HTML-Kenntnisse erfordert dies nicht.

Mühe zahlt sich aus

Eine Preview-Funktion verwendet exakt dieselben Stylesheets (XSL und CSS) wie die Produktionsumgebung. So können Redakteure vorher prüfen, wie ihre Seiten später auf der Website aussehen. Dies ist aber trotzdem nicht so komfortabel wie das Rich Text Editing.

Die Vorteile der strengen Trennung von Inhalt und Darstellung zahlten sich bereits nach wenigen Monaten aus. Wegen einer neuen Markenstruktur im Konzern musste etwa ein Viertel des Content unter einem neuen Design online gebracht werden. Dieses Unterfangen dauerte lediglich zwei Monate. (fn)