3.6.1  SOAP.  37

3.6.2  XML-RPC.  37

3.6.2.1  XML-RPC: Server-Implementierung.  37

3.6.2.2  XML-RPC: Client-Implementierung.  38

3.7  XML-Daten transformieren.  38

3.7.1  XML-Daten mit CSS formatieren.  39

3.7.2  XSLT.  39

3.7.2.1  XSLT-Prozessoren.  39

3.7.2.2  Grundlegende Syntax-Elemente.  40

3.7.2.3  Abfragen.  41

3.7.2.4  Weitere XSLT-Funktionen.  42

3.7.2.5  Formatting Objects (XSL-FO)  43

3.7.2.6  XSLT-Beispiel anhand des TAZ-Corpus.  44

4.  Weitere Spezifikationen des W3C.  46

4.1  XML-Elemente mit xml:id indizieren.  46

4.2  Binären Daten Media-Typen zuweisen.  46

4.3  SMIL - Synchronized Multimedia Integration Language.  47

4.4  Scalable Vector Graphics.  47

4.4.1  Grundlegende SVG-Elemente.  48

4.4.2  Weitere SVG-Elemente.  50

4.4.3  Transformationen.  50

5.  XML-Datenbanken.  51

5.1  Das relationale Datenmodell versus XML.  51

5.2  OpenSource XML-Datenbanken.  51

5.3  Die XML-Datenbank eXist.  53

5.3.1  Installation von eXist.  53

5.3.2  XML-Workflow in eXist.  53

5.3.3  Das TAZ-Corpus in der eXist-Datenbank.  54

5.3.4  Deutsch-Englisches Wörterbuch.  54

5.4  Beipielanwendung (Perl): Validieren des Zipfschen Gesetzes anhand des TAZ-Corpus.  

   55

5.4.1  Programmlauf.  56

6.  Weitere Tools zum Bearbeiten von XML-Daten.  58

6.1  XML-Editoren.  58

6.1.1  Kommerzielle Produkte.  58

6.1.2  OpenSource-Produkte.  59

6.1.3  Übersicht.  59

6.2  Weitere Perl-Module zur Verarbeitung von XML-Daten.  59

6.2.1  XML::Simple.  59

6.2.2  XML::XPath.  60

7.  XML-Bearbeitung in weiteren Programmiersprachen.  61

8.  Schlussbemerkungen.  62

Quellenangaben.   64

Literaturangaben.   64

WWW  -Adressen.  64

- 2 -

1. Einleitung

Seitdem es elektronisch gespeicherte Daten gibt, existiert das Problem der unterschiedlichen Datenformate: Die Frage nach der Art und Weise, wie die Daten gespeichert werden. Programme unterschiedlicher Hersteller, die alle einem ähnlichen Zweck dienen, benutzen dennoch zueinander nicht kompatible Datenformate. So kann es vorkommen, dass eine Textverarbeitung die Dokumente einer anderen Textverarbeitung nicht oder nur mehr schlecht als recht lesen kann. Ältere Dokumente können nicht mehr verarbeitet werden, wenn es die sie erzeugenden Programme nicht mehr gibt oder diese auf aktuellen Computer-Plattformen nicht mehr laufen. Verschärfend kommt hinzu, dass auch die verwendeten Speichermedien einer rasanten Entwicklung unterliegenheute noch auf dem aktuellsten Stand der Technik, in wenigen Jahren schon wieder veraltet und mit den dann gängigen Geräten nicht mehr lesbar.

Liesse sich letzteres Problem noch durch das ständige Umkopieren auf neue Datenträger lösen, so bleibt doch weiterhin das Problem der verschiedenen Datenformate bestehen. In der Quantitativen Linguistik werden grosse Datenbestände in Form von Text-Corpora benötigt. Diese liegen zumeist als ASCII-Dateien ¹ vor: In dieser Form sind sie zumindest für Menschen direkt lesbar. Allerdings enthalten die Corpora unterschiedlichste linguistische Informationen und sind dementsprechend unterschiedlich strukturiert. In der Praxis bedeutet dies dass Programme, Schnittstellen etc., die für das eine Corpus erstellt wurden, nur mit erheblichen Anpassungs-Aufwand auf andere Corpora angewandt werden können.

