Algorithmus zur Erstellung von Templates für XSL-Transformationen von/in verschiedene XML-Dialekte

Transkript

1 Algorithmus zur Erstellung von Templates für XSL-Transformationen von/in verschiedene XML-Dialekte Michael Wolfram M A S T E R A R B E IT eingereicht am Fachhochschul-Masterstudiengang Digitale Medien in Hagenberg im Juni 2008

2 Copyright 2008 Michael Wolfram Alle Rechte vorbehalten ii

3 Erklärung Hiermit erkläre ich an Eides statt, dass ich die vorliegende Arbeit selbstständig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt und die aus anderen Quellen entnommenen Stellen als solche gekennzeichnet habe. Hagenberg, am 30. Juni 2008 Michael Wolfram iii

4 Inhaltsverzeichnis Erklärung Kurzfassung Abstract iii viii ix 1 Einleitung Problemstellung Zielsetzung Aufbau Anwendungsfelder von Transformationssprachen Bereiche Presentation Oriented Publishing Message Oriented Middleware Methoden der Transformation DSSSL XSLT MetaMorphosis Proprietäre Algorithmen Fazit Ausgewählte Publishing-Formate und ihre Besonderheiten XHTML XSL-FO als Möglichkeit zur Druckausgabe SVG Fazit Ausgabeformate für Datentransfer XML CSV XML Grundlagen Wohlgeformtheit Gültigkeit iv

5 Inhaltsverzeichnis v 3.2 XML-Knoten Elemente Attribute Datentypen PCDATA CDATA CDATA-Abschnitt XML-Verarbeitung Ereignisgesteuerte Verabeitung Baumbasierende Verabeitung XML-Pull Verabeitung XSLT Grundlagen Aufbau eines XSLT-Sheets Element xsl:template Element xsl:apply-templates Element xsl:value-of Element xsl:output Conflict Resolution XSLT-Prozessoren Bewertung von XSLT-Prozessoren Fazit XPath Knotentypen Adressierung Achsen Knotentests Relative und absolute Pfade Prädikate XSL-Editoren Realisierung eines XSLT-Editors Anforderungen Wahl des Frameworks Struktur des realisierten Editors Grundlegende Hilfestellung User Interface Multiple Inputs Externe Libraries Beschränkungen Fazit

6 Inhaltsverzeichnis vi 6 Algorithmus für XSLT-Templates Grundsätzliche Überlegungen Problembereiche Bestehende Ansätze und Lösungen Generierung bei bekannter Struktur Analyse des XML-Schemas Semantischer Ansatz Fazit Schema und Funktionsweise Element-Matching Content-Matching Attribute-Matching Template Building Template Sorting Beschränkungen Format Quell- und Ergebnisdokument Angabe der DTD Größe Quelldokument Vorteile Nachteile Verbesserungsmöglichkeiten Multiple Inputs DTD-Angabe Einstellungsmöglichkeiten Tidy Evaluierung Aufbau der Evaluierung Auswahl und Zusammensetzung der Testgruppe Benutzertests Nachbesprechung und Bewertung Ausgangsfrage und Ziel Konventionelle XSLT-Template-Entwicklung Bedienung des Editors XSLT-Template-Entwicklung unter Einsatz eines Algorithmus Fazit der Evaluationsergebnisse Bewertung der Evaluation Ergebnisse und Ausblick 62 A Inhalt der DVD 64 A.1 PDF-Dateien A.2 Algorithmus-Dateien A.3 Quellen

7 Inhaltsverzeichnis vii Literaturverzeichnis 69

8 Kurzfassung Die Metasprache XML bietet die Möglichkeit Daten zwischen verschiedenen Systemen auszutauschen und diese in unterschiedlichen Ausgabeformaten zu präsentieren. Für die dazu notwendigen Transformationen der XML- Dokumente gibt es mit den Transformationssprachen DSSSL und XSLT sowie dem zielgetriebenen XML-Prozessor MetaMorphosis und der Entwicklung eigener, proprietärer Transformationsalgorithmen verschiedene Methoden, die sich unterschiedlich gut dafür eignen. Ein wesentlicher Punkt für die Wahl einer Transformationsmethode ist das gewählte Ausgabeformat, da gewisse Vorraussetzungen gegeben sein müssen und auf Besonderheiten des Ausgabeformats zu achten ist. Da die meisten der besprochenen Ausgabeformate selbst in einem XML-Dialekt geschrieben sind, liegt das Hauptaugenmerk dieser Arbeit auf XSLT. Die Entwicklung der für eine Transformation nötigen Regeln ist ein Bereich, in dem es aktuell kaum Unterstützung durch automatische Abläufe gibt. In dieser Masterarbeit wird dieser Aspekt genauer untersucht und eine Möglichkeit aufgezeigt Entwickler bei dieser Arbeit zu unterstützen, indem ihnen eine Entwicklungsumgebung bereit gestellt wird, in der, basierend auf Beispieldokumenten, Transformationsregeln dynamisch generiert werden. Dabei werden die Entwicklung eines Algorithmus für die automatische Generierung von XSLT-Transformationsregeln begleitet und wichtige Problemfelder wie die Mustererkennung in formalen Sprachen oder das Matching einzelner Knoten der Beispieldokumente untersucht und mögliche Lösungen aufgezeigt, sowie die realisierte Entwicklungsumgebung in praktischen Tests evaluiert und Vor- und Nachteile der Algorithmus-gestützten Entwicklung von Transformationsregeln dargestellt. viii

9 Abstract The metalanguage XML offers a way to share structured data across different systems as to present it in various publishing formats. There are several methods to transform the XML documents such as the transformation languages DSSSL and XSLT, the target-driven XML-processor MetaMorphosis and self-developed, proprietary transformation-algorithms. Major aspects that have to be considered before the choice of a transformation method are the target format and its characteristics. Due to the fact that most of the output formats are XML based themselves, this thesis main focus is on XSLT. The biggest problem in the development of the needed transformation rules is that there are no supporting algorithms at the moment. Therefore this aspect is analysed and ways are shown to support developers working on transformation rules by providing a development environment with an integrated algorithm that generates XSLT-templates based on example documents. The development of this algorithm is shown as are difficult problems like pattern recognition in formal languages and node-matching in example documents. Finally there is a usability and performance test of the development environment with its integrated algorithm and advantages and disadvantages of the algorithm-supported development of transformation rules are identified. ix

10 Kapitel 1 Einleitung 1.1 Problemstellung Transformationssprachen wie XSLT oder DSSSL werden eingesetzt, um Daten aus einem XML-Format in eine anderes Format oder einen anderen XML- Dialekt zu transformieren. Eine ausschließlich manuelle Entwicklung der dafür notwendigen Transformationsregeln ist jedoch äußerst aufwendig und bedarf umfangreichen Testens, um Fehler und Auswirkungen auf bestehende Regeln auszuschließen. Hierbei gibt es bis dato keinerlei assistierenden Technologien, ausgenommen XSL-Editoren, die aber nur generelle Hilfestellung wie XML-Syntaxhighlighting oder die Erstellung von XPath-Ausdrücken bieten. 1.2 Zielsetzung Das Ziel dieser Arbeit ist es, die Entwicklung von Transformationsregeln in XSLT zu erleichtern. Dafür soll ein Algorithmus entwickelt werden, der selbstständig, basierend auf vom Benutzer bereitgestellten, beispielhaften, Quell- und Ergebnisdokumenten, die Regeln definiert, die notwendig sind, um mittels einer XSL-Transformation das angegebene Quelldokument in das ebenfalls definierte Ergebnisdokument zu transformieren. Dazu ist es nötig, verschiedene Ausgabeformate auf ihre speziellen Eigenschaften zu untersuchen und allgemein gültige Methoden zu finden, um Elemente und Attribute der Quelldokumente in ihr entsprechendes Gegenüber in den Ergebnisdokumenten abbilden zu können. Zudem muss eine Methode entwickelt werden, um die im Ergebnisdokument abgebildeten Elemente und Attribute nicht nur in ihren Namen und Werten zu verknüpfen, sondern auch deren Position im Ergebnisdokument identifizieren und dementsprechend adressieren zu können (z. B. über XPath). 1

11 1. Einleitung 2 Abschließend soll evaluiert werden, ob die durch den erstellten Algorithmus unterstützte Entwicklung von XSLT-Templates wesentliche Vorteile im Vergleich zu einer ausschließlich manuellen Entwicklung bietet und auftretende Nachteile und Verbesserungsmöglichkeiten sollen identifiziert und bewertet werden. 1.3 Aufbau Die Arbeit selbst ist in fünf wesentliche Teile gegliedert. Im ersten Teil werden die Anwendungsfelder von Transformationssprachen generell besprochen. Dabei wird auf die Trennung der Anwendung zum Einen zur Zwecke der Darstellung, dem Presentation Oriented Publishing, zum Anderen zum Zwecke des reinen Datenaustauschs zwischen Systemen, der Message Oriented Middleware, eingegangen und die entsprechenden Formate (XML, XSL-FO, SVG,...) und ihre Besonderheiten besprochen. Des weiteren werden verschiedene Technologien zur Transformation von XML- Daten untersucht und Unterschiede sowie Vor- und Nachteile der einzelnen Methoden dargestellt. Im zweiten Teil werden die nötigen Grundlagen zur Realisierung eines Algorithmus für die automatische Generierung von XSLT-Templates besprochen und anhand praxisbezogener Beispiele gezeigt. Dabei wird speziell auf Besonderheiten und Vorraussetzungen der Anwendung auf XML- Dokumente, den Aufbau von XSLT-Templates, deren wichtigsten Elemente und Funktionen und die Erstellung von XPath-Ausdrücken eingegangen sowie abschließend unterschiedliche XSLT-Prozessoren auf ihre Eignung für die Einbindung in die zu realisierende Applikation untersucht. Der dritte Teil beschreibt die Realisierung eines XSLT-Editors als Plugin für die Entwicklungsumgebung Eclipse. Dabei wird auf die Realisierung der grafischen Benutzeroberfläche eingegangen und Usability-Aspekte erklärt die ausschlaggebend für die realisierte Form derselben waren. Weiters wird die Wahl des verwendeten Frameworks und der eingesetzten Technologien besprochen und werden Probleme und Fragestellungen angesprochen, die bei der Entwicklung des Plug-ins aufgetreten sind. Danach folgt eine Erklärung der einzelnen Funktionen des entwickelten Editors. Im vierten Teil wird die Implementierung eines Algorithmus für die automatische Generierung von XSLT-Templates basierend auf Vergleichen von Quell- und Ergebnisdokumenten beschrieben. Dabei wird sowohl auf die Problembereiche bei den Vergleichen und der Identifikation von entsprechenden Bereichen im Quell- und Ergebnisdokument und verschiedene existierende Matching-Algorithmen aus verschiedenen Bereichen eingegangen als auch die tatsächliche Implementierung besprochen. Abschließend werden bestehende Einschränkungen und Verbesserungsmöglichkeiten des Algorithmus aufgezeigt.

12 1. Einleitung 3 Der letzte Teil stellt eine Evaluierung des entwickelten Algorithmus dar. Basierend auf Benutzertests und nachfolgenden Besprechungen werden Vorund Nachteile einer automatischen Generierung von Templates für XSL- Transformationen ausgemacht und entsprechende Schlüsse gezogen. Im Anhang findet sich der Fragebogen, der bei der Evaluierung des entwickelten Algorithmus mit den Testern durchgegangen wurde, sowie (auf DVD-ROM) das erstellte Eclipse-Plug-in AAXS MultiPageEditor, mit dem die Funktionsweise des Algorithmus praktisch getestet werden kann.

13 Kapitel 2 Anwendungsfelder von Transformationssprachen 2.1 Bereiche Grundsätzlich kann man das Einsatzgebiet für Transformationssprachen in zwei große Bereiche teilen: Das Presentation Oriented Publishing auf der einen und die Message Oriented Middleware auf der anderen Seite Presentation Oriented Publishing Mit Presentation Oriented Publishing bezeichnet man alle Anwendungen, die eine Transformation von Daten zum Zwecke ihrer Darstellung durchführen. Als gängige Publishingformate seien hier genannt: Hypertext Markup Language (HTML) (speziell die Extensible Hypertext Markup Language (XHTML) sowie die Wireless Markup Language (WML)) für die Darstellung im World Wide Web (WWW) Extensible Stylesheet Language Formatting Objects (XSL FO) zur Vorbereitung der Druckausgabe in verschiedenen Formaten Scalable Vector Graphics (SVG) für Grafiken/Diagramme DocBook 1 /LaTeX 2 /Open Document Format (ODF) 3 /Office Open XML (OOXML) 4 /Portable Document Format (PDF) als Dokumentenformate

14 2. Anwendungsfelder von Transformationssprachen Message Oriented Middleware Unter Message Oriented Middleware fallen Programme, die Daten zum Zwecke des Datenaustauschs zwischen Systemen transformieren. Obwohl in vielen Systemen die Extensible Markup Language (XML) als Import-/Exportformat vorhanden ist, müssen die zu importierenden/exportierenden Daten noch in das gleiche Format gebracht werden. Hierfür bietet sich eine Transformation mit der Extensible Stylesheet Language Transformations (XSLT) an, um die Daten in das gewünschte XML-Format zu bringen. Alternativen zu XSLT wären die Document Style Semantics and Specification Language (DSSSL), die Transformation über einen zielgesteuerten XML-Prozessor wie MetaMorphosis 5 oder die Programmierung eines entsprechenden Transformationsalgorithmus in einer beliebigen XML-verarbeitenden Programmiersprache. 2.2 Methoden der Transformation Es gibt verschiedene Methoden zur Transformation von XML-Dokumenten. So kann eine speziell dafür ausgelegte Transformationssprache wie XSLT (für XML-Dokumente) oder DSSSL (für beliebige SGML-Dokumente) benutzt werden, oder die Transformation direkt über einen zielgesteuerten XML- Prozessor wie MetaMorphosis realisiert werden. Eine andere Methode wäre die Entwicklung von eigenen, proprietären, Transformationsalgorithmen in einer beliebigen Programmiersprache DSSSL Die Document Style Semantics and Specification Language 6 ist eine Transformationssprache für Standard Generalized Markup Language (SGML)-Dokumente. Da XML ein Subset von SGML ist, kann DSSSL auch auf XML- Dokumente angewendet werden. DSSSL besteht aus einer Transformationssprache, die SGML-Dokumente basierend auf ihrer Dokumenttypdefinition in ein anderes Format bringt, sodass sie der DTD des gewünschten Ausgabeformats entsprechen und einer Stilsprache, die die Darstellung von Dokumenten festlegt. Da die Funktion von DSSSL und der Extensible Stylesheet Language (XSL) (respektive ihrer Teilsprachen XSLT und XSL FO) sehr ähnlich ist und Konzepte aus DSSSL unverändert übernommen wurden, können die Verarbeitungsprozesse der beiden Transformationssprachen gut miteinander verglichen werden. In der nachfolgenden Grafik (Abb. 2.1) wird der Verarbeitungsprozess von XSLT/XSL FO dargestellt, wobei die grau unterlegten Bereiche vom DSSSL-Standard definiert werden [4, Abschnitt 9.2]

