Back To Top

Struktur einer XML/XSLT-Anwendung


Grundstruktur einer XML-Anwendung

Comelio-Blog XSLT AnwendungXML-Neulinge, die sich bisher nur allgemein mit XML und vielleicht noch mit Dokumentmodellierung auseinander gesetzt haben, betreten mit XSLT eine ganz neue Welt. Wir sprechen deshalb von XML-Neulingen, da natürlich die Verarbeitung von XML-Daten ein zentraler Schwerpunkt im XML-Universum darstellt. In Seminaren oder Projektgruppen, denen wir XML-Kenntnisse vermitteln, ist es manchmal verwirrend, dass im Laufe von wenigen Tagen mehr und mehr Dokumente in der Entwicklungsumgebung zu betreuen sind. Beschränkt sich die Anzahl der Dokumente am Anfang auf ein einfaches XML-Dokument, so wird dies beim Thema Modellierung um die Syntax von XML Schema und wenigstens ein Schema-Dokument ergänzt. Im Verlauf der Veranstaltung reichen auch diese wenigstens zwei Dokumente nicht mehr als Spielmaterial aus. Die Liste der offenen Dateifenster wird um wenigstens eine Transformationsdatei in XSLT-Syntax ergänzt. Wir sprechen deswegen immer von wenigstens einem zusätzlichen Dokument, da sowohl die Syntax von XML Schema wie auch die XSLT Inklusionstechniken vorsieht, mit deren Hilfe Inhalte aus anderen Dokumenten abgerufen werden können.

Auf die einzelnen Dateien wollen wir hier noch einmal kurz eingehen, da aus ihnen jede XML-Anwendung besteht. Wie schon unsere Vorliebe für die Vorteile hinsichtlich der Auslagerung weiter oben deutlich wurde, so wird an dieser Stelle unsere persönliche Wertschätzung der Dokumentmodellierung deutlich.

Modellierung

Comelio-Blog XSLT AnwendungGrundsätzlich besteht unter Entwicklern allergrößte Übereinkunft, dass für das Gelingen eines beliebig skalierten Projekts die Datenmodellierung eine sehr hohe Bedeutung besitzt. Dennoch hören wir immer wieder gerade bei Datenbanken solche Kommentare wie »Eigentlich müsste diese Spalte so heißen wie diese andere, aber das ist in diesem Fall nicht so …«, »Das ist historisch gewachsen …«, »Ich habe das auch schon so übernommen, und jetzt kann man natürlich nichts mehr ändern …«, »Ach nein, diese Tabellen verwende ich gar nicht mehr; ich bin mir sowieso unsicher, was sie speichern und welche Teile der Anwendung auf sie zugreifen …« oder »Sie wissen ja, wie das ist mit diesen redundanten Daten …«

Sicherlich ist es für einen externen Berater immer sehr einfach, hier und dort Fehler zu entdecken und gegenüber dem akademisch Korrekten in der Realität Unstimmigkeiten auszumachen. Die Begründungen lassen sich auch wieder in passender Literatur finden, in denen die Software-Entwicklung mit Gruppensoziologie und Psychologie Hand in Hand geht. Die Gründe und Verhaltensmuster, die zu solchen Unstimmigkeiten und vor allen Dingen nachträglichen hohen Kosten hinsichtlich von Änderungs- und Wartungsarbeiten führen, sind theoretisch gut bekannt und vermutlich jedem Leser aus der eigenen Berufspraxis geläufig. Dies führt dann auch zu solchen ironischen Äußerungen anderer Branchen und Berufsgruppen, die auf die möglichen negativen Konsequenzen eingehen, die sich ergeben, wenn technische Konstruktionen wie Atomkraftwerke und Flugzeuge mit ähnlicher Qualität wie Software geplant und konstruiert werden würden.

Es ist allerdings – und das möchten wir auch genauso spitz formulieren, wie wir es jetzt machen – höchst unverständlich, warum Fehler, die über dreißig Jahren lang in Entwicklungsprojekten mit Datenbanken gemacht wurden, nun in viel auffälligerer Form auch in XML-Projekten wiederholt werden. Dies gilt umso mehr, wenn man sich vor Augen führt, dass XML eine derart neue Technologie ist, dass es wohl nicht übertrieben ist, wenn man Folgendes behauptet: Die Fehler in XML-Anwendungen werden genau heute gelegt. Genau in den Momenten, in denen wir diese Zeilen schreiben und in denen Sie in einigen Monaten diese Zeilen lesen, werden Entwickler alles Mögliche machen – und das sind im XML-Bereich offensichtlich viele Fehler.