In dieser Arbeit soll versucht werden aufzuzeigen, dass es eine Alternative gibt: Mittels der „Extensible Markup Language“, kurz XML, liesse sich ein einheitlicher Workflow für die verschiedensten Corpora erstellen.

1 Zur Geschichte der ASCII-Definition: http://de.wikipedia.org/wiki/ASCII

- 3 -

1.2 Schreibweisen

Für den Fliesstext in dieser Arbeit wird die Schriftart Times New Roman in 12 pt Schriftgrösse benutzt. Davon unterscheiden sich Beispiele und Auszüge in Programmiercode oder XML durch die Schriftart Courier New.

Blöcke von Beispielcode werden zusätzlich eingerückt: Hallo Welt!

Auf der dieser Arbeit beiliegenden CD befindlichen Dateien verweist ein Ordner-Symbol in der entsprechenden Fussnote:

Sofern keine weiteren Angaben folgen bzw. das Kapitel endet beziehen sich alle folgenden Code-Beispiele auf diese Datei.

1.3 Verwendete Software

Alle in dieser Arbeit beschriebenen Programme wurden unter Suse Linux 9.1 Personal Edition erstellt ² . Um diese kompilieren zu können, sind in fast jedem Fall weitere Software, die nicht im Umfang der Suse-Distribution enthalten ist, notwendig.

Die benutzten Module, Bibliotheken etc. liegen ausschliesslich als OpenSource bzw. zumindest kostenloser Software vor. Abhängig vom Installations-Umfang sind auf anderen Linux-/Unix-Distributionen u.U. schon einige vorhanden, andere müssen nachinstalliert werden. Prinzipiell steht auch einer Installation unter Windows nichts im Wege.

1.3.1 Java

Um die bereits kompilierten Java-Klassen der beschriebenen Programme auszuführen, genügt ein installiertes „Java Runtime Environment (JRE)“ ³ . Zum erneuten Kompilieren ist das „Java Development Kit (JDK)“ notwendig ⁴ . Java sollte mindestens in der Version 1.4 vorliegen.

1.3.2 Perl

Auf dem Referenz-System befand sich die Perl-Version 5.8.3. Die verwendeten Perl-Module

2 ftp.suse.com/pub/suse/i386/9.1-personal-iso

3 http://www.java.com:80/en/download/manual.jsp

4 http://java.sun.com/j2se/1.5.0/download.jsp

- 4 -

befinden sich alle auf dem „Comprehensive Perl Archive Network CPAN)“ ⁵ und können von dort heruntergeladen und installiert werden.

Die meisten Unix-Distributionen enthalten bereits ein installiertes Perl. Wenn nicht, kann es ebenfalls vom CPAN bezogen werden ⁶ .

Unter Windows bietet sich die ActivePerl-Distribution von ActiveState ⁷ an. Hierbei handelt es sich um ein fertig kompiliertes Perl, welches bereits zahlreiche nützliche Module enthält.

5 http://www.cpan.org

6 http://www.cpan.org/src/README.html

7 http://www.activestate.com/Products/ActivePerl/

- 5 -

2. Die „Extensible Markup Language“ (XML)

2.1 XML - ein offener Standard

Am 10. Februar 1998 veröffentlichte das „Worl Wide Web Consortium ⁸ “ (kurz: W3C) die Version 1.0 seines Vorschlags zu einer „Extensible Markup Language“ ⁹ . In der Zusammenfassung heisst es:

Its goal is to enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML. XML has been designed for ease of implementation and for interoperability with both SGML and HTML.