15 2. Anwendungsfelder von Transformationssprachen 6 Abbildung 2.1: Verarbeitungsprozess von DSSSL. [4, Abschnitt 9.2] Um beispielsweise den folgenden Satz Schreiben Sie an < >user@domain.com</ >. aus einem DocBook-Dokument per DSSSL in HTML zu transformieren, ergibt der folgende DSSSL-Code [13, Seite 16] 1 (element 2 ($code-seq$ 3 (make sequence 4 (literal "<") 5 (make element gi: "A" 6 attributes: 7 (list (list "HREF" 8 (string-append "mailto:" 9 (data (current-node))))) 10 (process-children)) 11 (literal ">")))) das folgende Ergebnis Schreiben Sie an <tt>< <a href="mailto:user@domain.com">user@domain.com</a> ></tt> XSLT Die Extensible Stylesheet Language Transformations wurde anders als DSS- SL speziell für die Transformation von XML-Dokumenten entwickelt. Zusammen mit der XML Path Language (XPath), für die Adressierung der

16 2. Anwendungsfelder von Transformationssprachen 7 einzelnen Knoten eines XML-Dokuments, definiert sie Regeln für die Transformation in ein anderes Ausgabeformat oder einen anderen XML-Dialekt und stellt Funktionen für die Manipulation der XML-Daten bereit. XSLT hat sich zum Teil direkt aus DSSSL entwickelt und obwohl beide Sprachen von der Funktionsweise sehr ähnlich sind und DSSSL, aufgrund ihrer möglichen Anwendung auf beliebige SGML-Dokumente, einen größeren Funktionsbereich abdeckt, bietet XSLT speziell auf XML-Dokumente und deren Eigenschaften ausgelegte Funktionen an und eignet sich daher besonders für die Transformation von XML-Daten. Da XSLT selbst auf der XML-Syntax beruht ist es theoretisch möglich, erstellte XSLT-Templates wiederum durch eine XSL-Transformation zu verändern, XSLT also durch sich selbst zu transformieren eine Anwendung die in DSSSL beispielsweise nicht möglich ist. Um die in Abschnitt beschriebene Transformation in XSLT durchzuführen, würde folgendes XSLT-Template benötigt werden [13, Seite 16]: 1 <xsl:template match=" "> 2 <xsl:call-template name="inline.monoseq"> 3 <xsl:with-param name="content"> 4 <xsl:text><</xsl:text> 5 <a> 6 <xsl:attribute name="href">mailto:<xsl:value-of select="."/></xsl :attribute> 7 <xsl:apply-templates/> 8 </a> 9 <xsl:text>></xsl:text> 10 </xsl:with-param> 11 </xsl:call-template> 12 </xsl:template> Das Ergebnis der Transformation entspricht dem der DSSSL-Transformation MetaMorphosis MetaMorphosis 7 ist ein zielgesteuerter XML-Prozessor, der eine Transformation von XML-Dokumenten direkt in ihrer Baumstruktur ermöglicht. Dabei werden über ein Application Programming Interface (API) in C++, C# oder Java Regeln für die Konstruktion des Ausgabedokuments erstellt, die eigentliche Verarbeitung des Eingangsdokuments übernimmt dann der Prozessor selbst Proprietäre Algorithmen Grundsätzlich ist es möglich, gänzlich auf bestehende Transformationssprachen zu verzichten und die gesamte Transformation in einer beliebigen Programmiersprache selbst auszuprogrammieren. Diese Vorgehensweise hat zwar 7

17 2. Anwendungsfelder von Transformationssprachen 8 den Vorteil, dass die Transformation sehr spezifisch programmiert und genau an die Eingangsdokumente und das gewünschte Ausgabeformat angepasst werden kann, sowie auch alle Möglichkeiten einer Transformation zur Verfügung stehen solange die entsprechenden Funktionen von der Programmiersprache selbst angeboten werden jedoch überwiegen in vielen Fällen die Nachteile. Erstens wird die Erstellung der XSLT-Templates (beinhalten die XSL- Transformationsregeln) oftmals mit geringerem Aufwand möglich sein als die komplette (Neu-)Entwicklung eines Transformationsalgorithmus. Zweitens können XSL-Transformationen wohlgeformte (Abschnitt 3.1.1) und valide (Abschnitt 3.1.2) Dokumente garantieren (die meisten XSLT- Prozessoren validieren das Eingangsdokument mit dessen Dokumenttypdefinition (DTD) - falls angegeben). Drittens ist natürlich zu bedenken, dass hinter bestehenden Transformationssprachen wie DSSSL oder vor allem XSLT viele Jahre der Entwicklung stehen und auch die zur Transformation benötigten (Applikations-) Prozessoren (z. B. XSLT-Prozessor) für Transformationen optimiert wurden, wodurch man davon ausgehen kann, bei der Performanz mit der Eigenentwicklung im Vergleich zu einer XSL-Transformation schwer mithalten zu können. Ein einfaches Beispiel wäre die Transformation der folgenden XML-Daten 1 <members> 2 <person>max Mustermann</person> 3 <person>daniela Tester</person> 4 <person>david Beispielg</person> 5 </members> in folgende unordered list 8 im XHTML-Format: 1 <ul> 2 <li>max Mustermann</li> 3 <li>daniela Tester</li> 4 <li>david Beispielg</li> 5 </ul> Der für diese Transformation notwendige Algorithmus könnte in PHP Hypertext Preprocessor (PHP) beispielsweise wie folgt aussehen: 1 function convertmemberstounorderedlist($inputdata){ 2 $inputdata = eregi_replace('<members>', '<ul>', $inputdata); 3 $inputdata = eregi_replace('</members>', '</ul>', $inputdata); 4 $inputdata = eregi_replace('<person>', '<li>', $inputdata); 5 $inputdata = eregi_replace('</person>', '</li>', $inputdata); 6 return $inputdata; 7 } Folgende zwei XSLT-Templates würde diese Transformation ebenfalls durchführen: 8

18 2. Anwendungsfelder von Transformationssprachen 9 1 <xsl:template match="members"> 2 <ul><xsl:apply-templates /></ul> 3 </xsl:template> 4 5 <xsl:template match="person"> 6 <li><xsl:value-of select="." /></li> 7 </xsl:template> Man kann leicht erkennen, dass die XSL-Transformation nicht aufwändiger als der proprietäre Algorithmus in PHP und trotzdem sehr einfach zu lesen ist. Ein großer Vorteil der XSLT-Variante ist, dass ein und dieselben Templates in allen Programmiersprachen, für die es XSLT-Prozessoren gibt (Java, C, C++, Perl, PHP,...), verwendet werden können, wohingegen der PHP-Algorithmus eben nur in PHP funktioniert Fazit Bei Betrachtung der besprochenen Methoden zur Transformation von XML- Dokumenten bieten sich zuallererst die Transformationssprachen XSLT und DSSSL an, die folgende Vorteile bieten: offene, gut dokumentierte Standards umfangreiche Funktionen zur Datenmanipulation ausgereifte Technologien, die vielfach eingesetzt werden Bei der Transformation von XML-Daten ist XSLT der Alternative DSSSL vorzuziehen, da sie erstens speziell für diesen Zweck entwickelt wurde, zweitens selbst auf der XML-Syntax basiert und somit in allen XML-Editoren bearbeitet werden kann und es drittens eine Vielzahl ausgereifter XSLT- Prozessoren für den Einsatz in diversen Programmiersprachen (C, C++, Java, PHP,...) gibt. Die alternative Transformationmethode über den zielgesteuerten XML- Prozessor MetaMorphosis hat, gegenüber XSLT, die Nachteile, dass ihr Funktionsumfang und die möglichen Ausgabeformate beschränkt sind, ihr Software Development Kit (SDK) kostenpflichtig ist und sie nur in C++,.NET und Java eingesetzt werden kann. Die Entwicklung eigener, proprietärer, Transformationsalgorithmen kann in einem sehr eingeschränkten Anwendungsbereich, wenn die Syntax der Quell- und Ergebnisdokumente fest definiert ist und im Laufe der Zeit auch nicht erweitert wird, oder wenn die Daten in einer sehr speziellen Form transformiert werden müssen (z. B. abhängig von nicht im Quelldokument definierten Faktoren oder einem eigenen Algorithmus folgend) durchaus eingesetzt werden. Ein anderer Einsatzbereich selbst entwickelter Transformationsalgorithmen ist dann, wenn für die verwendeten Programmiersprache kein XSLT-Prozessor verfügbar ist.

19 2. Anwendungsfelder von Transformationssprachen 10 Generell lässt sich aber sagen, dass für eine Vielzahl der möglichen Transformationen von XML-Dokumenten XSLT die beste Wahl darstellt. 2.3 Ausgewählte Publishing-Formate und ihre Besonderheiten Die Vielzahl der möglichen Publishing-Formate kann man in zwei große Bereiche teilen: die nicht formatgebundenen wie XHTML oder WML, die fast ausschließlich über elektronische Geräte betrachtet werden, und die formatgebundenen wie PDF oder ODF, die sowohl zur Datenspeicherung als auch zum Dokumentdruck verwendet werden. All diese Publishing-Formate haben Besonderheiten, auf die bei einer Transformation geachtet werden muss, einerseits, um überhaupt syntaktisch korrekte Ausgabedokumente zu generieren, andererseits, um sich, durch geschickte Definierung der Transformationsregeln, viel Arbeit zu ersparen XHTML Obwohl selbstverständlich auch Transformationen in andere HTML-Versionen (z. B. HTML 4.01) möglich wären, bietet sich XHTML an, da XHTML 1.0-fähige Webbrowser mittlerweile einen ausreichend hohen Verbreitungsgrad haben [23] 9, eine durchwegs gleichmäßige Darstellung mittels Cascading Style Sheets (CSS) in aktuellen Browsern gewährleistet werden kann und XHTML im Gegensatz zu HTML 4.01 erweiterbar ist. Wie die die Transformationsbeispiele in Abschnitt 2.2.1, Abschnitt sowie in Abschnitt gezeigt haben, ist eine Transformation nach XHTML grundsätzlich recht leicht zu bewerkstelligen, da man meist ein Element des Ausgangsdokuments genau einem Element des XHTML-Markups zuweisen kann, wofür sehr einfache und kurze XSLT-Templates ausreichen. Komplizierter wird die Transformation dann, wenn man neben dem reinen Markup auch Stilinformationen (Schrift, Textgröße, Farbe, Ausrichtung) transformieren möchte (z. B. bei Transformation von ODF nach XHTML). Da XHTML selbst nur eine Auszeichnungssprache ist, in der keine Stilinformationen gespeichert werden, greift man an dieser Stelle auf CSS zurück. CSS kann entweder direkt im XHTML-Dokument oder in externen CSS-Dateien gespeichert werden. Wichtiger als der Speicherort ist jedoch die Art der Zuweisung der CSS-Eigenschaften. Diese können entweder Elementen direkt im XHTML-Dokument über das style-attribut zugewiesen oder extern definiert und über das class-attribut an Elemente geknüpft werden (die Zuweisung über den Elementnamen oder das id-attribut ist hier nicht zielführend, da sie für eine automatische Zuweisung schlecht geeignet ist) [24, Kapitel 14]. 9 nur begrenzt repräsentativ

20 2. Anwendungsfelder von Transformationssprachen 11 Welche Art der Zuweisung benutzt wird, hängt sehr stark vom Eingangsdokument ab. Am Beispiel von ODF würde sich die Definition von CSS-Klassen und Zuweisung über das class-attribut empfehlen, da in ODF selbst einzelne Stilklassen (als Element style:style) definiert und z. B. über das Attribut text:style-name einzelnen Wörtern/Blöcken zugewiesen werden [6, Abschnitte und ]. Hierbei müssten nur die jeweiligen ODF-Stileigenschaften in ihre CSS-Äquivalente übersetzt, als CSS-Klassen definiert und über class- Attribute zugewiesen werden. Weitere Informationen zu ODF sind in Abschnitt zu finden XSL-FO als Möglichkeit zur Druckausgabe XSL FO ist eine Seitenbeschreibungssprache, in ihrer Funktionsweise ähnlich PostScript (PS). Mit ihr wird das Erscheinungsbild am Druckmedium festgelegt (Seitenformat, Größe, Schrift, Positionierung,...) und aus dem daraus resultierenden XSL-FO-Baum kann im nächsten Schritt von einem FO- Prozessor (z. B. Apache FOP 10, Antenna House Formatter 11 ) das gewünschte Zielformat (z. B. PDF, Rich Text Format (RTF), PS, Printer Command Language (PCL)) erzeugt werden [5, Kapitel 3-7]. Bei der Transformation nach XSL FO hängt vieles vom Format des Eingangsdokuments ab. Während bei einer Transformation von XML nach XSL- FO beinah die gesamte Transformation definiert werden muss, da noch keine Stilinformationen definiert sind, kann eine Transformation von XHTML aus fast ohne Vorbereitungen durchgeführt werden. Das liegt daran, dass XHTML einen (bekannten) definierten Sprachraum besitzt und die zur Definition der Darstellung verwendeten CSS-Eigenschaften fast durchgängig entsprechende XSL-FO-Äquivalente haben. Darum gibt es auch bereits sehr weit entwickelte XSLT-Templates für die Transformation von XHTML (mit CSS) nach XSL-FO. So unterstützt das freie Programm CSSToXSLFO 12 von Werner Donne XHTML 1.0 sowie XHTML 1.1, 99% der CSS1-Eigenschaften sowie bereits 95% aller CSS2-Eigenschaften und erzielt ausgezeichnete Ergebnisse bei der Transformation eines XHTML-Dokumentes (inklusive CSS) in einen XSL-FO-Baum, der über einen Formatting Objects Processor in ein PDF gerendert werden kann. Nach der Transformation in XSL-FO stehen verschiedenste Zielformate über XSL-FO-Prozessoren zur Verfügung

