XSLT in Webapps: Diplomarbeit

Der Abschnitt beginnt mit der Feststellung, dass die Problematik der Dokumentformatierung nicht neu ist und bereits 1997 mit dem ersten Vorschlag für die eXtensible Stylesheet Language (XSL) durch das W3C adressiert wurde. XML wird als Weiterentwicklung und Vereinfachung der Standard Generalized Markup Language (SGML) dargestellt, während XSL eine ähnliche Vereinfachung der auf SGML basierenden Document Style Semantics and Specification Language (DSSSL) darstellt. SGML und DSSSL, die in den 1980er Jahren entstanden, erwiesen sich als zu komplex für eine praktische Umsetzung. Die Weiterentwicklung von XSL führte zu Begriffen wie XSL, XSL-FO und XSLT, die verschiedene Teilgebiete der XML-Darstellung abdecken und oft die Sprache XPath 2 zur Navigation in XML-Dokumenten verwenden. Diese Vielzahl an Begriffen und Technologien erschwert die Übersichtlichkeit. Fünf Jahre nach der offiziellen XSLT 1.0 Empfehlung durch das W3C war die Verbreitung von XSLT deutlich geringer als die von XML. Ein Grund hierfür ist die Konkurrenz durch Cascading Stylesheets (CSS), die eine einfachere und schnellere Formatierung von XML und HTML Dokumenten ermöglichen.

Der Abschnitt beschreibt die Struktur von XML-Dokumenten. Der XML-Markup wird definiert als Menge von Start- und End-Tags, leeren Element-Tags, Entity-Referenzen, Zeichenreferenzen, Kommentaren und weiteren Komponenten. Der Elementname definiert gleichzeitig den Elementtyp, und Elemente können Attribute mit Namen und Werten enthalten. Die Nachteile von Document Type Definitions (DTDs) werden angesprochen: ihre abweichende Syntax von XML erschwert die Auswertung, und ihre Möglichkeiten zur Überprüfung von Datenwerten sind begrenzt. Die Wohlgeformtheit von XML-Dokumenten wird definiert: Ein wohlgeformtes Dokument enthält ein oder mehrere Elemente, genau ein Wurzelelement, und korrekt verschachtelte Elemente. Das Namensraumkonzept ermöglicht die Verwendung erweiterter Namen, bestehend aus Namensraum-Namen und lokalen Namen, um Namenskonflikte zu vermeiden. Diese erweiterten Namen werden oft durch Präfixe abgekürzt.

XSLT wird als zweistufiger Prozess beschrieben: strukturelle Transformation und Formatierung. Aus diesem Grund wurde XSLT von XSL getrennt, wobei XSLT für die Transformation und XSL bzw. XSL-FO für die Formatierung zuständig sind. Der Abschnitt vergleicht XSLT mit Cascading Stylesheets (CSS). CSS, einschließlich CSS2, dient primär der endgültigen Formatierung von HTML und XML-Dokumenten, wobei es gestalterische Aspekte wie Schriftart, -größe und -farbe steuert. Im Gegensatz dazu bietet XSLT mehr Möglichkeiten, wie die Änderung der Elementreihenfolge oder Berechnungen, ist aber komplexer und ressourcenintensiver. Die Kombination von XSLT (zur Strukturerstellung) und CSS (für das Layout) wird als sinnvoll erachtet, um spätere Änderungen zu erleichtern. Im weiteren Verlauf des Dokuments wird 'Stylesheet' synonym zu 'XSLT Stylesheet' verwendet.

Der Abschnitt beschreibt XSLT Prozessoren, deren Aufgabe die Anwendung von XSLT-Transformationen auf XML-Daten ist, um neue XML-Datenstrukturen zu generieren. Diese Prozessoren arbeiten in der Regel mit einer Baumstruktur der XML-Daten. Zwei wichtige APIs, SAX und DOM, die auch die Grundlage der XSLT-Prozessoren bilden, werden kurz erläutert. DOM baut eine Baumstruktur des Dokuments im Speicher auf, während SAX sequenziellen Zugriff ermöglicht. Der Vorteil von XSLT liegt in seiner deklarativen Natur durch die Verwendung der XML-Syntax. Obwohl dies die Formulierung von Formatierungsregeln erleichtert, kann es bei komplexeren Berechnungen als Nachteil angesehen werden. Die regelbasierte Verarbeitung von XSLT Stylesheets mittels Templates wird erklärt; die Reihenfolge der Regeln ist prinzipiell bedeutungslos. Die inkrementelle Ausführung von Transformationen wird als theoretischer Vorteil genannt, der aber in der Praxis durch die benötigte vollständige Datenquelle limitiert ist.

Die Anforderungen an Programm- und Sendeplanungssysteme bei der ProSiebenSat.1 Media AG haben sich aufgrund einer veränderten Medienlandschaft stark gewandelt. Fenstersender, Live-Sender und individualisierte Programmabläufe führen zu einem erhöhten Planungsaufwand. Die bestehenden Systeme sind nicht flexibel genug, um auf kurzfristige Änderungen in der Programm- und Werbeplanung zu reagieren, insbesondere bei der Planung von Werbeblöcken, die für die Finanzierung der Sendergruppe essentiell sind. Diese Ineffizienzen im Planungsprozess bilden den Ausgangspunkt für das ProSeco-Projekt.