Hieraus wird ersichtlich, dass XML vornehmlich für den Datenaustausch im Internet gedacht war und die Eigenschaften von HTML und SGML ¹⁰ kombinieren sollte. In der Praxis resultierte hieraus die XHTML-Spezifikation ¹¹ : Diese stellt eine Neudefinition des HTML - 4.0 - Standards in Form von XML dar. Zwar besitzt XHTML nicht die grosse Flexibilität des eigentlichen XML-Standards, die syntaktisch wesentlich strengeren Regeln erleichtern aber z.B. das Parsen gegenüber HTML 4.0 ¹² .

Mittlerweile haben die großen Einsatzmöglichkeiten und die offene Verfügbarkeit des XML-Standards dafür gesorgt, dass XML auch in den verschiedensten Bereichen ausserhalb des Webs zum Einsatz kommt. Überall dort, wo offene Standards wichtig erscheinen und reger Datenaustausch herrscht, kann XML zum Einsatz kommen. Einige Beispiele hierfür wären:

• Die Büro-Software OpenOffice ¹³ und das daraus abgeleitete kommerzielle StarOffice ¹⁴ benutzen XML als Format für alle Dokumententypen (Textverarbeitung, Tabellenkalkulation, Präsentation und Vector-Graphik)

• SCORM, das „Sharable Content Object Reference Model“ ermöglicht den Austausch von Daten zwischen eLearning-Plattformen 15

• Mittels der „XML User Interface Language“ (kurz: XUL) des Mozilla-Projekts lassen sich

8 http://www.w3c.org

9 http://www.w3c.org/TR/1998/REC-xml-19980210 - Mittlerweile ist die dritte Edition der Spezifikation vom 4. Februar 2004 aktuell: http://www.w3.org/TR/2004/REC-xml-20040204/

10 http://www.isgmlug.org/sgmlhelp/g-index.htm

11 http://www.w3.org/TR/xhtml1/

12 http://www.w3.org/TR/xhtml1/#diffs

13 http://www.openoffice.org/

14 http://de.sun.com/Produkte/software/star/staroffice/index.jsp

15 http://www.adlnet.org/index.cfm?fuseaction=scormabt

- 6 -

Programme mit graphischer Benutzeroberfläche entwickeln ¹⁶ .

Die verschiedensten Arten von Daten können mittels XML repräsentiert und verarbeitet werden. Jedoch ist XML nicht für alle Datentypen gleich gut geeignet: Pixelbilder, Audio- und Video-Daten dürften sich nur schwerlich in XML darstellen lassen. Hierbei handelt es sich meistens um sehr große binäre Datenmengen, die durch ein XML-Gerüst noch unnötig weiter aufgebläht werden würden. Eine eigene Arbeitsgruppe kümmert sich beim W3C um die Frage, wann das Einbetten binärer Daten in XML Sinn machen würde ¹⁷ .

2.2 XML - Syntax

Als echte Untermenge ¹⁸ von SGML hält sich XML an deren syntaktische Vorgaben. So beginnt jedes XML-Document mit der Angabe des Dokumententyps und der Version:

Optional können hier in weiteren Attributen Angaben zu verwendeten Zeichensätzen, Sprache des Dokuments etc. gemacht werden.

Alle Daten eines XML-Dokuments werden in „Tags“ eingeschlossen. Jedes Tag umschliesst einen Daten-Bereich und muss nach diesem explizit geschlossen werden. Name und eventuelle Attribute des Tags werden in spitzen Klammern eingeschlossen:

Anschliessend folgen die Daten des so deklarierten Bereichs und die Schliessung des Tags:

Letztere erfolgt durch Setzen eines / („Slash“) nach der öffnenden spitzen Klammer, gefolgt von dem Namen des zu schliessenden Tags.

Öffnende und schliessenden Angabe sowie der Datenbereich zusammen ergeben ein Element. Jedes XML-Dokument benötigt mindestens ein sogenanntes Root-Element. Dieses muss alle anderen Elemente des Dokuments umschliessen, kann aber auch das einzige Element eines XML-Dokuments darstellen.

Ein einfaches, wohlgeformtes XML-Dokument könnte so aussehen ¹⁹ :

16 http://www.mozilla.org/projects/xul/