21 2. Anwendungsfelder von Transformationssprachen 12 ODF Das Open Document Format ist ein offener Dokumentenstandard, der von den wichtigsten freien Textverarbeitungsprogrammen (OpenOffice, StarOffice, KOffice,...) unterstützt oder sogar als Standarddateiformat verwendet wird. Der Markführer Microsoft wird ODF mit dem Service Pack 2 in Office 2007 unterstützen 13. Dokumente im Open Document Format sind meist Zip-Archive verschiedener XML-Dateien sowie Bilder und können deshalb nicht direkt durch eine XSL-Transformation erstellt werden, wohl aber die einzelnen XML-Dateien des Archivs. Auch wenn mir bisher keine Applikation bekannt ist, die XHTML-Dokumente direkt in ODF transformieren kann, sollte diese Wandlung genauso problemlos durchzuführen sein wie z. B. eine Transformation von XHTML in das DocBook-Format, für das es bestehende XSLT-Templates gibt (beispielsweise werden alle Dokumentationen von TYPO3 14 -Erweiterungen automatisch von XHTML in das DocBook-Format gewandelt). Es gibt jedoch Applikationen zur Konvertierung von Dokumenten im DocBook-Format nach ODF, z. B. docbook2odf 15, das die Konvertierung ebenfalls über eine XSL- Transformation löst. PDF PDF hat sich mittlerweile als Quasi-Standard für die Publizierung von Inhalten (in einem gesetzten Format) im World Wide Web und zum Datenaustausch in der Druckvorstufe (als PDF/X 16 ) erhoben und nimmt somit eine enorm wichtige Position unter den möglichen Ausgabeformaten einer Formattransformation ein. Interessant ist vor allem die direkte Transformation von XML-Daten eines Systems in ein PDF. Für fest definierte, XML-basierte Sprachen wie XHTML bestehen bereits sehr weit entwickelte Applikationen für eine Transformation in ein PDF-Dokument (siehe Abschnitt 2.3.2). Man kann aber auch ohne Umwege (z. B. über XHTML) direkt einen XSL-FO-Baum und folgend ein PDF aus XML-Daten generieren, als Beispiel sei die Spezifikation des Katalogdatenaustauschformats BMEcat genannt, deren Dokumentation auf diesem Wege direkt aus der Spezifikation des Standards erzeugt wurde [26, Kapitel 4] ExpandedFormatsPR.mspx 14 Ein Content Management System definiert in ISO und ISO

22 2. Anwendungsfelder von Transformationssprachen 13 RTF Da das Rich Text Format speziell zum Datenaustausch zwischen Textverarbeitungsprogrammen entwickelt wurde und eine offene Spezifikation besitzt 18 bieten viele FO-Prozessoren RTF als Ausgabeformat an. Ein Vorteil von RTF im Vergleich zu PDF ist dass es nachträglich noch mit einem beliebigen Texteditor komplett geändert werden kann was es andererseits als Format zum Vertrieb an Endkunden (z. B. als E-Book) uninteressant macht, weil es kein Digital Rights Management (DRM) ermöglicht SVG Der Standard Scalable Vector Graphics basiert ebenfalls auf XML und dient der Beschreibung von Vektorgrafiken. Deshalb bietet sich eine Transformation von XML-Daten über XSLT in SVG besonders an, da dadurch Vektorgrafiken erstellt werden können, die sowohl direkt in aktuellen Webbrowsern gerendert (Firefox, Safari, Opera unterstützen SVG jeweils nativ, Internet Explorer bis Version 7 nur mit Adobe SVG-Viewer-Plugin 19 ) als auch in ein PDF eingebunden werden können [29, Seite 2]. Eine XSL-Transformation von XML-Daten in SVG macht besonders bei allen Arten von Statistiken Sinn, die, grafisch aufbereitet, in Form von Diagrammen und Graphen präsentiert werden. Gerade in diesem Anwendungsfeld ist es möglich, XSLT-Templates so allgemein zu gestalten, dass damit, ohne größeres Eingreifen, eine Vielzahl von Daten in SVG-Diagramme gewandelt werden können [22, Kap. 2]. Der folgende Code (XML-Deklaration und Doctype entfernt) erzeugt beispielsweise ein Kreisdiagramm in SVG (Abb. 2.2). 1 <svg xmlns=" xmlns:xlink=" /1999/xlink" xml:space="preserve" width="400" height="400"> 2 <rect x="0" y="0" width="400" height="400" fill="white"/> 3 <g style="fill-opacity: 1; stroke:black; stroke-width: 1"> 4 <path d="m200,200 L200,20 A180, ,1 377,231 z" style="fill:\# ff0000;" /> 5 <path d="m200,200 L377,231 A180, ,1 138,369 z" style="fill :\#00ff00;" /> 6 <path d="m200,200 L138,369 A180, ,1 20,194 z" style="fill :\#0000ff;" /> 7 <path d="m200,200 L20,194 A180, ,1 75,71 z" style="fill:\# ff00ff;" /> 8 <path d="m200,200 L75,71 A180, ,1 200,20 z" style="fill:\# ffff00;" /> 9 </g> 10 </svg> Der 5. Pfad definiert beispielsweise das gelbe Diagrammstück und ist wie folgt definiert:

23 2. Anwendungsfelder von Transformationssprachen 14 Abbildung 2.2: SVG-Diagramm. <path d="m200,200 L75,71 A180, ,1 200,20 z" style="fill:#ffff00; "/> der Verlauf eines Pfades wird mit dem Attribut d bestimmt: M200,200 stellt die aktuelle Zeichenposition ein L75,71 zeichnet eine Linie zum angegebenen Endpunkt A180, ,1 200,20 zeichnet eine Bogenkurve zum angegebenen Koordinatenpunkt z schließt den Pfad style="fill:#ffff00;" füllt den Pfad mit Gelb Obwohl das angegebene Beispiel aufgrund der Bogenkurve bereits recht komplex ist, kann es dennoch gut über eine XSL-Transformation generiert werden. Balkendiagramme beispielsweise sind noch wesentlich einfacher zu erstellen Fazit Man hat mit Transformationssprachen die Möglichkeit XML-Daten in die verschiedensten Publishing-Formate zu bringen und gerade da es soviele unterschiedliche, mögliche Ausgabeformate gibt, ist es wichtig, über deren Syntax und Besonderheiten genau Bescheid zu wissen. So gibt es für diverse XML-Dialekte bereits existierende XSLT-Sheets für die Transformation in weit verbreitete Ausgabeformate (z. B. XHTML+CSS zu PDF, XHTML in DocBook, DocBook zu ODF) und es spricht nichts

24 2. Anwendungsfelder von Transformationssprachen 15 dagegen sich die Arbeit zu erleichtern, indem man z. B. einen XSLT-Sheet für die Transformation seiner XML-Daten in XHTML entwickelt und danach existierende XSLT-Sheets für die Transformation nach XSL FO (für eine spätere Formatierung als PDF) nutzt und sich so den ungleich aufwändigeren Weg der direkten Transformation nach XSL FO erspart. Eine andere Möglichkeit sich Arbeit zu ersparen ergibt sich dadurch, dass, wie in Abschnitt am Beispiel von CSS und ODF erwähnt, viele Sprachen, in Funktion und Definition, sehr ähnliche Formatierungseigenschaften besitzen, die direkt in ihr jeweiliges Äquivalent übersetzt werden können. 2.4 Ausgabeformate für Datentransfer Grundsätzlich ist XML das Format, an das man bei der Nutzung als Datentransferformat denkt. Mit den meisten, der in Abschnitt 2.2 besprochenen, Methoden zur Transformation ausgenommen des XML-Prozessors Meta- Morphosis ist allerdings die Transformation von XML-Daten in beliebige, textbasierte, Ausgabeformate möglich. Das heißt, es wäre möglich, XML- Daten auch direkt in einen SQL-Dump oder eine CSV-Datei zu transformieren XML Auch wenn XML als Import/Exportformat in vielen Systemen unterstützt wird, kann es nicht als direkt einsetzbares Austauschformat dienen, da die meisten Systeme ihre eigenen Spezifikationen besitzen. Deshalb wird es auch nie einen umfassenden Standard zum Datenaustausch auf XML-Basis geben, sondern eher eine Vielzahl einzelner Spezifikationen, die lediglich Teilbereiche umfassen (Formatstandards, Größen, Datentypen, Identifikationsstandards, Klassifikationsstandards) [28, Seiten 2-3]. Ein Beispiel eines sehr weit entwickelten Formatstandards ist BMEcat 20, ein Austauschformat für Katalogdaten, das vor allem im deutschsprachigen Raum verbreitet ist [25, Seite 3]. Selbst in diesem Teilbereich gibt es jedoch verschiedene konkurrierende Systeme (xcbl, ebxml, ONIX,...), die nicht direkt zueinander kompatibel sind und für die entsprechende Konverter entwickelt werden müssen. Hier bietet sich natürlich die Transformation über XSLT an. Sehr häufig wird das Problem jedoch schon darin bestehen, dass für ein System überhaupt kein XML-Standard als Ausgabeformat definiert wurde bzw. einige Elemente einfach nicht mit dem Importstandard übereinstimmen. In diesem Fall könnte man entweder das Ausgabeformat umprogrammieren, ein zusätzliches Ausgabeformat entwickeln oder das bestehende Ausgabeformat (z. B. über XSLT) transformieren. 20

25 2. Anwendungsfelder von Transformationssprachen CSV Auch wenn Comma-Separated Values (CSV) als Datenaustauschformat für tabellarische Daten weit verbreitet sind, können CSV-Dateien nur für sehr einfach strukturierte Daten verwendet werden. Grundsätzlich ist es aber problemlos möglich, XML-Daten (sofern sie tabellarisch dargestellt werden können und keine Schachtelung in mehrere Ebenen besteht) in CSV zu transformieren. Für den Austausch komplexere Strukturen ist aber ein XMLbasiertes Format besser geeignet und kann auch später wieder in ein anderes Format konvertiert werden, was bei CSV (über XSLT) nicht möglich ist.

26 Kapitel 3 XML Die Extensible Markup Language ist ein Standard des World Wide Web Consortium (W3C) zur Auszeichnung hierarchisch strukturierter Daten. Besonderes Augenmerk wurde darauf gelegt, dass die Auszeichnungssprache maschinenlesbar, aber trotzdem human readable ist, also vom Menschen gelesen und verstanden werden kann. XML selbst ging aus SGML hervor, ist aber gleichzeitig die Basis für viele andere formale Sprachen aus den verschiedensten Bereichen wie XHTML (WWW), ODF (Dokumentenformat), SVG (Vektorgraphik), MPEG-7 1 (Beschreibung von Multimediainhalten),... Grundsätzlich ist es möglich, mit einer Transformationssprache wie XSLT Daten, die in in einem XML-basierenden Format definiert sind, in ein beliebiges anderes (XML-basierendes) Format zu transformieren, sofern dies zum Einen Sinn macht und zum Anderen ein paar Voraussetzungen (Stichwort: Wohlgeformtheit) gegeben sind. 3.1 Grundlagen Wohlgeformtheit Damit ein XML-Dokument transformiert werden kann, muss es wohlgeformt sein damit es XML-Parser sowie XSLT-Prozessoren verarbeiten können. Dazu müssen folgende Vorraussetzungen erfüllt werden [27, Abschnitte 1.2 und 1.3]: In der ersten Zeile des Dokuments befindet sich die XML-Deklaration. Das Dokument muss genau ein Wurzelelement besitzen. Jedes Element muss ein Start- und ein End-Tag besitzen (ausgenommen sind leere Elemente, diese können in sich geschlossen sein). 1 definiert in ISO

27 3. XML 18 Start- und Endtag müssen sich in der gleichen Ebene befinden. Ein Element darf nur Attribute mit unterschiedlichen Namen besitzen. Verwendete ID-Attribute dürfen nur einmal im gesamten XML-Dokument vorkommen Gültigkeit Es ist sinnvoll, wenngleich nicht unbedingt erforderlich, XML-Dokumenten eine DTD oder ein XML-Schema zu Grunde zu legen, um ihre Gültigkeit zu überprüfen. Dadurch kann garantiert werden, dass ein Dokument nur zuvor (in der DTD) definierte Elemente und Attribute enthält und somit erstellte Transformationsregeln (z. B. in Form von XSLT-Templates) das gesamte Dokument abarbeiten können. Dokumenttypdefinition Die Dokumenttypdefinition gibt die Regeln für das XML-Dokument vor. Sie definiert welche Elemente und Attribute erlaubt, an welcher Stelle und in welcher Kombination sie gültig sind [16, Abschnitt 3.1]. Ein praktisches Beispiel für den Nutzen einer gültigen DTD findet sich in aktuellen Webbrowsern. Wird bei einem HTML- oder XHTML-Dokument kein Verweis (über den Doctype) auf die entsprechende DTD des Dokuments gesetzt, stellen die Browser die Webseite im so genannten Quirks-Mode dar und entsprechen dabei nicht der vom W3C vorgegebenen Darstellung (speziell beim CSS-Rendering). Eine DTD wird wie folgt zugewiesen (Anweisung muss vor dem Wurzelelement stehen): <!DOCTYPE Wurzelelement SYSTEM "datei.dtd" [... ]> XML-Schema Mit einem XML-Schema kann ein XML-Dokument ähnlich einer DTD beschrieben werden. Sie wird jedoch entgegen der Dokumenttypdefinition selbst in XML geschrieben. Vorteile eines XML-Schemas gegenüber einer DTD sind die volle Unterstützung der Namensräume und vor allem die vordefinierten Datentypen. So kann man bei Verwendung eines XML-Schemas bereits auf etwa 20 vordefinierte Datentypen wie xsd:string, xsd:integer, xsd:float zurückgreifen (und auch selbst neue definieren), während man bei DTDs auf den Datentyp string beschränkt ist [27, Abschnitt 8.2]. Die Zuweisung eines XML-Schemas sieht wie folgt aus: <?xml version="1.0"?>