Uns sind nur ganz wenige Projekte begegnet, in denen Daten für eine XML-Anwendung korrekt modelliert wurden. Was genau diese so genannte »korrekte Modellierung« ist und wie sie sich positiv und bei schlechter Modellierung dementsprechend negativ auf die Transformation und damit die Anwendung auswirken, wird Thema des dritten Bandes sein. Wir möchten nur bereits an dieser Stelle erneut betonen, dass die bloße Einfachheit, die mit XML prinzipiell einhergeht, nicht dazu führen darf, dass in dieser Sekunde die Grundlagen dafür gelegt werden, dass die oben zitierten Äußerungen für die in dieser Sekunde entwickelten Anwendungen ebenfalls gelten. Es ist zwar unwahrscheinlich, dass XML-Anwendungen eine so lange Laufzeit haben wie Anwendungen, die mit Datenbanken arbeiten, doch bei kürzerer Laufzeit mag man sich sogar noch an die Leute oder die Gruppe erinnern, die »damals« die Fehler in die Anwendung einbrachten, mit denen heute zu kämpfen ist oder die wenigstens regelmäßig zu den zitierten Äußerungen führen.

XSLT entfaltet ganz spezielle Vorteile, die indirekt mit der Syntax und direkt mit der Modellierung zusammenhängen. Man wird sich darüber unter Garantie nicht wundern, doch scheint diese Erkenntnis in den wenigstens Projekten wirklich gelebt zu werden. Man spricht über viele technische Details, setzt XML oft für erstaunliche und sehr innovative Lösungsstrategien ein, schafft es aber dennoch nicht, intelligente Bezeichner zu finden, einfache oder gewünschte Zugriffspfade zu gewährleisten, Vereinfachungen für Wartungsarbeiten bereits direkt in den Daten zu begründen oder flexible Dokumentstrukturen zu entwerfen. Das ist auf der einen Seite sehr schade für die Anwendungen, oftmals ein dankbares Feld für uns als Berater. Doch ärgerlich für alle Beteiligten und letztendlich auch für uns – und zwar wenigstens aus berufsethischen Gründen – ist, wenn man erst so spät zu einem Projekt gerufen wird, dass das Kind schon in den Brunnen gefallen ist und Änderungen aus so genannten »politischen Gründen« nicht mehr einfach möglich sind und quasi nur noch kosmetische Korrekturen zulässig sind. Auch hier hat vermutlich jeder genügend eigene Beispiele aus der Berufspraxis, die man zu Hause vielleicht beim Abendessen seufzend erzählt oder organisationsgegeben hinnimmt.

Validierung

Comelio-Blog XSLT AnwendungMit XML Schema oder der Document Type Definition (beides Techniken vom W3C) lassen sich Regeldokumente erstellen, die die Eingabedaten einer XML-Anwendung beschreiben. Über die Bedeutung dieser Modellierung wollen wir nicht erneut ein Wort verlieren, denn unsere Hochachtung trat sicherlich schon deutlich genug in und zwischen den Zeilen hervor. Sie ermöglichen eine genaue Angabe der inhaltlichen Strukturen und im Falle von XML Schema sogar der textuellen Inhalte in Form von gut entwickelten Datentypen. Die inhaltlichen Strukturen lassen sich in beiden Syntaxalternativen beschreiben, indem Bezeichner für Elemente und Attribute, die Häufigkeit bzw. das Auftreten von Elementen und die Hierarchie- und Reihenfolgenbeziehungen angegeben werden.

Ein erster Schritt einer einfachen XML-Anwendung besteht daraus, das eingehende XML-Dokument zu validieren, d.h. darauf zu überprüfen, ob es die Forderungen aus dem Regeldokument erfüllt. Nur solche Dokumente dürfen dann in die Transformation eingehen. Erst in einem zweiten Schritt wird dann die Transformation durchgeführt. Fehler, die dann noch auftreten, können sich eigentlich nicht mehr auf Fehler im Eingabedatenstrom selbst, sondern nur noch auf Fehler im XSLT-Dokument beziehen.

Leider wird standardmäßig von einem XSLT-Prozessor gar kein Regeldokument verlangt, sondern im Normalfall nur XML und XSLT. Man muss diesen Umstand insoweit bedauern, weil dadurch oftmals auch gar kein Schema-Dokument existiert oder – um der Dokumentation genüge zu tun – mit Hilfe eines Entwicklungswerkzeugs per Knopfdruck ein Regeldokument erzeugt wird. Dieses stellt aber für gewöhnlich nicht das Ergebnis eines Analyse- und Modellierungsprozesses dar, sondern repräsentiert das quasi »nachmodellierte« Ergebnis eines XML-Dokuments, das im schlimmsten Fall nur zu Testzwecken (»Wir nehmen erst einmal dieses …«, »Nachher können wir immer noch darüber sprechen …«) erzeugt wurde und »ungefähr« zu den tatsächlich gewünschten und benötigten Datenstrukturen konform ist.

Ob diese Situation anders wäre, wenn die Validierung nicht von einem speziellen Prozessor, sondern per Standardeinstellung vom XSLT-Prozessor durchgeführt werden würde, ist uns unklar. Vielleicht hätte sich die schlechte Verhaltensweise genauso eingeschlichen, sich teilweise weder mit den Techniken der Dokumentmodellierung zu beschäftigen, sondern der Einfachheit von »XML als HTML mit eigenen Tags« blindlings zu vertrauen und ins Verderben zu rennen.