Das Projekt ProSeco zielt auf den Entwurf und die Implementierung neuer Planungssysteme ab, die sowohl den neuen funktionalen Anforderungen der Sendergruppe gerecht werden als auch neue Technologien berücksichtigen. Das Ziel ist ein reibungsloser Planungsablauf, der auch langfristig gewährleistet ist. Die entwickelten Systeme bilden die Plattform für die Datenhaltung und alle Planungsaufgaben im Broadcastbereich – von der strategischen Programmplanung über die Sendeplanung bis hin zur Sendeabwicklung. Die genaue Technologiewahl wird nicht im Detail beschrieben, aber es ist ersichtlich, dass neue Technologien, inklusive vermutlich XSLT für die Datenverarbeitung und Transformation, zum Einsatz kommen sollen.

XSLT wird als deklarative Sprache beschrieben, die die XML-Syntax verwendet. Dies vereinfacht die Formulierung von Formatierungsregeln. Allerdings kann die XML-Syntax als Nachteil angesehen werden, wenn XSLT wie eine Programmiersprache für komplexere Berechnungen eingesetzt wird. Ein Beispiel für eine einfache Zuweisung in XSLT wird gezeigt. Die Möglichkeit, auf Funktionen externer Bibliotheken (z.B. Java) zuzugreifen, wird erwähnt, wobei die volle Unterstützung dieser Funktionalität erst in der noch nicht finalen XSLT 1.1 Spezifikation vorgesehen ist und von der Implementierung des XSLT Prozessors abhängt.

Die Abarbeitung eines XSLT Stylesheets erfolgt hauptsächlich über definierte Regeln in Form von Templates. Die Reihenfolge der Regeln ist prinzipiell irrelevant, was XSLT zu einer deklarativen Sprache im Gegensatz zu prozeduralen Sprachen macht. Die Funktion A = S(E) (Ausgabe = Stylesheet(Eingabe)) wird vorgestellt, um die reine funktionale Natur von XSLT zu verdeutlichen. Der Entwurf von XSLT orientiert sich an funktionalen Programmiersprachen, um inkrementelle Transformationen zu ermöglichen: Änderungen in einem Teil eines Datensatzes sollen idealerweise nur eine Teil-Neuberechnung der Darstellung erfordern. Diese inkrementelle Transformation ist jedoch derzeit bei keinem verfügbaren XSLT Prozessor vollständig implementiert.

Die Aufgabe eines XSLT-Prozessors besteht in der Anwendung von Transformationen, die in XSLT-Stylesheets beschrieben sind, auf XML-Daten. Er generiert neue XML-Datenstrukturen. Ein Prozessor arbeitet nicht direkt mit XML-Dokumenten, sondern mit deren Baumstruktur. Daher muss er nicht unbedingt XML-Dokumente parsen oder serialisieren, obwohl dies in den meisten Implementierungen enthalten ist. Die Arbeit erwähnt zwei wichtige APIs: SAX (Simple API for XML) und DOM (Document Object Model). Während DOM eine komplette Baumstruktur im Speicher aufbaut, ermöglicht SAX sequenziellen Zugriff. Anwendungen, die diese APIs nutzen, sind stark an die Struktur des XML-Dokuments gekoppelt, was bei Änderungen an der Struktur zu Problemen führen kann.

Zur Navigation in XML-Dokumenten wird XPath verwendet, welches eine eigene Spezifikation hat und zwar unabhängig von XSLT, jedoch eng mit XSLT verzahnt ist. Aus Gründen der Übersichtlichkeit wird im weiteren Verlauf der Arbeit keine Unterscheidung mehr zwischen XSLT und XPath getroffen. Die Arbeit erwähnt fop (von der Apache Gruppe), einen XSLT Prozessor, der auch XSL-FO Anweisungen verarbeitet und PDF-Dokumente generieren kann; Xalan wird als Standard XSLT Prozessor von fop genutzt. Der Vorteil von fop ist die freie Verfügbarkeit, obwohl nicht alle Merkmale von XSL-FO vollständig umgesetzt sind.

SchedEx ist in die Gesamtarchitektur von ProSeco integriert und dient als Plattform für die Datenhaltung und alle Planungsaufgaben im Broadcastbereich. Es besteht aus Servlets und Enterprise JavaBeans (EJBs), die im Applikationsserver laufen. Der Zugriff auf die Datenbank (SePla und andere) erfolgt über EJBs; ein Cache-Mechanismus optimiert den Zugriff auf häufig verwendete Daten. Sendeplandaten sind über ein Servlet abrufbar, das Datum und Sender-ID als Parameter erhält. Das System liefert die Daten in verschiedenen Formaten (XML-Stream, DOM-Document, HTML) zurück. Ein Streaming-Mechanismus wird erwähnt, der über eine XSLT-Transformation Playlists (ASX-Format) für den Browser generiert.