28 3. XML 19 <Root-Element xmlns:xsi=" xsi:schemalocation="[url_xml-schema]"> 3.2 XML-Knoten Ein XML-Dokument besteht aus einer Vielzahl von ineinander geschachtelten Elementen und Attributen die character data enthalten Elemente XML-Elemente bestehen aus einem Start- und einem Endtag in folgender Form: <ElementName></ElementName> Innerhalb des Start- und Endtags können nun entweder weitere Elemente, Textdaten (sogenannte character data) oder eine Kombination von beiden stehen. Aus der Vielzahl geschachtelter Elemente und Textdaten entsteht die logische Baumstruktur des XML-Dokuments Attribute Attribute werden verwendet, um Zusatzinformation zu einzelnen Elementen zu speichern (z. B. eindeutige ID, Verknüpfung mit anderem Element, Stilinformationen,...). Attribute in XML-Dokumenten werden als Name-Wert-Paar in folgender Syntax notiert: <ElementName AttributName="[Wert]"></ElementName> Datentypen Grundsätzlich hat man in XML nur einen Datentyp zur Verfügung, alle Inhalte sind automatisch vom Typ string (Text). Doch können Elemente und Attribute von unterschiedlichem Typ sein. So können Elemente entweder vom Typ Element Content sein, was bedeutet dass sie ausschließlich (in der DTD definierte) Kindelemente besitzen dürfen, oder vom Typ Mixed Content bei dem ihr Inhalt auch PCDATA sein kann [8, Abschnitt 3.2]. Für Attribute gibt es sogar 10 mögliche Typen, angefangen bei einem Texttyp (CDATA) über Tokenized Types (ID, IDREF, IDREFS, ENTITY, ENTITIES, NMTOKEN, NMTOKENS) bis hin zu vordefinierten Werten [8, Abschnitt 3.3].