17 http://www.w3c.org/XML/Binary/

18 http://www.w3.org/TR/1998/REC-xml-19980210#sec-intro: „By construction, XML documents are conforming SGML documents“

19 Datei: wohlgeformt.xml

- 7 -

Hallo Welt!

Elemente lassen sich beliebig tief ineinander verschachteln, allerdings muss hierbei auf syntaktische Korrektheit der öffnenden und schliessenden Teile der Tags geachtet werden. Nicht zulässig wäre folgendes, da tag1 vor tag2 geschlossen wird:

XML unterscheidet zwischen Gross- und Kleinschreibung, so dass ein Tag mit dem Namen nicht identisch ist mit .

In den verschiedenen Spezifikationen des W3C werden teilweise unterschiedliche Terminologien benutzt: So entspricht ein XML-Element im XPath- oder XSLT-Kontext einem Knoten.

2.3 Wohlgeformte und gültige XML-Dokumente

XML-Dokumente werden in wohlgeformte und gültige unterteilt. Wohlgeformte XML-Dokumente sind solche, die den in 2.2 beschriebenen syntaktischen Regeln folgen und nach der Header-Angabe mindestens ein Root-Element enthalten ²⁰ .

Gültige XML-Dokumente sind wohlgeformte Dokumente, die zusätzlich eine „Document Type Definition“ (kurz: DTD) oder ein XML-Schema ²¹ besitzen und die die dort beschriebene Struktur einhalten.

Von Fall zu Fall muss entschieden werden, ob wohlgeformte oder gültige XML-Dokumente erstellt werden sollen. Sowohl DTD als auch XML-Schema stellen eine Grammatik für das jeweilige XML-Dokument dar. Sie geben eine eindeutig definierte Struktur vor und ermöglichen so die Erstellung weiterer Dokumente, die die gleiche Struktur besitzen sollen. Ein gültiges XML-Dokument muss allerdings jedesmal auf seine syntaktische Übereinstimmung mit der zugrunde liegenden DTD bzw. dem XML-Schema überprüft werden. Dies bedeutet einen erheblichen Aufwand an Rechenleistung. In Anwendungen, in denen einmalig XML-Daten erstellt und diese anschliessend nur noch lesend zur Verfügung gestellt werden, würde auch ein „Zwischenszenario“ genügen: Nach der Erstellung werden die Daten einmalig auf ihre Gültigkeit gegenüber einer DTD oder XML-Schema überprüft. Nach erfolgreicher Prüfung werden sie - ohne Verweis auf DTD oder einem XML-Schema - als

20 http://www.w3.org/TR/2000/REC-xml-20001006#sec-well-formed

21 Auch bei dem später noch zu beschreibenden NG-RELAX handelt es sich um XML-Schemata

- 8 -

lediglich wohlgeformte Daten zur Verfügung gestellt.

2.4 Die Document Type Definition (DTD)

Eine DTD legt die Struktur eines XML-Dokuments fest: Welches Element darf an welcher Stelle auftauchen, wie werden Elemente geschachtelt und welchen Inhalt dürfen sie haben? Für die DTD gilt eine eigene, nicht XML-konforme Syntax. Eingeleitet wird sie durch das Schlüssel-Tag , gefolgt von einem beliebig zu wählendem Namen. Eine eckige Klammer zeigt den Beginn der Element-Definitionen an, mittels ]> wird die DTD beendet ²² . Durch das Hinzufügen einer DTD würde aus dem wohlgeformeten Dokument aus Kapitel 2.2 ein gültiges ²³ : ]> Hallo Welt!

