Websiteentwicklung: XSLT: Beschreibung

Websiteentwicklung XSLT Beschreibung

Was ist XSLT?

XSLT steht für eXtensible Stylesheet Language for Transformations. Es handelt sich um eine offizielle Empfehlung des W3C. Version 1.0 stammt von 1999, Version 2.0 von 2007, Version 3.0 von 2017.

Bei Version 3.0 kann es bei verschiedenen Programmen noch Implementierungslücken geben. Selbst Version 2.0 war auch 2015 noch nicht durchgehend oder überhaupt in aktuellen Programmen implementiert, die Version 1.0 verstehen.

Es handelt sich bei XSLT um eine XML-basierte Stilvorlagen-Sprache, mit welcher eine XML-Eingabedatei unter besonderer Berücksichtigung ihres strukturellen Aufbaus in beliebige, jedoch ebenso strukturierte textorientierte Ausgabeformate übersetzt, also „transformiert“ werden kann. „XSL“ als Namensbestandteil von XSLT dient dabei dazu, verschiedene Stilvorlagen-Sprachen und -Techniken unter diesem gemeinsamen Oberbegriff zusammenzufassen, da mit selbigen in Kombination unter vergleichsweise geringem Aufwand selbst komplexe Aufbereitungsprozessabläufe unter durchgängiger, ausschließlicher Verwendung von XML-Notation umgesetzt werden können. Benötigt wird natürlich immer ein Programm, welches die so notierte Transformation dann auch wirklich wie vorgesehen durchführt.

Die XSLT-Empfehlung betont dabei ausdrücklich, dass Quelldokument und Ausgabe voneinander unabhängig sind. Die Stilvorlage kann also aus dem Quelldokument Informationen entnehmen, um eine Ausgabe zu produzieren, muß es aber nicht. Auch wenn die Stilvorlage Informationen aus dem Quelldokument übernimmt, kann die Struktur der Ausgabe komplett anders gestaltet sein als es die Struktur des Quelldokuments vorgibt.

Einordnung

XML hat sich längst schon aufgrund des überschaubaren Sprachumfangs und Regelsatzes als universaler Standard für textorientierte strukturierte Datenformate durchgesetzt, was sich nicht zuletzt beim Blick auf die vielfältigen in XML formulierten Auszeichnungssprachen für alle möglichen Anwendungsgebiete zeigt. Die populärsten in XML formulierte Auszeichnungssprachen sind sicherlich XHTML und SVG, womit der Aufbau von Dokumenten im Netz beschrieben wird. Beliebter als XHTML ist allerdings die davon zu unterscheidende Vorgängerversion HTML, die noch kein XML-Format ist, also nicht von den einfachen Syntax- und Strukturregeln von XML profitieren kann, wenngleich man mittlerweile auch HTML-Dokumente schreiben kann, die den Syntax- und Strukturregeln von XML folgen, die dann wahlweise als XHTML oder HTML ausgeliefert oder interpretiert werden können. Beliebige HTML-Dokumente eigenen sich etwa im Allgemeinen nicht als Quelldokumente für XSLT, weil sie den Syntaxregeln von XSLT nicht genügen, man kann mit XSLT allerdings HTML als Ausgabe produzieren, wie auch andere Formate, die aus Klartext bestehen, binäre, verschlüsselte oder komprimierte Formate benötigen hingegen mindestens zusätzliche oder gänzlich andere Werkzeuge.

Historisch zeigte sich in der Fortentwicklung von HTML allerdings recht bald, dass die Darstellungsprogramme für HTML (sogenannte Brauser oder englisch auch browser), aber auch viele Autoren von dem zentralen Auszeichnungsgedanken abgewichen waren und nicht mehr länger die Information an sich anhand ihrer semantischen Bedeutung ausgezeichnet wurde, sondern stattdessen die Auszeichnung mehr und mehr der visuellen Darstellung der Information diente. Dabei war HTML doch von vornherein dazu angetreten, die Idee der semantischen Textauszeichnung erstmalig in die Praxis zu tragen. Semantische Auszeichnung nämlich ist maschinenlesbar, indem sich eine Information nicht implizit aus der Präsentation derselben erschließt oder eventuell erraten läßt. Im schlechtesten Fall ist gar die Intelligenz eines Menschen oder gar die Beratung durch den Autor des Dokumentes selbst erforderlich, um unter Auswertung des Kontextes die Bedeutung erfassen zu können. Semantische Textauszeichnung bedeutet, dass dafür mit der Auszeichnungssprache spezielle Meta-Information über den Inhalt notiert werden, welche einer Standardnotation folgen und sich somit über solche Meta-Informationen die Bedeutung des Inhaltes automatisch erschließen läßt. Damit werden auch recht einfache Programme zur Datenverarbeitung plötzlich in die Lage versetzt, auf semantische Datenbestände reagieren können. Als Beispiel sei ein violett eingefärbtes Wort inmitten von Fließtext angeführt – handelt es sich um einen Hinweis, um einen Verweis, um die Kennzeichnung eines Fehlers? Ein verarbeitendes Programm kann diese Unterscheidung nicht treffen. Bei einer semantischen Textauszeichnung hingegen wird als Meta-Information nicht angegeben, dass das Textsegment violett präsentiert werden soll, was ohnehin recht sinnlos wäre, wenn es vorgelesen wird oder auf einer Braille-Zeile präsentiert wird, sondern es wird angegeben, warum das Textsegment hervorgehoben wird. Da gerade dieses bei (X)HTML immer weniger geschah, stieß man früh auf die sich daraus ergebenden konzeptionellen Probleme.