Der SchedEx Viewer wird als relativ kleine Komponente innerhalb des ProSeco-Projekts beschrieben. Die Anforderungen umfassen funktionale Aspekte (Darstellung von Sendeplänen mit XSLT) und nicht-funktionale Aspekte (Performance, Sicherheit). Nicht-funktionale Anforderungen werden in einer zentralen Datenbank der PSI (wahrscheinlich ein internes System) verwaltet. Das Design folgt dem Model-View-Controller (MVC)-Pattern, wobei Model 2 mit Java Server Pages (JSPs) und Servlets verwendet wird. Die Benutzeroberfläche wird in mehrere Teilsichten unterteilt. Die Verwendung von HTTP als Kommunikationsprotokoll ermöglicht eine gewisse Unabhängigkeit von anderen Systemkomponenten.

Für die Webanwendung werden J2EE-Technologien eingesetzt. Struts und Cocoon Frameworks werden als mögliche Optionen für die Benutzeroberfläche bzw. das Publishing erwähnt, werden aber letztendlich nicht verwendet. Transformer und TransformerFactory aus J2EE ermöglichen die Einbindung verschiedener XSLT-Prozessoren zur Laufzeit. Ein ErrorListener fängt Meldungen des Prozessors ab und schreibt sie in ein ProgressBean. Das TransformServlet dient als Controller, der auf SchedEx und Daten aus DataBean zugreift, um die gewünschte Version des Sendeplans anzuzeigen. Das MVC-Pattern wird zur Strukturierung der Benutzeroberfläche verwendet, wobei Menü und Sendeplan-Model getrennt behandelt werden. Für die Darstellung dynamischer Inhalte wird Macromedia Flash als performantere Alternative zu Java Applets bevorzugt.

Bei der Implementierung der XSLT-Transformationen wird die Frage nach der zu verwendenden XSLT-Version (1.0 oder 1.1) gestellt. XSLT 1.1 bietet Neuerungen wie die Aufteilung der Ausgabe in mehrere Dokumente und standardisierte Einbindung von Extension Functions, wird aber nicht weiter verfolgt. Die Organisation der Stylesheets erfolgt über verschiedene Verzeichnisse: ALL (für alle Rollen gültige Layout-Definitionen und Transformationen), und UTIL (für allgemeine Funktionen wie Zeitkonvertierung und String-Manipulation). Diese Struktur soll Änderungen am Datenmodell vereinfachen, indem diese nur an einer zentralen Stelle vorgenommen werden müssen.

Die Darstellung der Sendezeiten muss Lücken und Überlappungen erkennen und anzeigen. Die Überprüfung basiert auf der Annahme, dass einige Sendeelemente feste Startzeiten haben (Attribut FIX mit Wert 1 in SCHEDULE_ITEM). Für Elemente zwischen diesen festen Startzeiten wird die Startzeit anhand der vorhergehenden Elemente und deren Längen berechnet. Abweichungen von den eingetragenen Startzeiten (Fixzeitverletzungen) werden während der XSLT-Transformation erkannt und dargestellt. Ein rekursiver Aufruf des Templates <xsl:template name="CALCULATE_TIMES"> berechnet fehlende Längenangaben in Millisekunden.

Für dynamische Aspekte, z.B. ein Menü, wird die Kommunikation zwischen verschiedenen Technologien beschrieben: Java (Server-Seite), HTML (Seitenaufbau), Javascript (Client-seitige Interaktion), und Flash (für performante Aktualisierungen). Die Kommunikation zwischen Java und HTML erfolgt über die Übergabe einer ID an die JSPs, welche die Views erzeugen. Diese ID wird dann an Javascript und schließlich an Flash weitergegeben. Flash Remoting MX ermöglicht die Kommunikation zwischen Flash und dem Java Application Server über ein SOAP-ähnliches Protokoll. Ein Flash Gateway konvertiert ActionScript-Objekte in Java-Objekte und umgekehrt. Zur Vermeidung von Performance-Problemen bei der Fortschrittsanzeige wird ein ProgressDelegate zwischen Flash Gateway und ProgressBean eingesetzt.

Der ItemTracker zeigt das aktuell laufende Sendeelement und seine verbleibende Dauer an. Er erhält die Daten über einen XML-Stream, der durch eine XSLT-Transformation generiert wird. Die aktuelle Zeit und die Daten des Sendeplans werden zur Ermittlung des aktuellen Elements verwendet. Die Interaktion mit der Hauptsicht erfolgt über Javascript-Aufrufe aus Flash. Der StreamingBrowser nutzt den Windows Media Player (WMP) zum Anzeigen von Video-Streams und implementiert die Playlist-Funktionalität in Javascript, da die WMP-Funktionen eingeschränkt sind. Eine erneute XSLT-Transformation generiert eine Playlist im ASX-Format.