29 3. XML 20 Trotz der möglichen Typen für Elemente und Attribute kann kein spezifischer Datentyp, wie er aus Programmiersprachen bekannt ist, beispielsweise Char, Integer oder Float festgelegt werden PCDATA Der Typ Parsed Character Data (PCDATA) erlaubt als Inhalt von Elementen beliebigen Text, ausgenommen reservierter Zeichen. Reservierte Zeichen in XML sind beispielsweise die spitzen Klammern (<>), Anführungszeichen ( ) oder das kaufmännische Und (&). Diese werden für das den Text umschließende Markup benutzt und müssen im Text durch sogenannte Entity-Referenzen (z. B. " für ein Anführungszeichen) ersetzt werden CDATA Der Typ Character Data (CDATA) erlaubt als Wert von Attributen beliebigen Text, ausgenommen reservierter Zeichen CDATA-Abschnitt Aufgrund des Fehlens von Datentypen in XML kann (und wird) es passieren, dass in Textdaten (für XML-Markup) reservierte Zeichen vorkommen die durch Entity-Referenzen ersetzt werden müssen, was bei einer großen Datenmenge jedoch unnötig aufwändig ist. Für diesen Fall gibt es den CDATA-Abschnitt [8, Abschnitt 2.7], der den Textinhalt umschließt, wodurch der XML-Parser diesen nicht weiter interpretiert. Der CDATA-Abschnitt ist jedoch nicht zu verwechseln mit den Ausdrücken CDATA und PCDATA (vgl. Abschnitt 3.2.3) mit denen er - abgesehen vom Namen - nichts gemein hat. CDATA-Abschnitte dürfen nämlich sehr wohl Markup (und somit reservierte Zeichen) enthalten - ganz im Gegensatz zu den CDATA oder PCDATA-Typen. Bei der Verwendung eines XML-Schemas anstatt einer DTD (vgl. Abschnitt 3.1.2) sind jedoch auch weitere Datentypen verfügbar (und neue können definiert werden), wodurch beim Datenaustausch zwischen mehreren Systemen der Datentyp erhalten werden kann. 3.3 XML-Verarbeitung Es gibt mehrere, grundsätzliche verschiedene, Ansätze XML-Dokumente abzuarbeiten. Die 3 wichtigsten Modelle sind die Ereignisgesteuerte Verarbeitung (Event-Driven Processing), die Baumbasierende Verarbeitung (Treebased Processing) sowie das Pull-based Processing [16, Abschnitt 18.1].

30 3. XML 21 Die unterschiedlichen Verarbeitungsmodelle unterscheiden sich im Zugriff auf die Elemente des XML-Dokuments (sequentiell oder beliebig) und im Ablauf der Verarbeitung (Pull oder Push) Ereignisgesteuerte Verabeitung Ereignisgesteuerte Methoden des XML-Parsings arbeiten ein XML-Dokument sequentiell ab und werfen dabei vordefinierte Ereignisse (sogenannte Parsing Events) an den XML-Parser wie das Vorkommen eines Starttags/Endtags oder den Beginn des Einlesens eines Elementinhalts. Für die einzelnen Ereignisse kann es nun vordefinierte Callback-Funktionen geben die darauf entsprechend reagieren und somit die Verarbeitungslogik darstellen. Vorteile einer ereignisgesteuerten Verarbeitung sind die hohe Geschwindigkeit und die geringe Speicherauslastung, da nur der für das aktuelle Ereignis relevante Dokumentteil im Speicher landet. Außerdem kann mit der weiteren Verarbeitung des Dokuments bereits begonnen werden, wenn die ersten Zeilen eingelesen und somit die ersten Ereignisse geworfen werden. Der große Nachteil ist, dass Applikationen wesentlich komplexer als bei Verwendung einer baumbasierten Verarbeitung werden, da nicht zu jedem Zeitpunkt auf alle Knoten des Dokuments zugegriffen werden kann und die gesamte Programmlogik auf die Behandlung der auftretenden Ereignisse ausgelegt werden muss. Die am häufigsten benutzte, ereignisbasierte API ist die Simple API for XML (SAX) Baumbasierende Verabeitung Baumbasierende APIs generieren aus dem eingelesenen XML-Dokument eine Baumstruktur, in der alle Knoten des Dokuments vorhanden sind. Dies erlaubt der Applikation zu jeder Zeit auf jeden Knoten des XML-Dokuments zuzugreifen sowie die Baumstruktur zu manipulieren und wieder in das Dokument zurückzuschreiben. Nachteilig ist die hohe Speicherauslastung (zumindest so groß wie das Dokument selbst, meist sogar ein Vielfaches der Dokumentgröße [16, Abschnitt ]) und dass das Dokument zuerst vollständig eingelesen werden muss, bevor es verarbeitet werden kann. Die am häufigsten benutze, baumbasierende API ist das Document Object Model (DOM) XML-Pull Verabeitung Die XML-Pull-Methode arbeitet ebenfalls ereignisgesteuert mit dem Unterschied, dass nicht das gesamte Dokument sequentiell abgearbeitet wird, sondern die Client-Applikation definierte Bereiche vom Parser anfordert.

31 Kapitel 4 XSLT XSLT ist neben der XML Path Language (XPath) und XSL FO ein Teil von XSL und bietet die Möglichkeit XML-Dokumente in beliebige andere, textbasierte Dokumente zu transformieren. In den meisten Fällen sind die Ergebnisdokumente ebenfalls in einem XML-Dialekt geschrieben (z. B. XHTML, XSL FO, ODF - s. Abschnitt 2.3), dies ist aber nicht zwingend erforderlich. Um XSLT nun zur Transformation von XML-Daten in Applikationen einzusetzen, müssen gewisse Voraussetzungen gegeben sein. In diesem Kapitel werden diese Voraussetzungen beschrieben, die grundlegenden Elemente und Attribute, die für eine XSL-Transformation (und somit für die Entwicklung eines Algorithmus zur automatischen Erstellung der XSLT-Template- Regeln) notwendig sind, besprochen, sowie wichtige Problembereiche wie die Conflict Resolution (Abschnitt 4.2.5), die für eine automatische Template- Generierung unbedingt bedacht werden müssen, dargestellt. Weiters werden mögliche, in dem zu realisierenden XSL-Editor einsetzbare, XSL-Prozessoren auf ihre Eignung untersucht und notwendige Grundlagen von XPath, anhand von Beispielen, erarbeitet. 4.1 Grundlagen Für eine XSL-Transformation werden (zumindest) 3 Dokumente benötigt [27, Abschnitt 7.1]: Ein wohlgeformtes XML-Dokument als Quelldokument. Das eigentliche XSLT-Dokument, den XSLT-Sheet, der zumeist eine Sammlung von XSLT-Templates beinhaltet und die Regeln für die Transformation definiert. Das Ergebnisdokument das durch den XSL-Transformationsprozess erstellt wird. 22

32 4. XSLT Aufbau eines XSLT-Sheets Der XSLT-Sheet ist ebenfalls ein wohlgeformtes XML-Dokument, der aus vielen kurzen XSLT-Templates (siehe Abschnitt 4.2.1), die innerhalb des Root-Elements <xsl:stylesheet> stehen, wie folgt aufgebaut ist: <?xml version ="1.0" encoding ="ISO "?> <xsl:stylesheet version ="1.0" xmlns:xsl =" </xsl:stylesheet> Innerhalb des stylesheet-elements stehen die so genannten Top-Level- Elemente [10, Abschnitt 2.2], die grundlegende Einstellungen definieren (z. B. <xsl:output> für Encoding des Ergebnisdokuments), bestehende XSLT-Stylesheets einbinden (<xsl:import> und <xsl:include>), Transformationsregeln zusammenfassen (<xsl:template> - siehe Abschnitt 4.2.1) oder Variablen, Parameter und Attribute für die Transformationen deklarieren (<xsl:variable>, <xsl:param> und <xsl:attribute-set>) Element xsl:template Mit Hilfe des xsl:template-elements kann man Regeln und Transformationen in mehrere kleine Abschnitte unterteilen, was sie zum Einen übersichtlicher und zum Anderen wiederverwertbar macht. Wichtigstes Attribut des Elements ist match, über das ein Template die Knoten identifiziert, auf die es seine definierten Regeln anwendet. Der Wert des match-attributs ist ein sogenanntes Pattern (vgl. Abschnitt 4.4.2), ein XPath-Ausdruck, der Teile des XML-Baums (bestimmte Knoten) adressiert. Das folgende XSLT-Template 1 <xsl:template match="title"> 2 <h1 style="color: grey;"><xsl:value-of select="." /></h1> 3 </xsl:template> würde beispielsweise auf alle <title>-elemente des Quelldokuments angewendet werden und deren Textinhalt über das Element <xsl:value-of> (Abschnitt 4.2.3) in das Ergebnisdokument kopieren, es mit <h1>-tags umschließen und eine CSS-Farbzuweisung erstellen. Die Aufteilung der Transformationsregeln in einzelne XSLT-Templates macht bei der dynamischen Generierung durch einen Algorithmus besonders Sinn, da sofort nach dem Matching von Elementen/Attributen im Quelldokument zu ihren Entsprechungen im Ergebnisdokument, also des Auffindens einer möglichen Verbindung, ein entsprechendes Transformations-Template erstellt werden kann. Problematisch kann dies jedoch bei der Verwendung verschiedener Matching-Methoden werden, da es passieren kann, dass auf

33 4. XSLT 24 einen Knoten im Quelldokument plötzlich mehr als nur ein Transformations- Template zutrifft. An dieser Stelle tritt dann die Conflict Resolution (Abschnitt 4.2.5) in Aktion Element xsl:apply-templates Mit dem <xsl:apply-templates>-element [10, Abschnitt 5.4] kann die Verarbeitung von Kindknoten eines XML-Knotens, auf den ein definiertes XSLT- Template-Pattern zutrifft, gesteuert werden. Beim Setzen des Elements werden innerhalb des Templates andere, definierte Templates angewendet, wodurch z. B. zuvor bestimmte Strukturen (Listen, Tabellen,...) auf besondere Weise abgearbeitet werden können. Über das Attribut select des Elements kann die weitere Abarbeitung auf bestimmte Knoten eingeschränkt werden (verlangt XPath-Ausdruck). Wird dieses Attribut nicht gesetzt, so werden alle Kindnoten abgearbeitet. Eine weitere Anwendung des <xsl:apply-templates>-elements ist eine grundsätzliche Ordnung von Strukturen. So kann, bei Verwendung mehrerer <xsl:apply-templates>-elemente innerhalb eines <xsl:template>, darüber definiert werden, welche Knoten zuerst abgearbeitet werden (und somit im Ergebnisdokument auch zuerst aufscheinen). Im Hinblick auf die automatische Generierung von verschiedenen XSLT- Templates wird es zumeist nötig sein, innerhalb eines XSLT-Templates das <xsl:apply-templates>-element, ohne Angabe des select-attributs, zu setzen, um eine weitere Abarbeitung der Kindknoten des aktiven Knotens zu gewährleisten. Es wäre jedoch sinnvoll, angenommen die DTD des Quelldokuments wäre gesetzt und könnte verarbeitet werden, die weiterzuverarbeitenden Knoten über das select-attribut auf die in dem Element (durch eine entsprechende Angabe in der DTD) erlaubten Kindelemente einzuschränken. Problematisch wäre diese Einschränkung jedoch dann, wenn zuvor gematchte Elemente des Quell- und Ergebnisdokuments unterschiedliche (oder einfach nur unterschiedlich viele) Kindelemente erlauben würden, was unweigerlich zur Generierung von falschen XSLT-Templates führen würde Element xsl:value-of Mit dem Element <xsl:value-of> kann ein Wert des Quelldokuments an die aktuelle Stelle des Ergebnisdokuments eingefügt werden [10, Abschnitt 7.6.1]. Der einzufügende Wert wird über das Attribut select des Elements definiert (verlangt XPath-Ausdruck) Element xsl:output Das Element <xsl:output> [10, Kapitel 16] hat besondere Bedeutung bei der Erstellung von XSLT-Templates, da es die Art des Ergebnisdokuments festlegt.

34 4. XSLT 25 Über das Attribut method des Elements kann die grundsätzliche Ausgabemethode definiert werden. Wird für dieses Attribut kein Wert gesetzt, so wird vom XSLT-Prozessor ein Wert festgelegt, d.h. dieser versucht die richtige Einstellung, basierend auf dem auszugebenden Markup, zu finden. Findet dieser z. B. das Root-Element html im transformierten Markup, nimmt er an, dass es sich um ein HTML-Dokument handelt und setzt den Wert dementsprechend. Je nach Wert für das method-attribut werden für die übrigen Einstellungen Standardwerte gesetzt. So werden z. B. bei der Ausgabe als XML alle Inhalte von Textknoten mit CDATA-Bereichen umschlossen, XML-Deklaration, Doctype und Encoding werden gesetzt und das Ergebnis als wohlgeformtes XML ausgegeben. Bei der Einstellung als HTML werden beispielsweise gewisse, leere Elemente (wie br, hr, img, input) in sich geschlossen und kein Endtag dafür erstellt sowie Inhalte aus script-elementen, die Steuerzeichen enthalten, nicht ersetzt. Eine sehr wichtige Einstellung, abseits der durch das method-attribut festgelegten Standardwerte, wird über das Attribut encoding gesetzt. Über den eingestellten Wert kann der Zeichensatz des Ergebnisdokuments festgelegt werden, was im speziellen beim Datentransfer zwischen Systemen Bedeutung bekommt, da hierbei auch sehr häufig auch der Zeichensatz geändert werden muss Conflict Resolution Dadurch dass die XSL-Transformationsregeln in kleine (wiederverwertbare) Templates aufgeteilt werden, die über den XPath-Ausdruck des match- Attributs zugeordnete Strukturen (Abschnitt 4.2.1) identifizieren und darauf angewendet werden, kommt es durchaus vor, dass zwei oder mehr Templates auf einen Knoten des Quelldokuments zutreffen. Da nur ein Template mit Transformationsregeln auf einen einzelnen Knoten angewendet werden kann, muss der XSLT-Prozessor das am besten zutreffende Template identifizieren. Dafür gelten die folgenden Regeln [10, Abschnitt 5.5] sowie [27, Abschnitt 7.3]: Template-Regeln aus importierten XSLT-Sheets haben eine niedrigere Priorität. Überschneiden sich Regeln aus zwei importierten XSLT- Sheets, so hat der zuletzt importierte Sheet Vorrang. Wird dem Template über das Attribut priority eine Priorität gesetzt, so wird das Template mit dem höchsten Wert (reelle Zahl mit maximal 2 Kommastellen) für die Transformation genommen. Wird die Priorität nicht manuell gesetzt so gilt die generierte Standardpriorität, die sich wie folgt zusammensetzt:

35 4. XSLT 26 Wenn ein Templatepattern mehrere Zuweisungsalternativen besitzt (getrennt durch ), wird es wie ein Set von Templateregeln behandelt, eine für jede alternative Zuweisung. Hat das Pattern die Form eines Kind- oder Attributsspezifikationssymbols, gefolgt von einem Qualified Name (QName) [7, Kapitel 4] oder ist es eine Processing-Instruction für ein Kindelement oder einen Attributknoten, dann hat es die Priorität 0. Werden in dem Pattern der Templateregel Elemente oder Attribute außerhalb des Standard-Namensraum angesprochen (sprich Elemente/Attribute mit einem Namespace-Prefix) so bekommt es eine Priorität von Besteht das Pattern ausschließlich aus einem NodeTest [11, Abschnitt 2.3] auf ein Kindelement oder einen Attributknoten, dann hat es eine Standardpriorität von Trifft keine der zuvor genannten Bedingungen zu, so hat das Templatepattern die Priorität 0.5. Treffen trotzdem mehrere XSLT-Template auf einen Knoten zu dann wählt der XSLT-Prozessor selbst eine anzuwendende Regel (zumeist die zuletzt zutreffende) oder wirft einen Fehler (häufiger). Glücklicherweise gibt es für XSLT-Prozessoren vordefinierte Regeln zur Konfliktbehebung, die einen Großteil der mit Sicherheit auftretenden Konflikte lösen wird. Jedoch werden bei der automatischen Generierung von XSLT-Templates, insbesondere wenn verschiedene Matching-Methoden nacheinander verwendet werden, sehr wohl Templates mit gleicher Wertigkeit auftreten, die es in einem nachfolgenden Schritt auszusortieren gilt. Spätestens an dieser Stelle muss dem Benutzer unbedingt die Möglichkeit zum manuellen Eingreifen gegeben werden, da eine Lösung der, durch mehrfach zutreffende XSLT-Templates verursachten, Konflikte, allein durch eine Sicherheitsfunktion im Algorithmus nie vollständig garantiert werden kann. 4.3 XSLT-Prozessoren XSLT-Prozessoren führen die eigentliche Transformation von XML-Daten durch. Dabei wird in einem ersten Schritt das zu transformierende XML- Dokument eingelesen, daraus ein entsprechender XML-Baum aufgebaut, danach der XSLT-Sheet eingelesen und in einem letzten Schritt ein Zielbaum erstellt, der den Regeln des XSLT-Sheets entspricht.

36 4. XSLT Bewertung von XSLT-Prozessoren Es gibt eine Vielzahl verfügbarer XSLT-Prozessoren für C++ (MSXML, Sablotron 1, Xalan 2,...), Java (Saxon 3, Xalan-Java 4, XT 5 ) oder auch PHP (XSL-Funktionen 6 ), die jedoch unterschiedlich einfach einzubinden sind und vor allem große Unterschiede in ihrer Leistung aufzeigen. So hat der MSXML-Prozessor eine wesentlich höhere Leistung als z. B. XT, Saxon oder Sablotron, ist aber im Gegensatz zu den letztgenannten kostenpflichtig. In Zahlen ist der MSXML bei der Verarbeitung kleiner als auch großer XML-Dokumenten in etwa doppelt so schnell als der sehr langsame Sablotron-Prozessor oder der nur wenig schnellere XALAN in der Java- Implementierung [15, Kapitel 8]. Auch bei der Unterstützung des XSLT-Standards gibt es viele Unterschiede. So unterstützen MSXML und Saxon die XSLT 1.1-Spezifikation vollständig und teilweise auch bereits XSLT 2.0, wogegen die Xalan-Prozessoren aktuell noch immer nur XSLT 1.0 vollständig unterstützen Fazit Aufgrund der vorliegenden Leistungstests [15, Kapitel 8] und der Eignung der Einbindung bieten sich für eine Einbinung in Java die freien XSLT- Prozessoren jdxslt, Xalan und Saxon an, bei einer C++-Entwicklung wären xsltc oder Sablotron zu empfehlen. 4.4 XPath Die XML Path Language ist Teil der XSL-Familie und wurde entwickelt um einzelne Knoten eines XML-Dokuments adressieren zu können. Die manuelle Erstellung von XPath-Lokalisierungspfaden ist eine der größten Schwierigkeiten bei der Entwicklung von XSLT-Templates, da die Ausdrücke, sofern nicht lediglich Elemente/Attribute per Namen angesprochen werden, sehr kompliziert werden können. Darum ist die Generierung von XPath-Pfaden auch eines der häufigsten Features von XSL-Editoren (vgl. Abschnitt 4.5) und es gibt für verschiedene Entwicklungsumgebungen (im speziellen auch für Eclipse) Plug-ins, die, beispielsweise per Klick auf einen XML-Knoten in einer Baumansicht des Dokuments, die entsprechenden XPath-Lokalisierungspfade generieren

37 4. XSLT Knotentypen Es gibt im Datenmodell von XPath insgesamt 7 verschiedene Knotentypen [11, Kapitel 5], die da wären Wurzelknoten, Elementknoten, Attributknoten, Namensraumknoten, Processing-Instruction-Knoten, Kommentarknoten und Textknoten. Wurzelknoten Der Wurzelknoten, oder Root Node, definiert den Ursprung des XML-Baums und umschließt alle anderen Knoten des Dokuments. Er bestimmt außerdem die Art des XML-Dokuments und darf nur einmal in einem Dokument vorkommen. So stellt im folgenden Beispiel 1 <?xml version="1.0" encoding="iso "?> 2 <html xmlns=" 3 <head></head> 4 <body> 5 <div id="content" class="main"> 6 <h1>meine Überschrift</h1> 7 <p>lorem ipsum dolor sit amet, consectetuer sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.</p> 8 </div> 9 </body> 10 </html> das Element <html> den Wurzelknoten des Dokuments dar. Elementknoten In der XPath-Spezifikation entspricht jedes Element eines XML-Dokuments einem Elementknoten, über den es adressiert werden kann. Der Textwert eines Elementknoten ist der reine Textwert des Elements an sich sowie der Textwert seiner sämtlichen Kindelemente. Im zuvor angeführten Beispiel sind die Elemente head und body jeweils Elementknoten mit diversen Kindknoten (div, h1, p), die ihrerseits wiederum Elementknoten wären. Attributknoten Ähnlich den Elementen eines XML-Dokuments gibt es auch für jedes Attribut einen entsprechenden Attributknoten. Wichtig zu erwähnen ist, dass ein Attributknoten in XPath aber nicht als Kindknoten des Elements, in dem es definiert wird, angesehen wird und auch nicht auf diese Art adressiert werden kann. Bei Attributknoten wird ihr Textwert durch den Attributwert bestimmt.

38 4. XSLT 29 Im zuvor angeführten Beispiel hat das Element div zwei Attribute (id und class), die Attributknoten entsprechen, diese sind jedoch keine Kindknoten des Elements. Textknoten Text aus CDATA-Abschnitten (vgl. Abschnitt 3.2.6) wird als Textknoten behandelt und der Text innerhalb der Abschnitte stellt den gesamten Textwert des Knotens dar. Textknoten sind vor allem deshalb wichtig, da sie bei einer Transformation von XML-Dokumenten im Normalfall bestehen bleiben, im Gegensatz zu den einzelnen Element- und Attributnamen, die im Ergebnisdokument meist andere sind. sonstige Knoten Namensraumknoten, Processing-Instruction-Knoten sowie Kommentarknoten [11, Abschnitte 5.4, 5.5 und 5.6] sind für die dynamische Generierung von XSLT-Templates weniger interessant und werden deshalb an dieser Stelle nicht weiter besprochen Adressierung Um bestimmte Knoten adressieren zu können, wird, ausgehend vom aktuellen Knoten, ein bestimmter Lokalisierungspfad [11, Kapitel 2] definiert. Dieser XPath-Ausdruck setzt sich aus Lokalisierungsschritten gefolgt von Prädikaten zusammen. Die einzelnen Lokalisierungsschritte bestehen wiederum aus der Angabe der Achse und eines Knotentests Achsen Die Angabe der Achse bestimmt die Beziehung des zu findenden Knotens im Vergleich zum Ausgangsknoten. Die wichtigsten Achsen sind [11, Abschnitt 2.2]: self verweist auf den Ausgangsknoten. child verweist auf alle Kindelemente des Ausgangsknoten. parent verweist auf den Elternknoten. ancestor verweist auf alle übergeordneten Knoten. descendandt verweist auf alle dem Ausgangsknoten untergeordneten Knoten. following-sibling verweist auf alle nachfolgenden Geschwisterknoten. preceding-sibling verweist auf zuvorkommende Geschwisterknoten. attribute verweist auf einen Attributknoten des Ausgangsknotens.

39 4. XSLT Knotentests Sogenannte Knotentests [11, Abschnitt 2.3] schränken den Adressierungspfad nach Angabe der Achse weiter ein. Sie werden in der Form ACH- SE::KNOTENTEST geschrieben und können verschiedene Eigenschaften definieren, die Knoten innerhalb der gewählten Achse erfüllen müssen, um durch den Lokalisierungspfad adressiert zu werden. Knotentest: Name Durch Angabe eines Knotennamens in der Form ACHSE::NAME werden die entsprechenden Knoten adressiert. So würde beispielsweise die Angabe child::person alle Kindknoten mit dem Namen person des aktuellen Knotens ansprechen. Knotentest: text() Der Knotentest text() wählt alle Textknoten innerhalb der definierten Achse aus. Knotentest: * Bei Angabe des Knotentests *, z. B. in Form child::* werden alle Knoten innerhalb der definierten Achse gefunden. Knotentest: node() Der Knotentest node() wählt beliebige Knoten aus Relative und absolute Pfade Lokalisierungspfade können entweder relativ oder absolut angegeben sein. Absolute Pfade gehen immer vom Wurzelknoten des Dokuments aus (eingeleitet mit Schrägstrich), wogegen relative Lokalisierungspfade den Pfad, ausgehend vom aktuellen Knoten, angeben Prädikate Mit der Angabe von Prädikaten können Lokalisierungspfade noch weiter eingeschränkt werden. Dabei werden Bedingungen definiert, die die zuvor durch die Angabe der Achse und den Knotentest ausgewählte Knotenmenge überprüfen. Prädikate werden in der Form ACHSE::KNOTENTEST[PRAEDIKAT] definiert und geben entweder den Wert true oder false zurück. Je nach Rückgabewert wird der Knoten aus dem Node-Set entfernt oder nicht.

40 4. XSLT 31 Innerhalb der der Prädikate können Funktionen und Operatoren verwendet werden, die den boolschen Ausdruck formen, der danach ausgewertet wird. Mögliche Funktionen teilen sich in die Bereiche Node-Set (z. B. Position des Knotens im Node-Set, Anzahl der Knoten), String-Funktionen (z. B. Zeichenkettenanalyse und -manipulation), Logische Funktionen (z. B. True/False-Ausdrücke innerhalb des Prädikats) sowie Numerische Funktionen (z. B. Summenberechnung) [27, Abschnitte und 5.3]. Der Lokalisierungspfad 1 child::book[child::text() = "Mein XPath-Buch"] adressiert beispielsweise alle Kindelemente Namens book des Ausgangsknotens, die einen Kindknoten haben, der vom Typ ein Textknoten ist und den Wert Mein XPath-Buch hat. Verkürzte Notation Es gibt in XPath eine verkürzte Schreibweise für die Adressierungspfade, die im Grunde sogar leichter zu lesen ist als die Langfassung. Dabei gibt es diverse Abkürzungen für die Angabe der Achse [19, Seite 41]: Die Angabe der Kindelement-Achse (child::) kann generell weggelassen werden. Die Elternachse (parent::) wird mit.. abgekürzt. Die auf sich selbst verweisende Achse (self::) wird mit. abgekürzt. Die Angabe der Attributachse (attribute::) wird ersetzt. Die XPath-Funktion zur Angabe einer Position innerhalb eines Elements ([position() = NUMBER]) wird mit [NUMBER] abgekürzt. So kann beispielsweise der XPath-Ausdruck 1 /child::author/child::book[position()=2]/attribute::title wie folgt abgekürzt werden: 1 /autor/book[2]/@title Bei einer automatischen Generierung der XSLT-Templates, und somit auch der Lokalisierungspfade, hätte die Benutzung der verkürzten Schreibweise, außer einer unerheblichen Speicherersparnis, keine Vorteile, jedoch bietet es sich an diese trotzdem zu verwenden, da sie für den Benutzer einfach besser lesbar ist.

41 4. XSLT XSL-Editoren Für die Entwicklung eines XSL-Editors ist es notwendig, zuerst bestehende Applikationen zu untersuchen. Obwohl es grundsätzliche natürlich möglich ist, Anwendungen in XSL (somit auch XSLT) in einem beliebigen Text- Editor zu erstellen, gibt es diverse spezielle XML/XSL-Editoren, die besondere Hilfestellung bei der Entwicklung bieten 7. Die verfügbaren Editoren muss man grundsätzlich in zwei gänzlich verschiedene Kategorien teilen. Diejenigen, die hauptsächlich bei der Entwicklung des XML-Markups an sich unterstützen sollen (z. B. oxygen 8, Exchanger XML 9 ) und diejenigen, die entwickelt wurden, um die Daten innerhalb des XML-Markups zu bearbeiten und zum Teil das eigentliche Markup vom Benutzer verstecken (z. B. XMetaL 10, Syntext Serna 11 ) [9, Abschnitt 3.3]. Während die erste Kategorie für die Entwicklung von XSLT-Sheets wunderbar geeignet ist, richten sich die Produkte der zweiten Kategorie eher an Redakteure, die Inhalte, im XML-Format, warten sollen, als an Entwickler. Aktuell betrachtet verschwimmt die Grenze zwischen den einzelnen Kategorien jedoch immer mehr und so bieten viele große Editoren wie oxygen oder XMLSpy 12 mittlerweile die Möglichkeit, die Ansicht auf das zu entwickelnde XML-Dokument gänzlich anzupassen und sich frei zwischen der kompletten Darstellung des Markups (es besteht sogar die Möglichkeit den Inhalt auszublenden und nur die XML-Struktur zu bearbeiten), und des vollständigen Verzichts darauf, zur reinen Bearbeitung der Inhalte, zu bewegen. Von den großen XML/XSL-Editoren angebotene Features, die für eine Entwicklung von XSL-Applikationen von besonderer Bedeutung sind: XML/XSL-Syntaxhighlighting unterstützte XSLT-Template-Entwicklung (durch Element/Attribut- Bibliothek) Erstellung von XPath-Lokalisierungspfaden über Wizard oder Baumansicht eingebauter XSLT-Prozessor zum Testen der XSLT-Sheets XSLT-Debugging grafische XML-Schema-Entwicklung DTD-Analyse und Manipulation Integration in IDEs (zumeist Eclipse oder Visual Studio.NET)

42 4. XSLT 33 Man sieht, dass die grundlegende Hilfestellung mancher Editoren bereits sehr weit geht und umfangreiche Hilfsmittel zur Analyse und Entwicklung von XSLT-Transformationsregeln (XPath-Wizard, Element/Attribut- Bibliotheken, XSLT-Prozessor für Testzwecke, XSLT-Debugger) angeboten werden. Trotz der bereitgestellten Hilfsmittel steht (bei allen untersuchten XML/ XSL-Editoren) jedoch fest: Die Entwicklung der einzelnen XSLT-Transformationsregeln muss in jedem Fall vom Benutzer selbst durchgeführt werden. Es mögen zwar die Grundstruktur von XSLT-Templates durch den Editor erstellt und XPath-Ausdrücke per Knopfdruck erzeugt werden, es gibt jedoch aktuell keine Algorithmen, die dynamisch komplette XSLT-Templates für XML-Dokumente generieren. Und genau an diesem Punkt soll der zu entwickelnde Algorithmus einsetzen: Basierend auf beispielhaften Quell- und Ergebnisdokumenten komplette (und einsatzfähige) XSLT-Templates zur Transformation von XML- Dokumenten zu generieren.

43 Kapitel 5 Realisierung eines XSLT-Editors Bei der Realisierung des XSLT-Editors stellt sich zuerst die Frage, was man von solch einem Editor überhaupt erwartet. Es gibt bereits einige Editoren (s. Abschnitt 4.5) für die manuelle Erstellung und Bearbeitung von XSLT-Sheets. Diese sind zum Teil sehr mächtig und bieten viel Hilfestellung bei der manuellen Entwicklung von XSLT- Templates inklusiv teilweiser XSLT 2.0-Unterstützung [18], mächtigen Wizards für XML Query Language (XQuery) und XPath-Ausdrücke, Debugger und vieles mehr. Jedoch bieten all diese Editoren zwar Hilfestellung bei der manuellen Entwicklung von XSLT-Templates, nehmen dem Entwickler die eigentliche Arbeit aber nicht ab. Sinnvoller wäre es, einen Editor zu entwickeln der den stets wiederkehrenden Schritt des Vergleichens von Quelldokument und Ergebnisdokument und des folgenden Erstellens der einzelnen XSLT-Templates abkürzt, indem er dies selbst durchführt. Im besten Fall sollte man dem Editor eine Anzahl von beispielhaften Quelldokumenten und den entsprechenden Ergebnisdokumenten (sprich die transformierten Quelldokumente) geben und dieser generiert daraus automatisch die entsprechenden XSLT-Templates, um die gewollte Transformation zu erzielen. Für den Fall, dass der XSLT-Editor nicht alle notwendigen Templates generieren kann, müsste die Möglichkeit gegeben sein, manuell eingreifen zu können, neue XSL-Transformationsregeln hinzuzufügen, bestehende falls nötig korrigieren, und die generierten Templates direkt im Editor testen zu können. Vorstellbare Einsatzgebiete für solche Editoren wären die Entwicklung von XSLT-Templates für alle Projekte, die einen großen Bereich von Elementen und Strukturen abdecken müssen, sowie für die Transformation von Dokumenten, deren Elementumfang erweitert werden und somit zu Beginn 34

44 5. Realisierung eines XSLT-Editors 35 nicht klar definiert werden kann. Genannt seinen hier beispielhaft: Datenimport/-export über XML-Struktur in Systemen Transformation der XML-Daten in ein Publishingformat (z. B. XHTML, PDF, ODF) Schließlich wäre eine automatische Generierung der XSLT-Templates auch besonders dann von Vorteil, wenn dadurch bei der Transformation auftretende Konflikte (z. B. weil mehrere Templates auf einen Knoten im XML- Dokument zutreffen) vermieden werden können, indem die Konfliktauflösung bereits vom Algorithmus berücksichtigt wird. 5.1 Anforderungen Folgende Anforderungen an den Editor stellen sich aus den zuvor gesammelten Überlegungen: Bereitstellung grundlegender Editorfunktionen (Dateioperationen, Suchen/Ersetzen, Copy & Paste) Algorithmus zur automatischen Generierung von XSLT-Templates basierend auf Quell- und Ergebnisdokumenten Generierung der Lokalisierungspfade für erstellte Templates Einbindung eines XSLT-Prozessors zur Überprüfung der generierten Templates 5.2 Wahl des Frameworks Am Anfang der Entwicklung stellte sich die Frage, ob es sinnvoll ist, den Editor als Standalone-Applikation zu entwickeln oder ihn als Plug-in in eine bestehende Entwicklungsumgebung zu integrieren. Gegen eine Realisierung als Standalone-Produkt (geplant in C# unter Einsatz der Windows Presentation Foundation (WPF)) sprach der sehr hohe Entwicklungsaufwand, der nötig gewesen wäre, um auch nur die grundlegendsten Funktionen bereitzustellen, die man von einem Editor erwartet (Dateioperationen, Suchen/Ersetzen, Syntaxhighlighting, etc.). Für die Programmierung als Plug-in einer bestehenden Entwicklungsumgebung (in diesem Fall Eclipse 1 ) sprachen folgenden Punkte: verbreitete Entwicklungsumgebung (hohe Akzeptanz im Vergleich zu Standalone-Produkt) 1

45 5. Realisierung eines XSLT-Editors 36 viele existierende Plug-ins (gute Verbreitungsmöglichkeiten) performantes Plug-in Framework (viele bestehende Funktionen) nutzbare Grundfunktionalität (voll funktionsfähige Entwicklungsumgebung) 5.3 Struktur des realisierten Editors Der AAXS-MultiPageEditor besteht aus den folgenden Komponenten: User Interface XML-Parser AAXS (s. Kapitel 6) XSLT-Prozessor Grundlegende Hilfestellung Grundlegende Hilfestellung beim Entwickeln von XSLT-Templates bietet die Bereitstellung eines XML-Editors mit Syntaxhighlighting, da dies eine zu erwartende Grundfunktionalität aktueller Editoren darstellt. Zusätzliche Hilfe beim Entwickeln ist die Einbindung eines XSLT-Prozessors (s. Abschnitt 5.3.4), um generierte XSLT-Templates an Ort und Stelle testen zu können User Interface Durch die Erstellung des Programms als Eclipse-Plugin bot es sich an, auf die bereits vorhandenen Editor-Klassen aufzusetzen. Zur Wahl stand entweder die Realisierung als ein einzelner Editor, wobei die Arbeitsschritte über ein eigenes Menü bzw. Buttons in der Aktionsleiste angesprochen und die Ergebnisse der Verarbeitungsschritte in Fenstern geöffnet würden oder die Verwendung der MultiPageEditor-Klasse 2 von Eclipse. Die Entwicklung als MultiPageEditor bietet sich dahingehend an, dass die Aktivierung der einzelnen Verarbeitungsschritte durch Wechseln zwischen den Editorfenstern sehr unkompliziert ist, die Benutzer auf sämtliche Verarbeitungsschritte sofort zurückgreifen können und so nicht aus der gewohnten Programmierumgebung herausgehen müssen. Da diese Variante der Benutzeroberfläche zudem die schnellste Möglichkeit bietet, zwischen den einzelnen Verarbeitungsschritten umzuschalten, wurde schließlich die Realisierung als MultiPageEditor gewählt. Um den Editor zu starten, genügt es im Package Explorer oder der hierarchischen Ansicht eine Datei (sinnvollerweise ein XML) auszuwählen und 2 org.eclipse.platform.doc.isv/reference/api/org/eclipse/ui/part/multipageeditor.html

46 5. Realisierung eines XSLT-Editors 37 Abbildung 5.1: Quelldokument wurde geladen. über ihr Kontextmenü die Option [Open with] -> [AAXS MultiPageEditor] zu wählen. Die Benutzeroberfläche im AAXS-MultiPageEditor wurde in 5 Editor- Sheets geteilt. Ein Editorfenster lädt das Quelldokument, das im nächsten wird das Ergebnisdokument erstellt, im dritte Sheet erstellt der Algorithmus XSLT-Templates, im nächsten kann ein zu testendes XSLT-Template zusammengebaut werden und das fünfte Fenster zeigt das Ergebnis der XSL- Transformation. Sheet 1: Quelldokument Sheet 1 (Abb. 5.1) lädt den Inhalt der Datei in einen voll funktionsfähigen XML-Editor. Die hier zu ladende Datei stellt die XML-Struktur dar, auf welcher der Vergleichsalgorithmus AAXS (s. Abschnitt 6) basierend arbeitet. Das Quelldokument kann an dieser Stelle verändert werden, um verschiedene Strukturen und deren Auswirkungen zu testen. Zusätzlich können hier später weitere Dokumente geladen werden, um den Algorithmus mit weiteren Beispielstrukturen zu füttern. Sheet 2: Ergebnisdokument Im zweiten Sheet (Abb. 5.2) wird das gewünschte Ergebnisdokument (ebenfalls XML) geladen. Diese XML-Struktur wird vom AAXS (s. Abschnitt 6) benutzt die XSLT-Templates zu erstellen, die notwendig sind, um das Quelldokument aus dem ersten Sheet in das in diesem Sheet geladene Ergebnis-

47 5. Realisierung eines XSLT-Editors 38 Abbildung 5.2: Ergebnisdokument wurde geladen. dokument zu transformieren. Die Funktionen dieses Sheets entsprechen denen des XML-Editors des ersten Sheets mit der einen Ausnahme, dass der Inhalt des Editorfensters nicht in der (zuvor gewählten) Datei gespeichert werden kann und das zu vergleichende Ergebnisdokument per Copy & Paste geladen werden muss. Standardmäßig wird hier wie im ersten Editorfenster der Inhalt der XML- Datei, über deren Kontextmenü der MultiPageEditor aufgerufen wurde, geladen. Sheet 3: Generierte XSLT-Templates Bei Aktivierung des dritten Sheets (Abb. 5.3) wird der AAXS-Algorithmus (s. Kapitel 6) gestartet. Nach dem Durchlauf (die Dauer ist entscheidend von der Größe des Quelldokuments abhängig) werden die, basierend auf Vergleichen des Quelldokuments mit dem Ergebnisdokument, erstellten XSLT- Templates ausgegeben. In diesem Editorfenster kann nicht editiert werden, da ein Wechsel der Fenster sofort einen neuen Durchlauf des Vergleichsalgorithmus und sofortige Löschung der editierten Templates verursachen würde. Jedoch können einzelne XSLT-Templates (oder der gesamte XSLT-Template-Sheet) per Copy & Paste in den vierten Sheet des MultiPageEditors kopiert und dort bearbeitet werden.

48 5. Realisierung eines XSLT-Editors 39 Abbildung 5.3: XSLT-Templates wurden generiert. Abbildung 5.4: Zusammenstellen des XSLT-Template-Sheets. Sheet 4: zu testender XSLT-Sheet Sheet 4 (Abb. 5.4) bietet wiederum einen XML-Editor, um aus den generierten XSLT-Templates einen XSLT-Template-Sheet zusammenzubauen und diesen im nächsten Schritt zu testen. Durch diesen Zwischenschritt ist es auch sehr einfach möglich, den Ver-

49 5. Realisierung eines XSLT-Editors 40 Abbildung 5.5: XSL-Transformation. gleichsalgorithmus auf mehrere, verschiedene Dateien anzuwenden, die Ergebnisse zu sammeln und dann einen großen XSLT-Template-Sheet zu erstellen, der einen großen Bereich der zu transformierenden XML-Strukturen abdeckt. Auch ist eine manuelle Bearbeitung einzelner XSLT-Templates an dieser Stelle manchmal notwendig, wenn z. B. der Algorithmus komplizierte Strukturen nicht erkannt und somit nicht ausreichende XSLT-Templates erstellt hat oder zusätzliche Informationen/Inhalte hinzukommen, die nicht in den geladenen Quell- und Ergebnisdokumenten erfasst wurden (s. Abschnitt 6.4). Sheet 5: XSL-Transformation Bei Aufruf von Sheet 5 (Abb. 5.5) wird über einen XALAN-XSLT-Prozessor das Quelldokument aus Sheet 1 mit dem XSLT-Template-Sheet aus dem vierten Editorfenster transformiert und das Ergebnis ausgegeben. Im Idealfall entspricht die generierte Ausgabe dem Inhalt von Sheet 2 (und somit dem Ergebnisdokument). Wenn dem nicht so ist, kann der Benutzer die XSLT-Templates manuell bearbeiten und die XSLT-Transformation zum Testen nutzen, bis das gewünschte Ergebnis erscheint Multiple Inputs Zum Entwicklen eines XSLT-Template-Sheets für ein großes Projekt (z. B. Datenaustausch zwischen zwei Systemen) wird man sicher nicht mit einem

50 5. Realisierung eines XSLT-Editors 41 Beispiel-Quelldokument und einem Beispiel-Ergebnisdokument auskommen, sondern viele verschiedene Beispieldateien benötigen, um alle Elemente und Strukturen mit den generierten XSLT-Templates abdecken zu können. Hierfür wird der Zwischenschritt in Editorfenster 4 benützt, wo die generierten XSLT-Templates gesammelt bzw. editiert werden können. Zwar könnte dies auch anders gelöst werden, wie durch eine zusätzliche Auswahl von Dokumenten über eine eigene Lademaske oder eine Erweiterung der Hierarchieansicht (z. B. Checkboxen zur Auswahl), dies würde jedoch die einfache Bedienbarkeit des MultiPageEditors einschränken, da der Arbeitsablauf anders als gewohnt wäre Externe Libraries XML-Parser Zum Parsen der XML-Dateien wird die JAVA-interne Java API for XML Processing (JAXP) benützt und das XML-Dokument als DOM-Objekt behandelt. XSLT-Prozessor XSLT-Transformationen werden über den Xalan-XSLT-Prozessor 3 durchgeführt, da dieser besser zu integrieren war als der ebenfalls getestete Prozessor Saxon 4 und beide eine ähnliche Performanz aufweisen [15]. Für die Transformation von XML-Dateien in dem Umfang wie er bei der Entwicklung eines XSLT-Template-Sheets zu erwarten ist, reicht die Geschwindigkeit des Xalan aus. Sollte jedoch die Transformation von ungleich größeren Dokumenten nötig sein, wäre es ohne weiteres möglich, ihn gegen einen performanteren XSLT-Prozessor auszutauschen und somit die Geschwindigkeit der Transformation zu erhöhen. 5.4 Beschränkungen Der erstellte Editor kann mit beliebigen Textdateien umgehen, der Algorithmus zur Generierung der XSLT-Templates benötigt jedoch wohlgeformte XML-Dateien als Vergleichsdokumente (s. Abschnitt 6.4). Desweiteren gibt es momentan keine Möglichkeit die erstellten XSLT- Templates, direkt aus dem Editor heraus, abzupspeichern und das beispielhafte Ergebnisdokument kann nicht über den Dateiexplorer von Eclipse geladen werden sondern muss per Copy & Paste direkt in das entsprechende Editorfenster kopiert werden

51 5. Realisierung eines XSLT-Editors 42 Auch darf in den XML-Dateien noch keine DTD angegeben werden, da der XSLT-Prozessor keinen Zugriff auf die Datei hätte und die Transformation abbrechen würde. 5.5 Fazit Es wurde ein XSLT-Editor implementiert, dessen Hauptaugenmerk auf der automatische Abarbeitung von Beispieldokumenten und der folgenden Generierung von XSLT-Templates liegt. Der Editor bietet in der finalen Version folgende Features: Grundlegende Editorfunktionen (Dateioperationen, Suchen/Ersetzen, Copy & Paste) Syntaxhighlighting automatische Generierung von XSLT-Templates basierend auf Beispiel- Dokumenten Generierung der XPath-Lokalisierungs-Pfade für die XSLT-Templates Möglichkeit zur Überprüfung der Templates durch Einbindung eines XSLT-Prozessors

52 Kapitel 6 Algorithmus zur Generierung von XSLT-Templates 6.1 Grundsätzliche Überlegungen Die automatische Generierung von XSLT-Templates basierend auf Vergleichen zwischen beispielhaften Quelldokumenten und entsprechenden Ergebnisdokumenten (entsprechen den Quelldokumenten nach der Transformierung) ist ein komplett neues Forschungsgebiet, das bisher keiner der großen XSL-Editoren bietet. Hier bot es sich an, die einzelnen Schritte, die für die Erstellung der Templates notwendig waren, in möglichst kleine und voneinander unabhängige Bereiche aufzuteilen und gesondert zu behandeln. So wurden zum Einen die Verarbeitungsschritte von den Analysemethoden getrennt und auch die Korrekturmethoden und die tatsächliche Erstellung der Templates möglichst unabhängig voneinander entwickelt. Dadurch ist es möglich, verschiedene Analysemethoden zu verwenden, macht jedoch auch Sortiermethoden notwendig, um mögliche doppelte oder konfliktgefährliche Templates auszusortieren. Am schwierigsten ist jedoch die Entwicklung von Methoden zum Auffinden von Mustern über reine Syntaxanalyse. Dies hat sich im Laufe der Entwicklung als fast unmöglich herausgestellt, weshalb dazu übergegangen wurde, dies über eine Statistikanalyse zu versuchen. Auch können Mustererkennungsmethoden aus anderen Bereichen (z. B. Digitale Bildanalyse und Bildverarbeitung) nur ansatzweise Hilfestellung bieten, da es viele bestehende Lösungen für grafische Probleme, jedoch sehr wenig für syntaktische Problemstellungen gibt. Am ehesten fällt dies mit dem Bereich der semantischen Verbindungen (Stichwort: Semantic Web) zusammen, die jedoch auch noch (obwohl schon seit langer Zeit) im Anfangsstadium sind und zu einem großen Teil mit Meta-Daten arbeiten, die man bei einer rein algorithmischen Analyse der Syntax von Daten eben nicht zur Verfügung hat. 43

53 6. Algorithmus für XSLT-Templates Problembereiche Es war bereits zu Beginn der Entwicklung abzusehen, dass die Mustererkennung wohl einen der größten Problembereiche bei der Entwicklung des Algorithmus darstellen würde. Weitere Problembereiche waren die Konfliktlösung bei mehrfach auftretenden und zutreffenden XSLT-Templates und die möglichst allgemeine Formulierung der XPath-Lokalisierungspfade (relative Adressierung der anzusprechenden Knoten). Pattern Recognition Die Mustererkennung hat sich im Laufe der Entwicklung des Algorithmus als eines der größten Probleme dargestellt. Das Matching einzelner Elemente war einfach. Schon über reines Content-Matching (vgl. Abschnitt 6.3.2) konnte eine Vielzahl von Elementen der Quelldokumente ihren Entsprechungen in den beispielhaften Ergebnisdokumenten zugeordnet werden. Für die Mustererkennung musste jedoch eine gänzlich andere Methode gefunden werden. 6.2 Bestehende Ansätze und Lösungen Obwohl das Thema einer automatischen Generierung von XSLT-Sheets die Forschung seit Jahren beschäftigt Version 1.0 der XSLT-Spezifikation wurde bereits im Jahr 1999 verabschiedet gibt es bisher keine funktionalen Lösungsansätze. So hielt Bob DuCharme auf der XML-Konferenz 2005 einen Vortrag über dieses Thema [12, Kapitel 1] und stellte die dabei auftretenden Probleme dar er zeigte eine Möglichkeit, die manuelle Entwicklung von XSLT-Sheets vom Benutzer wegzunehmen indem die zu erreichende Struktur in Form eines Arbeitsblatts (Excel Spreadsheet) vom Benutzer definiert und danach in XSLT-Templates übersetzt wurde [12, Kapitel 2 und 3]. Da jedoch diese Variante zum Einen ebenfalls massiven Benutzerinput erfordert und die Abstraktion der Problemebene auf 2 Dimensionen (mehr sind bei diesem Lösungsansatz in einer Tabelle nicht möglich) sicherlich nicht für einen großen Anwendungsbereich geeignet ist Generierung bei bekannter Struktur Ein Ansatz die Generierung von XSLT-Templates zumindest teilweise zu automatisieren stammt von Michelle Bealle. Ausgehend von der Problemstellung, dass aus einem XML eine HTML-Tabelle erstellt werden sollte und zwar alle Elemente definiert waren, die zugewiesenen Attribute sich aber (vom Attributnamen, nicht vom Wert her) ändern konnten. Als Lösung wurde ein XSLT-Sheet für die grundsätzliche Transformation des XMLs (mit bekannten

54 6. Algorithmus für XSLT-Templates 45 Elementen) in eine HTML-Tabelle erstellt, das tatsächliche XML geparst und die, zunächst unbekannten, Attribute als XSL-Attributes im XSLT-Sheet angelegt und während der Transformation an die richtigen Stellen eingefügt [3]. Auch wenn diese Anwendung eine teilweise automatische Generierung von XSLT-Templates darstellt, so ist dies trotzdem als Spezialfall zu sehen. Im vorliegenden Fall war die grundsätzliche Struktur des XML-Dokumentes von vornherein bekannt, unbekannt war nur, welches Element welche Attribute besitzen würde. Ein weiterer Punkt der gegen einen solchen Ansatz spricht ist, dass dies wieder nur ein zweidimensionales Problem darstellt. Dadurch, dass die Elemente untereinander keine Abhängigkeit besitzen konnten, also lediglich die unbekannten Attribute mit den bekannten Elementen verknüpft werden musste, war die Lösung des Problems mit wenig Aufwand zu realisieren. Wenn aber davon ausgegangen wird, dass erstens die Elemente des XML- Dokuments bei der Erstellung nicht bekannt sind was aber durch Analyse der DTD oder eines vorhandenen XML-Shemas (vgl. Abschnitte und 3.1.2) gelöst werden könnte und zweitens Abhängigkeiten zwischen den Elemente des XMLs bestehen, also Strukturen analysiert werden müssen, so stellt dies keinen möglichen Lösungsansatz dar Analyse des XML-Schemas Das größte Problem bei der automatischen Generierung von XSLT-Templates sind die vielen Unbekannten. Zu Beginn der Analyse des XML-Dokuments ist nicht bekannt welche Elemente und Attribute das XML-Dokument enthält und in welcher Struktur. Deshalb ist es auch sehr schwer, Knoten aus dem Quelldokument dem beispielhaften Ergebnisdokument zuzuordnen, da sie im Grunde Kindknoten jedes bestehenden Knotens sein könnten. Eine mögliche Einschränkung des Problems, wenngleich auch keine vollständige Lösung, bietet eine Analyse der Dokumentenstruktur. Dafür eignet sich natürlich die Analyse einer bestehenden Beschreibung der Dokumentenstruktur (DTD, XML-Schema) am besten. Mögliche Analyseansätze wären grundsätzlich die Beschränkung der möglichen Kindelemente eines XML- Knotens auf die in der Struktur erlaubten Knoten, eine Analyse der Verschachtelungsstruktur [20, Abschnitte 2.7 und 2.8] oder eine Häufigkeitsstatistik. Dieser Ansatz funktioniert natürlich nicht wenn nicht sowohl das Quelldokument als auch das beispielhafte Ergebnisdokument ein XML-Schema besitzen, was häufig vorkommt, da vielen, über die Jahre entwickelten, XML- Dialekten eine DTD zu Grunde liegt (z. B. XHTML), eine andere Schemasprache verwendet wird (z. B. Document Structure Description (DSD) 1, Schematron 2, Regular Language Description for XML New Generation (RE

55 6. Algorithmus für XSLT-Templates 46 LAX NG) 3 ), oder gänzlich auf eine Definition der Dokumentenstruktur verzichtet wird Semantischer Ansatz In einem Beitrag zur XML Konferenz 2002 spricht Joshua Fox die Probleme bei einer automatischen Generierung von XSLT-Sheets an und stellt fest dass auch die Analyse von DTDs oder XML-Schemen eines Dokuments die Probleme nur einschränken, die Hauptarbeit aber trotzdem noch vom Entwickler erledigt werden muss, der sowohl die Semantik, als auch die Struktur der Quell- und Ergebnisdokumente analysieren und dann manuell entsprechende Transformationsregeln erstellen muss [14, Kapitel 1]. Als Lösungsansatz schlägt er die Anwendung eines Semantic Hubs vor, sozusagen die Einführung einer Abstraktionsebene auf die, die einzelnen Schemen gemappt werden. Dadurch würde es ausreichen ein XML-Schema nur ein einziges Mal auf die Ontologie der Abstraktionseben zu mappen um von dort aus ein Mapping auf beliebige andere Schemen (die ebenfalls bereits auf die Abstraktionsebene gemappt wurden) durchzuführen [14, Kapitel 5]. Die von ihm vorgeschlagene Abstraktionsebene ist objektorientiert organisiert, aufgeteilt in einzelne Klassen die, vorstellbar wie in objektorientierten Programmiersprachen, voneinander abgeleitet sein können oder Schnittstellen zueinander besitzen können [14, Abschnitt 6.1]. Er schlägt vor das Mapping auf die Abstraktionsebene über die Definition eines semantischen Schemas in Form von XML Schema Definition (XSD)-Komponenten zu realisieren [14, Kapitel 7]. Das auftretende Problem dieses Lösungsansatzes ist, dass, ein tatsächliches Funktionieren des Ansatzes vorausgesetzt, trotzdem zumindest einmal das XML-Schema jedes Formats auf das Abstraktionsschema manuell gemappt werden müsste, ein Vorgang der gleich viel Aufwand wie das manuelle Mapping der Quelldokumentenstruktur auf das Schema des Ergebnisdokuments erfordert. Auch dieser Ansatz setzt voraus, dass Quell- und Ergebnisdokument eine Strukturbeschreibung (in diesem Fall explizit ein XMl- Schema) besitzen Fazit Die besprochenen Lösungsansätze sind leider nur Ansätze zur Lösung der vielen, unterschiedlichen Probleme die bei der automatischen Generierung von XSLT-Templates auftreten. Vom, in Abschnitt beschriebenen, Spezialfall abgesehen hat sich aus keinem der angeführten Ansätze eine einsatzfähige Applikation entwickelt. Dies, und die Tatsache, dass die Suche nach einer Lösung für die automatische Generierung von Transformationsregeln 3

56 6. Algorithmus für XSLT-Templates 47 seit der Einführung von XSLT 1.0 im Jahr 1999 immer noch andauert, zeigt wie komplex die Problematik ist. Am vielversprechendsten scheint die Analyse der Dokumenttypdefinitionen oder besser des XML-Schemas eines Dokuments zu sein, da dadurch zumindest das Problem der fast unendlichen Kombinationsmöglichkeit von Element/Attribut-Kombinationen in einem Dokument eingeschränkt werden kann. Da dies jedoch ein Vorhandensein einheitlicher Schemadefinitionen für alle, in die Transformation einbezogenen, Dokumente voraussetzt was aktuell nur in einem Teil der Anwendungsfälle zutrifft stellte sich diese Methode für die Realisierung der angestrebten Funktionsweise des Algorithmus als nicht einsetzbar heraus. 6.3 Schema und Funktionsweise Die grundsätzliche Funktionsweise der auf Basis der Recherche entworfenen XSLT-Template-Generierung ist wie folgt (Abb. 6.1): Das Quelldokument wird eingelesen, geparst und in einem DOM-Baum gespeichert. Das beispielhafte, entsprechende Ergebnisdokument wird eingelesen, geparst und in einem DOM-Baum gespeichert. Die verschiedenen Matching-Methoden versuchen Elemente/Attribute zu verknüpfen. Die Methode zur Mustererkennung wertet die gefundenen Elemente/Attribute aus und stellt eine Statistik auf. Die XSLT-Template-Patterns werden generiert. Ein Sortierungsalgorithmus ordnet die generierten XSLT-Template- Patterns um Konflikte zu vermeiden. Der erstellte XSLT-Template-Sheet wird ausgegeben. Zunächst wird das Quelldokument entweder über den Dateiexplorer in Eclipse oder per Copy & Paste geladen und vom JAXP-XML-Parser geparst und als DOM-Objekt gespeichert. Danach wird auf ähnliche Art mit dem entsprechenden Ergebnisdokument, das für die Vergleiche verwendet werden soll, verfahren, dieses kann jedoch nur direkt per Copy & Paste geladen werden. Im nächsten Schritt werden die verschiedenen Matching-Methoden aufgerufen und versuchen nun auf Basis von Vergleichen des Inhalts von Textknoten, von Elementnamen, Attributnamen und -werten sowie CDATA-Abschnitten mögliche Entsprechungen einzelner Knoten im Quelldokument einzelnen Knoten im Ergebnisdokument zuzuordnen. Die Ergebnisse werden zunächst gespeichert und noch nicht direkt ausgegeben.

57 6. Algorithmus für XSLT-Templates 48 Abbildung 6.1: Funktionsweise. In Folge wertet die Methode zur Mustererkennung die gefundenen Verknüfpungen zwischen den Attributen und Elementen des Quell- und des Ergebnisdokuments aus und stellt eine Statistik auf, in der Häufigkeit und Ebene von ineinander geschachtelten Elementen bzw. das Vorkommen von bestimmten Attributen gespeichert werden. Daraus versucht sie dann zusammengehörende Strukturen im Quelldokument auszumachen und diese entsprechenden Strukturen im Ergebnisdokument (z. B. Listen, Tabellen bei XHTML-Ausgabe) zuzuordnen. Im nächsten Schritt werden dann die eigentlichen Transformationsregeln generiert, deren Zielpfade berechnet (XPath-Ausdrücke - das eigentliche Pattern) und daraus kleine, nicht direkt zusammenhängende XSLT-Templates erstellt. Im vorletzten Schritt wird dann versucht, durch einen Sortieralgorithmus einerseits doppelte XSLT-Templates zu eliminieren und andererseits die bestehenden Templates nach Priorität zu sortieren, um Konflikte, wenn mehrere Templates gleichzeitig auf einen Knoten im XML-Dokument zutreffen, möglichst zu vermeiden. Als letztes wird die Rahmenstruktur um die erstellten XSLT-Templates gebaut und das somit generierte XSLT-Template-Sheet ausgegeben.

58 6. Algorithmus für XSLT-Templates Element-Matching Die Element-Matching-Methode versucht Elementknoten einerseits basierend auf deren Elementnamen, andererseits auf Basis der Anzahl ihrer Kindknoten sowie deren Inhalt, Entsprechungen im Ergebnisdokument zuzuordnen. Eine beispielhafte, reduzierte, Implementierung in Pseudo-Code könnte wie folgt aussehen: Algorithm 6.1: Element Matching 1: doelementmatching(node1, node2) 2: if node1.getn oden ame() == node2.getn oden ame() then 3: createxslttemplate(node1, node2); 4: else if node1.getchildn odes().count() == node2.getchildnodes().count() then 5: createxslttemplate(node1, node2); 6: else if node1.ist extn ode() == true and node2.ist extn ode() == true then 7: docontentmatching(node1, node2); 8: end if 9: end Content-Matching Beim Content-Matching wird versucht, einzelne Knoten des Quelldokuments entsprechenden Knoten im Ergebnisdokument zuzuweisen, basierend auf Vergleichen von deren Inhalten. Eine beispielhafte, reduzierte, Implementierung in Pseudo-Code könnte wie folgt aussehen: Algorithm 6.2: Content Matching docontentmatching(node1, node2) 2: if node1.ist extn ode() == true and node2.ist extn ode() == true then if node1.gett ext() == node2.gett ext() then 4: createxslttemplate(node1, node2); end if 6: end if end Am eindeutigsten funktioniert diese Zuweisung natürlich bei reinen Textknoten oder CDATA-Abschnitten, die zu annähernd 100% entsprechenden Knoten im Ergebnisdokument zugeordnet werden können.

59 6. Algorithmus für XSLT-Templates 50 Jedoch funktioniert diese Methode auch bei Elementknoten generell, vor allem wichtig für die spätere Strukturanalyse, da in dem Fall einfach ihr kompletter Inhalt (mitsamt untergeordneten Knoten) verglichen wird Attribute-Matching Bei Attribute-Matching wird entgegen des Namens hauptsächlich versucht, Elementknoten entsprechend zuzuordnen, basierend auf deren Attributen. Dabei wird sowohl nach Attributnamen als auch nach dem Wert des Attributknotens verknüpft. Eine beispielhafte, reduzierte, Implementierung in Pseudo-Code könnte wie folgt aussehen: Algorithm 6.3: Attribute Matching doattributematching(node1, node2) if node1.haschildn odes() == true and node2.haschildn odes() == true then 3: for i 0... node1.getchildnodes().count() do for j 0...node2.getChildNodes().count() do if node1.getchildn odes().getp os(i).isattributen ode() == true and node1.getchildn odes().getp os(j)-.isattributenode() then 6: if node1.getchildn odes().getp os(i).getn oden ame() == node2.getchildn odes().getp os(j).getn oden ame() then createxslttemplate(node1, node2); break; 9: else if node1.getchildn odes().getp os(i).gett ext() == node2.getchildn odes().getp os(j).gett ext() then createxslttemplate(node1, node2); break; 12: end if end if end for 15: end for end if end Diese Methode erkennt auch die Zuweisung von ID-Attributen Template Building Die Template-Building-Funktion baut die am Ende auszugegebenen XSLT- Templates zusammen, basierend auf den Ergebnissen der zuvor durchgelaufenen Matching-Methoden.

60 6. Algorithmus für XSLT-Templates 51 In dieser Funktion werden auch die notwendigen XPath-Ausdrücke für die Lokalisierungspfade der einzelnen Templates generiert sowie das Rahmenmarkup für die einzelnen Templates und den gesamten ausgegebenen XSLT-Template-Sheet Template Sorting Der Template-Sorting-Algorithmus löscht doppelte oder sehr ähnliche XSLT- Templates, die durch die Verwendung von verschiedenen Matching-Methoden entstanden sind und sortiert die danach übrig gebliebenen nach Prioriät, um Konflikte von vornherein zu vermeiden (Abb. 6.2). Eine beispielhafte, reduzierte, Implementierung in Pseudo-Code könnte wie folgt aussehen: Algorithm 6.4: Template Sorting dotemplatesorting(templatelist) for i 0...templateList.count() do for j i templateList.count() do 4: if templatelist.get(i).getrule() == templatelist.get(j).getrule() then templatelist.removefromlist(j); else if templatelist.get(i).getp attern() == templatelist.get(j).getpattern() then priority ); 8: end if end for end for end sorttemplates(templatelist.get(i).getpattern(), 6.4 Beschränkungen Leider gibt es diverse Einschränkungen für die Benützung des MultiPage- Editors sowie des AAXS. Diese sind zu einem kleinen Teil dadurch bedingt, dass die Applikation als Plug-in für die bestehende Entwicklungsumgebung Eclipse entwickelt wurde und so gewisse Funktionen, wie speziell das selektive Abspeichern des Inhalts eines einzelnen Fensters der MultiPageEditor-Applikation, nicht so einfach realisiert werden können. Zum weitaus größeren Teil sind diese Einschränkungen aber durch den Einsatz diverse externer Bibliotheken entstanden, als auffällige Punkte genannt seien die Einschränkung bei den beispielhaften Quell- und Ergebnisdo-

61 6. Algorithmus für XSLT-Templates 52 Abbildung 6.2: Prioritätensystem. kumenten sowie die nur teilweise funktionierende Angabe einer Dokumenttypdefinition Format Quell- und Ergebnisdokument Sowohl für das beispielhafte Quelldokument als auch für das beispielhafte Ergebnisdokument gilt: Es müssen wohlgeformte XML-Dateien sein. Für das Quelldokument entsteht diese Anforderung bereits dadurch, dass es in Schritt 5 benützt wird, um durch eine XSL-Transformation direkt in der Applikation die zuvor erstellten XSLT-Templates zu testen und der verwendete Xalan-XSLT-Prozessor dies voraussetzt. An sich kann ein XSLT-Prozessor XML-Dokumente auch in Nicht-XML- Dokumente wandeln, wodurch die Forderung nach einem wohlgeformtem Beispiel-Ergebnisdokument auch nicht begründet wird. Jedoch werden beide Dokumente am Anfang geparst, um den verschiedenen Matching-Methoden einen DOM-Baum der XML-Dokumente zur Verfügung zu stellen. Der verwendete JAXP-XML-Parser verlangt aber, verständlicherweise ein wohlgeformtes XML-Dokument. Es wäre zwar durchaus möglich einzelne Matching-Methoden (wie das Content-Matching, vgl. Abschnitt 6.3.2) alleine durchzuführen, da diese abgewandelt werden könnten, um nicht zwingend einen DOM-Baum zu benötigen, jedoch wären die Ergebnisse des Matchings wohl nur mangelhaft. Durch alleinige Verwendung dieser Matching-Methode wäre es auch nicht möglich, Strukturen im Ergebnisdokument ausfindig zu machen, sondern die generierten Templates wären auf reine Element-Ersetzung reduziert.