Wenn eine Unterscheidung zwischen dem strukturellen Aufbau und der visuellen Darstellung nicht getroffen wird, muss eine Veränderung der Darstellung über eine Veränderung der Strukturangaben vorgenommen werden, obwohl sich weder der Aufbau ändert, noch die Strukturierungsangabe mit der visuellen Gestaltung von der Funktionsweise her im Zusammenhang steht. Um diesen Effekt zu verhindern, werden Struktur und Darstellung voneinander getrennt und nur über gemeinsame Identifikationsmerkmale zugeordnet, damit bei gleichbleibender Struktur eine andere Darstellung auf dieselben Daten und umgekehrt dieselbe Darstellung auf andere Daten, jedoch mit gleichen Identifikationsmerkmalen versehen, angewendet werden kann. Während besonders bei Textauszeichnungsprachen wie (X)HTML CSS als Gestaltungssprache zum Einsatz kommt, so wird in der weiteren Welt der XML-Strukturierungssprachen gerne auch mal XSL-FO für die Layoutdefinition herangezogen, zumal XSL-FO im Gegensatz zu CSS seinerseits selbst vollständig in XML formuliert ist. Nachdem nun eigene oder standardisierte XML-Formate die semantische Auszeichnung und Strukturierung von textorientierten Daten ermöglichen und mit XSL-FO oder auch CSS deren Darstellung spezifiziert werden kann, erlaubt darüber hinaus XSLT die strukturelle Umgestaltung vorliegender Datenbestände, wobei das Ergebnis einer Transformation dann auch nicht mehr unbedingt XML sein muss.

Typische Anwendungen

Bei den in der Praxis verwendeten XML-Formaten gibt es zwei charakteristische Typen von Inhalte oder Formaten, aber natürlich auch Mischformen davon. Gedacht war XML zunächst für die Auszeichnung von narrativen Textdokumenten, also Dokumenten, die Geschichten erzählen oder Inhalte anbieten, die primär für Menschen gedacht sind, die ein entsprechend geeignetes Hintergrundwissen haben, um den Inhalt zu verstehen. Solche Formate haben meist eine recht lockere, flexible Struktur, um jeglichen Inhalt geeignet abbilden zu können, es reicht meist als Auszeichnung, die semantische Bedeutung des jeweiligen Inhalts kennzeichnen zu können. Narrative Werke sind jedoch recht individuell aufgebaut, die Struktur unterschiedlicher Werke ist also recht unterschiedlich, entsprechend flexible muß ein narratives Format sein, welches all diese recht unterschiedlich strukturierten Inhalte sinnvoll abbilden können will.

Schnell ist jedoch klar geworden, dass sich XML auch gut eignet, um datenbasierte Information strukturiert abzulegen, vergleichbar mit einer Datenbank, jedoch bei Bedarf in viel allgemeinerer Form. Daten und Relationen zwischen ihnen werden als Objekte im solch einem XML-Format notiert, entsprechend gibt es auch ein XML-Dokument-Objekt-Modell (XML-DOM), um auf solche Objekte zuzugreifen, um sie zu manipulieren oder geeignet zu präsentieren.

Hat man als Ausgangsdokument ein datenbasiertes XML-Dokument, geht es bei einer darauf angewendeten Stilvorlage im Format XSLT häufig darum, die Daten anders zu sortieren, anders anzuordnen, um sie in einer Form aufzubereiten, die sich für die Interpretation und Weiterverarbeitung durch andere Programme besonders eignen.