Hier wird das einzige enthaltene Element ausgabe vom Typ #PCDATA definiert. Als #PCDATA definierte Elemente dürfen beliebig lange alphanumerische Zeichenketten enthalten. Die Datei 2.4-2.xml enthält eine etwas komplexere DTD. Hier sind in das Root-Element ausgabe zwei Elemente text geschachtelt - das Plus-Zeichen am Ende der Element-Definition erlaubt mehr als ein text-Element innerhalb ausgabe. Im Gegensatz hierzu definiert ein Fragezeichen ein optionales Element, welches nicht zwingend vorkommen muss. text-Elemente können wiederum die Elemente ueberschrift und kapitel beinhalten. Letztere enthalten alphanumerische Daten. Das Element kapitel wurde zusätzlich um das nicht-optionale Attribut nummer erweitert. Optionale Attribute werden mit #IMPLIED statt #REQUIRED gekennzeichnet.

]>

22 http://www.w3.org/TR/2000/REC-xml-20001006#dt-doctype

23 Datei: gueltig-dtd.xml

- 9 -

Attribute vom Typ CDATA können beliebigen alphanumerischen Inhalt enthalten. Im Gegensatz zu #PCDATA wird der Inhalt von CDATA nicht vom Parser auf Korrektheit überprüft. Gleichfalls sind Voreinstellungen in der DTD möglich. Eine Definition der Art

läßt nur die Werte 1, 2 und 3 für nummer zu. Ein Element kann beliebig viele Attribute besitzen. Abkürzungen, sogenannte Entities, können ebenfalls in der DTD definiert werden. Folgende Entity:

Dies sorgt dafür, dass im XML-Dokument alle Vorkommen von &autor; durch den Text „Peter Mustermann“ ersetzt werden. Wird dem Namen der Entity (in diesem Fall autor) ein „%“ vorangestellt, kann die Entity bereits im weiteren Verlauf der DTD und nicht erst im XML-Dokument angewandt werden.

Komplexere DTDs würden eine XML-Datei unnötig aufblähen. Deswegen ist es möglich, DTDs in externe Dateien auszulagern. Anschließend können sie über die DOCTYPE-Anweisung in beliebig viele XML-Dokumente eingebunden werden ²⁴ :

Bei Verwendung des Schlüsselwerts SYSTEM handelt es sich um eine DTD, die sich auf demselben Rechner wie die aufrufende XML-Datei befinden muss. Bei Verwendung von PUBLIC kann sich die DTD auch auf anderen Rechnern befinden. Dies ist sinnvoll, wenn z.B. ofizielle DTDs des W3Cs direkt von der Homepage eingebunden werden sollen ²⁵ .

24 Dateien: gueltig-dtd-extern.xml und gueltig-dtd-extern.xml

25 Seeboerger-Weichselbaum, Michael: Das Einsteigerseminar XML. Seite 91, 2. Auflage, Kaarst 2000

- 10 -

2.5 Die DTD des TAZ-Corpus

Das TAZ-Corpus wurde aus einzelnen Texten der Berliner Tageszeitung „Die Tageszeitung“ zusammengestellt. Es liegt in Form gültiger XML-Dateien vor. Die entsprechende DTD wird aus einer externen Datei eingebunden ²⁶ .

Zuerst werden die Entitys textabschnitt und satzabschnitt so definiert, dass sie auch innerhalb des weiteren Verlaufs der DTD benutzt werden können:

Das Element corpus stellt das Root-Element dar und kann beliebig viele weitere Elemente des Typs article beinhalten:

Das Element article wiederum setzt sich zusammen aus header und body:

Der header setzt sich aus einigen weiter unten definierten Elementen des Typs #PCDATA zusammen. Das mit einem * gekennzeichnete Element autor darf leer bleiben:

Der body enthält headings und den text, wobei erstere wieder leer bleiben können: headings setzen sich aus title und subtitle zusammen:

title und subtitle machen Gebrauch von der Entity satzabschnitt:

26 Datei: taz-corpus-version1.0.dtd - Im Kontext des TAZ-Corpus lautet der Dateiname der DTD lediglich „corpus.dtd“. Aus Gründen der Übersichtlichkeit wurde der Name hier erweitert

- 11 -

text enthält die in der Entity textabschnitt definierten Elemente iwp, clause, token und fnm sowie einen subtitle:

Die Elemente fnm und iwp bestehen aus Elementen vom Typ token. Letzteres ist vom Typ #PCDATA definiert. Damit ist die Hierarchie am unteren Ende angelangt:

clause expandiert zu den in satzabschnitt festgelegten Elementen:

Da in der Entity satzabschnitt wiederum das Element clause definiert ist, kann eine clause aus beliebig tief ineinander geschachtelten Elementen des Typs clause bestehen. Abschliessend bekommen die Elemente token und clause einige Attribute zugewiesen, die teilweise optional (IMPLIED) sind:

>

Zum Zeitpunkt der Erstellung dieser Arbeit war die DTD des TAZ-Corpus in der Version 1.0 nicht mehr aktuell. Es wurden weitere linguistische Strukturen hinzugefügt.

2.6 XML-Schema

Bereits die erste XML-Defintion von 1998 enthielt die Möglichkeit, XML-Dokumente nach vorgegebenen DTDs zu strukturieren ²⁷ . Seitdem haben sich die Anwendungsbereiche für XML stark vergrößert und XML-annotierte Datenbestände wurden in ihrer Struktur komplexer. Dieser gestiegenen Komplexität konnte die DTD nicht mehr gerecht werden. Ihr fehlten Eigenschaften wie ²⁸ :

27 http://www.w3.org/TR/1998/REC-xml-19980210#dt-doctype

28 Skulschus, Marco und Wiederstein, Marcus: XML Schema. Seite 12, 1. Auflage, Bonn 2004

- 12 -

• Definition neuer Datentypen und komplexer Datenstrukturen

• Aufteilung der DTD in mehrere Dokumente bzw. Kombination mehrerer separat gespeicherter Definitionen

• Wiederverwendbarkeit einzelner Definitionen oder Teile davon (komponentenbasierter Ansatz)

Diese offensichtlichen Nachteile der DTD führten 2001 zur Verabschiedung der XML-Schema-Definition ²⁹ . Bei XML-Schemata handelt es sich um eine weitere Möglichkeit, die Strukturen eines XML-Dokuments festzulegen und somit gültige Dokumente zu erzeugen.

Auf die Einführung einer neuen Syntax wurde im Gegensatz zur DTD verzichtet, so dass ein XML-Schema lediglich ein weiteres wohlgeformtes XML-Dokument darstellt. In Konkurrenz zur offiziellen XML-Schema-Definition des W3C-Konsortiums ³⁰ stehen die von Microsoft entworfene Variante BizTalk-Schema ³¹ und XDR (XML Data Reduced) - Schema ³² . Auf letztere beiden soll hier aber nicht eingegangen werden.

2.6.1 Das Instanz-Dokument 33

Zur Veranschaulichung der Syntax von XML-Schemata soll wieder das Beispiel aus Kapitel 2.4 verwendet werden, diesmal allerdings wird anstatt einer DTD ein Schema zur Strukturierung des Dokuments eingesetzt.

Wieder wird das Dokument durch Angabe der XML-Version begonnen:

In der nächsten Zeile wird das Root-Element (ausgabe) deklariert:

Dieses wurde um zwei Attribute erweitert: Das Attribut xmlns definiert den Namens-Raum („Name-Space“), aus dem die weiteren Elemente des Schemas stammen. Hier wird auf die aktuelle Schema-Instanzen ³⁴ Schema-Definition für des W3C verwiesen

(http://www.w3.org/2001/XMLSchema-instance).

29 http://www.w3.org/TR/xmlschema-0/

30 http://www.w3.org/TR/xmlschema-1/ und http://www.w3.org/TR/xmlschema-2/

31 http://www.microsoft.com/biztalk/evaluation/overview/biztalkserver.asp und http://www.infoworld.com/cgi-bin/displayStory.pl?991022.hnibmxml.htm

32 http://www.oasis-open.org/cover/XMLData-Reduced19990509.html

33 Datei: gueltig-schema.xml

34 In der Terminologie des W3C wird als „Schema-Instanz“ ein per XML-Schema validiertes XML-Dokument bezeichnet

- 13 -