Die gesamte Validierung stellt auf jeden Fall einen eigenen Schritt dar, der zeitlich vor der Transformation liegt. Er ist jedoch optional und wird nicht immer durchgeführt. Er sollte allerdings dafür sorgen, dass nur solche Dokumente in die Transformation eingehen, die auch erwartet werden.

Zusätzlich sorgt er für gewöhnlich motivierend dafür, dass man sich eingehend mit den Techniken der Modellierung, einer geeigneten Syntax und dann auch mit den wirklich vorhandenen oder für die Anwendung bereitzustellenden Datenstrukturen auseinander setzt.

Transformation

Comelio-Blog XSLT AnwendungDas Kernstück einer einfachen XML-Anwendung besteht dann aus der eigentlichen Transformation, für die neben dem XML-Eingabedokument ein XSLT-Dokument erwartet wird. Es ist technisch nicht ganz korrekt, im Zusammenhang mit XML von Dokumenten zu sprechen, denn theoretisch können alle Strukturen, die bisher immer als Dokument bezeichnet wurden, auch in Form von Variablenwerten oder in Form von ausgelesenen Datenbankergebnissen und nicht als tatsächlich auf der Festplatte vorhandene Datei auftreten. Der neutrale Begriff, der zu verwenden wäre, um nicht von vorneherein immer an Dateien zu denken, ist »Datenstrom« oder in Kombination mit »Eingabe-« und »Ausgabe-« auch »Eingabestrom« oder »Ausgabestrom«. Da die XSLT-Syntax letztendlich auch ganz gewöhnliche XML-Dokumente erzeugt, könnte man sogar von einem »Transformations(daten)strom« sprechen, denn auch diese Bestandteile lassen sich in einer Datenbank speichern und zur Laufzeit gerade auch ohne Dateizugriff in den Zwischenspeicher laden.

Für die Verwendung von XSLT gibt es noch einige zusätzliche Bestandteile, die teilweise nur für spezielle Prozessoren zugänglich sind oder teilweise auch in der Spezifikation und damit überall verfügbar sind.

Prozessoren bieten eine Vielzahl an Funktionen, die nicht im Standard vorgesehen sind und die teilweise die Entwicklung von Algorithmen sehr vereinfachen. Allerdings erschweren sie einen Umstieg auf einen anderen Prozessor, weil die Funktionen des einen Prozessors nicht die gleichen eines anderen Prozessors sind. Zusätzlich erlauben viele Prozessoren eine eigene Fehlerbehandlung wie z.B. das Zuweisen von Textdateien, in denen die Fehlermeldungen gesammelt werden.

In der XSLT-Syntax sind dann zusätzlich Möglichkeiten für dateibasierte Auslagerung und Wiederverwendung und die Verwendung von lokalen und globalen Parametern gegeben. Während Ersteres bereits sehr mit der Syntax von XSLT zusammenhängt, stellt der Einsatz von globalen Parametern eine nützliche Technik dar, die sich nur über einen Prozessor realisieren lässt. Ihm muss nämlich die aufrufende Anwendung geeignete Werte übergeben. Dadurch lassen sich die die Transformation beeinflussenden oder zu verarbeitenden Werte übernehmen und sehr flexible Transformationen einrichten.

Grundstruktur einer XML-Anwendung

Die Abbildung zeigt den allgemeinen Aufbau einer XML-Anwendung, bestehend aus einem Eingabedokument in XML, das die zu verarbeitenden Werte enthält, einem XML-Schema-Dokument, das die Regeln des Eingabedokuments beschreibt, und schließlich die XSLT-Datei, die die Transformationsanweisungen enthält. Das Ergebnis wird hier ebenfalls als Datei verdeutlicht, obwohl durchaus nicht notwendigerweise eine konkrete Datei auf der Festplatte entstehen muss. Ebenso liegt keine Verpflichtung für die anderen, hier als Datei bezeichneten, Inhalte vor, als Datei zu existieren. Die zu verarbeitenden, modellierenden und die Transformation angebenden Inhalte können auch nur flüchtig in einem Zwischenspeicher vorliegen und z.B. aus einem Datenbankergebnis stammen oder von einer Anwendung dynamisch zusammengesetzt werden.

Auf der senkrechten Achse sind Phasen, Aktivitäten oder Zustände verzeichnet, die innerhalb der Anwendung identifizierbar sind. In diesen Bereichen Modellierung, Datenspeicherung, Prüfung, Transformation und Ausgabe sind unterschiedliche Dokumente vonnöten oder auch mit Hilfe eines geeigneten Prozessors (Validierung, Transformation) zu kombinieren.

Auf der waagerechten Achse ist direkt über den Dokumenten ihre Hauptaufgabe verzeichnet, während innerhalb jedes Dokumentsymbols die jeweilige Dateiendung steht. Die Anordnung der einzelnen Dokumente korrespondiert mit den identifizierten Bereichen auf der senkrechten Achse.

Beachten muss man vor allen Dingen den grauen Pfeil zwischen dem Transformationsdokument und dem Datendokument.