Alternativ kann es auch darum gehen, die Daten geeignet aufzubereiten, um sie in ein narratives Format zu transformieren, welches sich gut dafür eignet, um die Daten Menschen in verständlicher oder verständlicherer Form zu präsentieren. Unterschiedliche Menschen haben unterschiedliche Stärken und Schwächen, wie sie Information gut verstehen. Bei einigen kann ein ausformulierter Text kompliziertere Zusammenhänge am einfachsten verständlich machen, andere mögen eine graphische oder akustische Präsentation bevorzugen. Etwa könnte hier eine XSLT-Stilvorlage dazu verwendet werden, um für statistische Daten, die im Ausgangsformat in Listen oder Tabellen stehen, eine Graphik etwa im Format SVG zu erzeugen, um mit Balkendiagrammen oder Kuchendiagrammen die Daten einfacher verständlich zu machen und so die Daten einem breiteren Publikum besser verständlich zu machen.

Hat man als Ausgangsdokument ein narratives XML-Dokument, so geht es oft darum, dies in ein anderes narratives Format zu transformieren, um es anderen Nutzergruppen zugänglich zu machen. Hat man etwa ein Dokument im Office-Format von Microsoft vorliegen, möchte man dies vermutlich in das Format von Libre/Open-Office oder gar (X)HTML konvertieren, um es allgemein zugänglich und bearbeitbar zu machen. Hat man etwa ein (X)HTML als Ausgangsdokument vorliegen, so kann es wünschenswert sein, dies nach Libre/Open-Office, Postscript, PDF zu konvertieren, um es optimal druckbar zu machen. Formate wie DocBook, TEI oder LML verfügen über reichhaltige Möglichkeiten, um Werke semantisch sehr gut auszuzeichnen, es gibt aber keine Programme, welche diese selbst gut präsentieren können. In einigen Fällen kann es ausreichen, eine geeignete Präsentation mit CSS zu ermöglichen, teilweise wird es aber auch sinnvoll sein, per XSLT nach (X)HTML zu transformieren.

Hinsichtlich der Schwierigkeit, eine passende Stilvorlage zu erstellen, kann man hier grob unterscheiden, ob man ein bestimmtes, bekanntes einzelnes Dokument konvertieren möchte oder eine allgemeine Stilvorlage entwickeln möchte, um ein beliebiges Dokument von einem Format A in ein Format B zu konvertieren, was eine wesentlich komplexere Aufgabe ist und zumeist impliziert, dass Format A einem recht strikten Schema folgen muß. Die Stilvorlage muß dann wiederum alle gemäß Schema möglichen Strukturen berücksichtigen, um für jegliches Ausgangsdokument eine sinnvolle Ausgabe zu produzieren und dabei jeglichen Informationsschwund oder eine Änderung der Bedeutung der Information vermeiden.

Ganz offenbar ist es viel einfacher, nur für ein bestimmtes Ausgangsdokument eine Stilvorlage zu schreiben, weil man darin eben nicht alle Möglichkeiten des Ausgangsformates berücksichtigen muß, sondern nur die tatsächlich verwendeten. Allerdings ist hier auch der Nutzen von XSLT stärker begrenzt, denn oft bedeutet es einen ähnlichen Aufwand, die Stilvorlage zu entwerfen, wie einfach manuell die Information vom Ausgangsdokument ins Zielformat zu übertragen. XSLT wird also erst richtig effizient, wenn damit zahlreiche Ausgangsdokumente eines Formates A in eine Ausgabe im Format B transformiert werden können, auch ohne den genauen Inhalt der Ausgangsdokumente zu kennen. Immerhin ist es bei datenbasierten Dokumenten auch oft möglich, immer die gleiche Struktur im Dokument zu haben, also die gleiche Abfolge von Elementen und Verschachtelungen von Elementen, nur die Dateninhalte der Elemente oder die Werte der Attribute ändern sich. Auch bei solch speziellen Dokumentklassen ist es oft recht einfach möglich, eine generelle Stilvorlage für eine Transformation zu schreiben und damit ein recht effizientes Werkzeug zu bekommen, um Konversionen oder Präsentationen automatisch erstellen zu lassen.

Grenzen der Anwendung

Ganz offenbar zeigen sich aber auch deutliche Grenzen des Verfahrens:
Will man von Format A nach B konvertieren, es mangelt aber dem Format B an Strukturen, um jegliche semantische Information, die im Ausgangsdokument notiert ist, zu berücksichtigen, so tritt bei einer Konversion offenbar ein arger Informationsschwund ein, das Ergebnis ist also durchweg als inhaltlich mangelhaft anzusehen. Mangelt es umgekehrt Format A an ausreichenden Möglichkeiten, um den Inhalt semantisch gut auszuzeichen, so nützt es auch wenig, wenn Format B all diese Möglichkeiten hat, weil man sie bei einer automatischen Konversion gar nicht nutzen kann. Zwangsläufig ist es dann also notwendig, den Inhalt des Ausgangsdokumentes mit menschlichem Verstand zu analysieren, um dann mit dem Format B eine sinnvolle semantische Aufbereitung zu realisieren.

Beliebt ist es in diesem Zusammenhang besonders bei narrativen Formaten wie (X)HTML, Open-Office, Microsoft-Office, FictionBook, DocBook, DTBook/Daisy, TEI, LML, RTF, Mobi, KF8, PDF etc mit XSLT oder ähnlich realisierten Programmen, von einem Format in ein anderes automatisch zu konvertieren. Zumindest wenn man mit einem Format beginnt, welches semantisch reichhaltige Auszeichnung ermöglicht und man diese auch wirklich verwendet, so geht bei einer automatischen Konversion oft sehr viel nicht nur semantische Information verloren, entweder weil das Zielformat gar nicht die passenden Auszeichnungsstrukturen bietet oder die Stilvorlage zur Transformation viel zu einfach gehalten ist, um das Ausgangsformat ohne Informationsverlust auf das Ausgabeformat abzubilden. Hier ist also Vorsicht angesagt, sowohl für jene, die solche fertigen Transformations-Hilfen nur nutzen, aber gerade auch bei jenen, die sie erstellen, denn wenn man sich dabei das Leben zu leicht macht, hat das ganz offenbar schwerwiegende Folgen für alle Nutzer der Hilfen und auch für die Leser oder allgemeiner Rezipienten der Ergebnisse. Wie bereits angedeutet, gerade Dokumente in narrativen Formaten können eine sehr komplexe Struktur anweisen, die bei jedem einzelnen Werk stark individuell ausgeprägt sein kann, weswegen eine allgemeine Transformationshilfe für semantisch gut ausgezeichnete narrative Werke meist eine sehr komplexe Aufgabe ist, deren kompetente Lösung viel Erfahrung und detaillierte Kenntnisse über Ausgangs- und Zielformat voraussetzt.

Ferner kann es auch einfach sein, dass die Daten in Format A ungeeignet für eine Präsentation im Format B abgelegt sind. Zwar kann man mit XSLT auch einfache Rechnungen durchführen, XSLT beinhaltet aber keine sehr umfangreichen Möglichkeiten, um wirklich Daten von einer numerischen Repräsentation in eine andere zu überführen, nicht triviale Wechsel von Koordinatensystemen etwa für die Repräsentation von Strukturen in einer Ebene oder im dreidimensionalen Raum oder gar in der Raumzeit werden meist über die in XSLT eingebauten Möglichkeiten hinausgehen. So kann es also schwierig sein, mathematische oder naturwissenschaftliche Datenbestände per XSLT etwa nach SVG zu transformieren, um sie visuell darzustellen, wenn nicht bereits das Ausgangsmaterial in geeigneter Form abgelegt ist, also den Möglichkeiten von XSLT und SVG gerecht wird. Bei diesem Beispiel verfügt nun SVG selbst über eine Möglichkeit einfacher affiner Koordinatentransformationen, auch die Kombination mit XSLT reicht da aber nicht, um nicht triviale, nicht affine Koordinatentransformationen umzusetzen, dafür braucht es zusätzliche Programme, Skripte oder DOM-Manipulationen.

Ein weiteres Problem kann sich ergeben, wenn das Format A des Ausgangsdokumentes praktisch beliebig komplex ist. Will man etwa von DocBook, LML oder Tei nach (X)HTML transformieren, stößt man recht schnell auf das Problem, dass (X)HTML zwar viele nützliche Funktionen hat (Formulare, interaktive Verweise, Einbinden von Graphiken, Bildern, Audio, Video etc), aber im Grunde der Wortschatz zur semantischen Textauszeichnung recht mager ausgelegt ist. Immerhin kann man dann heute auf (X)HTML+RDFa ausweichen, um per RDFa die semantische Bedeutung von (X)HTML-Strukturen anzugeben. Dokumente im Format (X)HTML+RDFa wiederum können nahezu beliebig komplex sein, eine geeignete automatischen Konversion von diesem Format in ein anderes kann beliebig kompliziert werden, was auch eintreten kann, wenn in einem Dokument Strukturen aus verschiedenen Namensräumen verwendet werden, man denke nur an die inzwischen recht naheliegende Möglichkeit, (X)HTML, MathML und SVG in einem Dokument zu kombinieren.

Zusammenfassend kann man also sagen, dass trotz oder vielleicht auch gerade wegen des eigentlich recht überschaubaren Funktionsumfanges von XSLT die Komplexität und der Umfang von Stilvorlagen stark davon abhängt, wie abstrakt oder allgemein die zu erledigende Aufgabe ist. Darüberhinaus kann es zahlreichen Transformations-Aufgaben geben, für die XSLT nicht geeignet ist.

Hoch zu XSLT | Vor zu Vorbereitung