programmierung von xml-basierten anwendungen unter ... · v zum geleit innerhalb der letzten 10...

Aus dem Institut für Informationssystemeder Universität zu Lübeck

Direktor:Prof. Dr. rer. nat. Volker Linnemann

Programmierung von XML-basiertenAnwendungen unter Berücksichtigung der

Sprachbeschreibung

Dissertationzur

Erlangung der Doktorwürdeder Universität zu Lübeck

– Aus der Technisch-Naturwissenschaftlichen Fakultät –

Vorgelegt vonSascha Martin Kempa

aus Berlin – Frohnau

Lübeck, Juli 2003

v

Zum Geleit

Innerhalb der letzten 10 Jahre hat das World-Wide Web eine beispiellose Entwicklung zu einemweltweiten Informationssystem vollzogen. Es ist aus vielen Bereichen nicht mehr wegzudenkenund hat die tägliche Arbeit wesentlich verändert. Wichtige Informationen müssen nicht mehrmühsam telefonisch, per Email oder per Post angefordert werden, sondern können direkt inter-aktiv am Bildschirm abgefragt werden. Suchmaschinen erlauben das Auffinden der für die eigeneArbeit wichtigen Informationen.

Zur internen Darstellung von WWW-Seiten in Textform hat sich die Sprache HTML (HypertextMarkup Language) als Standard durchgesetzt. XML (Extensible Markup Language) als Verall-gemeinerung von HTML spielt in zunehmendem Maße eine Rolle als Datenaustauschformat undzur Datenmodellierung.

Um WWW-Seiten schnell und übersichtlich zu entwerfen, werden geeignete Werkzeuge benö-tigt. Dies gilt insbesondere bei neueren Anwendungen, bei denen WWW-Seiten nicht statischsind, sondern dynamisch bei jeder Anforderung durch einen Benutzer neu erzeugt werden. Bei-spiele sind Seiten für Börsenkurse oder für Wetterdaten. Diesen Anwendungen ist es gemeinsam,dass der Inhalt einer Webseite sich aus aktuellen, häufig veränderlichen Daten ergibt und daherad hoc dynamisch erzeugt werden muss.

Die heute in der Praxis eingesetzten Werkzeuge für dynamische Web-Seiten sind unzureichend,da die Gültigkeit der generierten Seiten, d.h. die Korrektheit gemäß einer Sprachbeschreibung, imAllgemeinen nicht statisch am Generierungsprogramm abgelesen werden kann, sondern durchdynamische Testläufe überprüft werden muss. Dies gilt sowohl für HTML-Seiten als auch fürXML-Dokumente. Wichtige Vertreter dieser Werkzeuge sind JAVA Servlets und JAVA ServerPages.

Hier setzt die Arbeit von Martin Kempa an. Es wird in der Arbeit die Sprache XOBE (XMLOBJEKTE) als Erweiterung der im WWW-Kontext inzwischen sehr weit verbreiteten objektori-entierten Programmiersprache JAVA entwickelt. XOBE erlaubt eine einfache Implementierungvon Anwendungen zur Generierung von XML-Dokumenten. HTML ist hierbei in der Form desXML-konformen XHTML ein wichtiger Spezialfall.

In XOBE wird die Gültigkeit der durch ein Programm generierbaren XML-Dokumente wei-testgehend statisch garantiert. Dies geschieht dadurch, dass eine Sprachbeschreibung für XML-Dokumente, formuliert in XML Schema, direkt zur Typisierung verwendet wird. XML-Kon-struktoren erlauben die Generierung neuer XML-Dokumentteile aus bereits vorher generiertenDokumentteilen. Hierdurch kann gewährleistet werden, dass ein XML-Konstruktor nur XML-Dokumentteile erzeugen kann, die dem zugrunde liegenden XML Schema in der Struktur ent-sprechen.

Für die Analyse der XML-Konstruktoren wird in der Arbeit ein geeignetes Typsystem formalentwickelt. Zur Typüberprüfung werden die aus der Literatur bekannten Heckengrammatiken(hedge grammars) herangezogen. Heckengrammatiken eignen sich in besonderer Weise zur Mo-

vi

dellierung von XML-Sprachbeschreibungen. Der Algorithmus zur Typüberprüfung stellt eine Er-weiterung und Modifizierung eines von Antimirov entwickelten Algorithmus zur Überprüfungvon Ungleichungen von regulären Ausdrücken dar.

Zur Analyse und Traversierung von XML-Objekten verwendet die Arbeit die Sprache XPATH.Auch hier wird die Typinferenz formal definiert.

Die formal beschriebenen Algorithmen wurden implementiert und die Sprache XOBE im Rah-men eines Präprozessors für JAVA implementiert. Zwei Beispielanwendungen, nämlich die WML-Anbindung eines Medienarchivs und eine Übungsdatenverwaltung zeigen, wie man mit XOBEprogrammiert und wie die statische Korrektheit von generierten XML Strukturen gewährleistetwerden kann.

Die Arbeit von Martin Kempa zeigt in hervorragender Weise, wie das praktische Problem dergültigen XML-Dokumente gelöst und durch Einsatz einer entsprechenden Theorie untermauertwerden kann. Die Arbeit leistet einen herausragenden Beitrag zur sicheren Programmierung vonWeb-Anwendungen. Dies ist von besonderer Bedeutung angesichts der stürmischen und teilwei-se wenig systematischen Entwicklung im Bereich der Web-Programmierung.

Lübeck, im September 2003 Volker Linnemann

vii

Danksagungen

Diese Arbeit ist das Resultat mehrerer langwieriger Forschungsphasen meiner gut fünf Jahre lan-gen Tätigkeit als wissenschaftlicher Mitarbeiter am Institut für Informationssysteme der Univer-sität zu Lübeck. Ausgehend von der Themensuche und der Einarbeitung in die Problemstellung,über die Erarbeitung von Lösungsideen und der Implementierung von Prototypen, bis hin zumZusammenschreiben der Dissertation und dem Korrekturlesen habe ich vielfältige Unterstützungerfahren. An dieser Stelle möchte ich mich bei allen Beteiligten dafür bedanken.

Mein besonderer Dank gilt zunächst meinem Betreuer Prof. Dr. Volker Linnemann, in dessenArbeitsgruppe diese Arbeit entstanden ist. Mit vielen inhaltlichen Diskussionen, Anregungen undEinwänden hat er meine Forschungsarbeit stets wohlwollend, aber inhaltlich kritisch begleitet.Herrn Prof. Dr. Walter Dosch danke ich für die Übernahme des zweiten Gutachtens, das miteinem nicht unerheblichen Arbeitsaufwand verbunden ist. Bei Prof. Dr. Jürgen Prestin möchteich mich ebenfalls bedanken, der so freundlich war, den Vorsitz in der Prüfungskommission zuübernehmen.

Für anregende Diskussionen zum Inhalt der Arbeit geht mein Dank an meine Kollegen BedaChristoph Hammerschmidt und Sönke Magnussen. Für viele Verbesserungsvorschläge nach mü-hevoller Korrekturlesung gebührt der Dank Angela König, Henrike Schuhart und Torben Spieg-ler.

Abschließend möchte ich mich noch bei meiner Frau Susanne bedanken, ohne deren Rückhalt inallen weiteren Belangen des Lebens diese Arbeit nicht möglich gewesen wäre.

Lübeck, Juli 2003 S. Martin Kempa

ix

Zusammenfassung

Die Kommunikation über das World-Wide Web mit Benutzern, seien es menschliche Anwenderoder entfernt arbeitende Programme, wird in zunehmendem Maße zum integralen Bestandteilmoderner Informationssysteme. Mit der Extensible-Markup-Language (XML) ist für den Aus-tausch von Informationen über das Internet ein einheitliches Datenformat standardisiert worden,auf dessen Grundlage spezielle Auszeichnungssprachen für unterschiedliche Anwendungsgebie-te definiert werden können. Heutige Web-Anwendungen zeichnen sich dadurch aus, dass sie ingroßem Umfang Dokumente einzelner Auszeichnungssprachen verarbeiten und dynamisch – al-so zur Laufzeit des Programmes – erzeugen. Die Implementierung dieser Web-Anwendungenerfolgt dabei in der Regel mit Werkzeugen, die die Korrektheit der erzeugten Dokumente nichtsicherstellen, was zusätzliche Testläufe notwendig macht. Es ist deshalb wünschenswert, eineProgrammiersprache zur Verfügung zu haben, die die Kenntnis über die in einer Anwendungverwendeten Auszeichnungssprache nutzt, um fehlerfreie Anwendungen zu entwickeln.

In dieser Arbeit wird die Sprache XOBE (XML-Objekte), eine Erweiterung der objektorientier-ten Programmiersprache Java, vorgestellt, die eine einfache Implementierung von XML-basiertenAnwendungen erlaubt. XML-Fragmente können dabei nach Deklaration der Sprachbeschreibungeiner XML-Auszeichnungssprache im Programm als Instanzen von XML-Objekt-Klassen wieeingebaute Datentypen eingesetzt werden. Durch neu eingeführte Sprachkonstrukte ist es mög-lich, XML-Objekte zu erzeugen und Informationen oder Teile aus diesen zu selektieren. DerVorteil der weitestgehenden Überprüfung der Gültigkeit für dynamisch erzeugte XML-Fragmen-te zum Zeitpunkt der Programmübersetzung wird bei diesem Ansatz im Gegensatz zu anderenErweiterungen sichergestellt.

Die Analyse der Gültigkeit von XOBE-Programmen erfolgt mit dem auf XML-Typen zugeschnit-tenen Typsystem. Durch die aus der Literatur bekannten Heckengrammatiken ist es möglich, diedurch die Sprachbeschreibung festgelegten XML-Typen, die im XOBE-Programm genutzt wer-den, zu formalisieren. Auf dieser Basis kommt zur Überprüfung einzelner Programmanweisun-gen ein neu entwickelter Subtyp-Algorithmus zum Einsatz. Die prototypische Implementierungder XOBE-Spracherweiterung, die als Präprozessor realisiert wurde, transformiert den XOBE-Quelltext in reines Java. Zur Repräsentation der XML-Objekte wird dabei der Schnittstellenstan-dard Dokument-Objektmodell (DOM) eingesetzt.

Die Programmiersprache XOBE ist besonders gut geeignet, Web-Anwendungen und Web-Ser-vices zu erstellen, die über das Internet zugreifbar sind. Dies wurde im Rahmen dieser Arbeitdurch die Implementierung zweier prototypischer Web-Anwendungen bestätigt, die zusätzlichzeigen, dass mit XOBE Quelltexte entstehen, die im Vergleich zu Alternativen verständlicherund leichter zu warten sind. Damit leistet die Arbeit einen wichtigen Beitrag für die strukturierteEntwicklung korrekter XML-basierter Anwendungsprogramme.

Inhaltsverzeichnis

1 Einführung 1

1.1 Motivation für statische Typüberprüfung . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Zielsetzung und Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Grundlagen und verwandte Arbeiten 9

2.1 Extensible-Markup-Language . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.1 Dokumenttypen für Auszeichnungssprachen . . . . . . . . . . . . . . . 13

2.1.2 XML -Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2 XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3 Dokument-Objektmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.3.1 Formalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.3.2 Schnittstellen und deren Semantik . . . . . . . . . . . . . . . . . . . . . 27

2.3.3 Implementierungen und Erweiterungen . . . . . . . . . . . . . . . . . . 39

2.4 Verarbeitung syntaktischer Strukturen . . . . . . . . . . . . . . . . . . . . . . . 40

2.5 Web-Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.5.1 Das Internet und seine Dienste . . . . . . . . . . . . . . . . . . . . . . . 41

2.5.2 Präsentation von statischen Dokumenten . . . . . . . . . . . . . . . . . 43

2.5.3 Dynamisierung des Webs auf der Client-Seite . . . . . . . . . . . . . . . 45

2.5.4 Dynamisierung des Webs auf der Server-Seite . . . . . . . . . . . . . . . 47

2.5.5 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

2.6 Verarbeitung und Repräsentation von XML . . . . . . . . . . . . . . . . . . . . 51

xii INHALTSVERZEICHNIS

2.6.1 Verarbeitung von XML als Zeichenkette . . . . . . . . . . . . . . . . . . 51

2.6.2 Einfache Objektmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . 52

2.6.3 Höhere Objektmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

2.6.4 Garantie der statischen Gültigkeit . . . . . . . . . . . . . . . . . . . . . 54

2.6.5 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

2.7 Einordnung dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3 XML-Objekte 59

3.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.2 Syntax und Semantik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.2.1 Objektmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.2.2 Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.2.3 Deklaration von Variablen . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.2.4 Konstruktoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

3.2.5 Elementliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

3.2.6 Selektion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

3.3 Anwendungsbeispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.4 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4 Ein Typsystem für XOBE 73

4.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4.2 Formalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.3 XML-Schema als Heckengrammatik . . . . . . . . . . . . . . . . . . . . . . . . 83

4.4 Typinferenz für XML-Konstruktoren . . . . . . . . . . . . . . . . . . . . . . . . 89

4.5 Typinferenz für XPath-Ausdrücke . . . . . . . . . . . . . . . . . . . . . . . . . 91

4.6 Algorithmus zur Typüberprüfung . . . . . . . . . . . . . . . . . . . . . . . . . . 100

4.7 Korrektheit des Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

4.7.1 Korrektheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

INHALTSVERZEICHNIS xiii

4.7.2 Vollständigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

4.7.3 Terminierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

4.8 Erweiterungen und Vereinfachungen . . . . . . . . . . . . . . . . . . . . . . . . 117

4.8.1 Substitutionsgruppen, Typerweiterung und Typeinschränkung . . . . . . 117

4.8.2 Vereinfachungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

5 Übersetzung von XOBE-Programmen 127

5.1 Architektur des Präprozessors . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

5.2 Implementierung für XML-Objekt-Konstruktoren . . . . . . . . . . . . . . . . . 130

5.3 Implementierung der XPath-Ausdrücke . . . . . . . . . . . . . . . . . . . . . . 135

5.4 Erfahrungen und Leistungsdaten . . . . . . . . . . . . . . . . . . . . . . . . . . 144

5.4.1 Leistungsdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

5.4.2 Erweiterungen des Prototyps . . . . . . . . . . . . . . . . . . . . . . . . 146

6 Web-Anwendungen programmiert in XOBE 149

6.1 WML-Anbindung eines Medienarchivs . . . . . . . . . . . . . . . . . . . . . . 149

6.1.1 Arbeitsweise und Benutzerzugang . . . . . . . . . . . . . . . . . . . . . 150

6.1.2 Architektur und Implementierungsdetails . . . . . . . . . . . . . . . . . 152

6.2 Übungsdatenverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

6.2.1 Arbeitsweise und Benutzerzugang . . . . . . . . . . . . . . . . . . . . . 158

6.2.2 Architektur und Implementierungsdetails . . . . . . . . . . . . . . . . . 161

7 Zusammenfassung und Ausblick 167

A XML-Schema AOML 171

B Beweis von Satz 4.2 173

C Formalisierung DTD 175

D Implementierung der XPath-Achsen 177

xiv INHALTSVERZEICHNIS

Kapitel 1

Einführung

Das World-Wide Web ist seit nahezu 10 Jahren das weltumspannende Informationssystem. Miteiner unüberschaubar großen Zahl von Rechnern tragen Anbieter aus allen Bereichen der Gesell-schaft zum Informationssystem bei und eine noch viel größere Anzahl von Endanwendern nutztdas World-Wide Web täglich zur Informationsgewinnung. Die ersten Jahre des Webs waren ge-prägt von der Präsentation von Daten und Dokumenten in Form von statischen Hypertexten, dievom Anbieter für den Benutzer zur Verfügung gestellt wurden.

Populär wurden diese Systeme zu einem Zeitpunkt, als die Annahme vorherrschte, dass Ände-rungen an Dokumenten im World-Wide Web nicht oder nur selten vorgenommen werden. DieseVoraussetzung wurde mit der Zeit immer mehr abgeschwächt: Mehr und mehr Daten, die überdas Web für den Benutzer zugänglich sind, erfordern eine dynamische Anpassung der Dokumen-te oder sogar den Dialog mit dem Benutzer. Möchte ein Anbieter beispielsweise eine Seite insWeb einspeisen, die die aktuellen Börsenkurse angibt, so würde der Inhalt dieses Dokuments imVerlaufe eines Tages ständig variieren. Eine der erste Anwendungen, die einen Dialog mit demEndanwender benötigte, ist die Suchmaschine, die Anfragen nach Dokumenten mit gesuchtemInhalt im Web beantworten kann.

Die neuen Anforderungen an das World-Wide Web führten zur Entwicklung von separaten, un-abhängigen Web-Anwendungen einzelner Anbieter, die auf spezifische Aufgaben zugeschnittensind. Diese Anwendungen sind durchaus vergleichbar mit traditionellen Informationssystemen,von denen sie sich im Wesentlichen durch die Kommunikation mit dem Endbenutzer über dasWorld-Wide Web unterscheiden.

Weiterhin ist die Verknüpfung von Web-Anwendungen mit traditionellen Datenbanksystemenoder gar die Einbindung von Web-Anwendungen in eine bestehende Informationssysteminfra-struktur zu beobachten. Die Web-Anwendung dient dann als Schnittstelle zum Endbenutzer,während aus Benutzersicht das Datenbank- oder Informationssystem im Hintergrund der Anwen-dung wirkt. Viele der leistungsfähigsten Anwendungen im World-Wide Web nutzen inzwischendiese Möglichkeit. Die Web-Anwendungen der Banken ermöglichen inzwischen die Abwicklung

2 KAPITEL 1. EINFÜHRUNG

fast sämtlicher Bankgeschäfte über das World-Wide Web. Eine weitere umfangreiche Anwen-dung, die an ein bestehendes Informationssystem angebunden wurde, ist die Fahrplanauskunftder Bahn mit gleichzeitiger Einkaufsmöglichkeit der Fahrkarte.

Vergleichbar ist der aktuelle Stand der Programmierung von Web-Anwendungen mit den An-fangstagen des Einsatzes elektronischer Datenverarbeitung, in denen Programme ausschließlichvon wenigen Spezialisten erstellt werden konnten: Eine Vielzahl unterschiedlicher Werkzeugeund Technologien sind notwendig, um eine leistungsfähige Web-Anwendung zu erstellen. Teil-weise muss für ähnliche Aufgaben, abhängig davon, ob diese auf dem Rechner des Anbietersoder dem Rechner des Anwenders ausgeführt werden, auf unterschiedliche Programmierspra-chen und -techniken zurückgegriffen werden.

In Zukunft soll die Idee der modularen Softwarekomponenten in Web-Anwendungen einfließen.Anstelle von eigenständigen, monolithischen Programmen soll dann eine Web-Anwendung auseiner Vielzahl kleiner, unabhängiger Softwarebausteine bestehen, die über das World-Wide Webhinweg austauschbar sind. Diese Web-Services werden dafür im Web zentral registriert und kön-nen anschließend bei Bedarf von anderen Web-Anwendungen eingesetzt werden.

Als Fernziel der Entwicklung von Web-Anwendungen ist wohl der persönliche, virtuelle Rechnerim Web zu nennen. Jeder Benutzer hat dann auf einer von ihm frei wählbaren Oberfläche allefür ihn relevanten Anwendungen jederzeit und überall verfügbar. Einen ersten Schritt in dieseRichtung stellen die omnipräsenten Emaildienste im Web dar, über die von jedem ans World-Wide Web angeschlossenen Rechner die persönliche Email gelesen und verschickt werden kann.

1.1 Motivation für statische Typüberprüfung

Von den erwähnten Fortschritten im Bereich der Web-Anwendungen sind alle Komponenten,aus denen ein solches System besteht, betroffen: Die Verwaltung der Daten in einem Daten-banksystem ist ebenso zu überdenken wie die Kommunikation zwischen den Anbietern und demEndbenutzer. Gleiches gilt für die Programmarchitektur und insbesondere für die Programmier-sprachen zum Implementieren der Anwendungen. Die Anpassung von Programmiersprachen aufdie neuen Erfordernisse von Web-Anwendungen bilden den Schwerpunkt dieser Arbeit.

Die Entwicklung der Web-Anwendungen beschleunigte die Etablierung des Datenformats Ex-tensible-Markup-Language (XML) zum Standard für das World-Wide Web. Da es sich bei XML

um ein universelles Datenbeschreibungsformat handelt, war es möglich, auf der Basis von XML

verschiedene Auszeichnungssprachen für die unterschiedlichsten Anwendungsgebiete zu defi-nieren, die von der Präsentation von Dokumenten im Web bis zum simplen Austausch vonGeschäftsdaten reichen. Standardisierungsgremien treiben den Entwicklungsprozess von XML-basierten Standards intensiv voran: So wurden bereits eine Sprache für Verweise, eine Selek-tionssprache und eine Transformationssprache für XML standardisiert; gearbeitet wird zur Zeitunter anderem an einer Anfragesprache für XML-Datenbanksysteme. Ähnlich rasant verläuft der

1.1. MOTIVATION FÜR STATISCHE TYPÜBERPRÜFUNG 3

Prozess bei den Softwareherstellern, die versuchen, ihre aktuellen Produkte um Zugriffsmöglich-keiten über XML zu erweitern oder neue XML-spezifische Werkzeuge anzubieten.

Moderne Web-Anwendungen und Web-Services erzeugen im großen Maße XML-Dokumentedynamisch. Der Inhalt dieser Dokumente wird im Vergleich zu den traditionellen, statischenWeb-Seiten, die für alle Benutzer zu jedem Zeitpunkt gleich sind, erst zur Laufzeit der Web-An-wendung erzeugt. Die Implementierungen dieser Web-Anwendungen und Web-Services erfolgtheutzutage durch den Einsatz von Standard-Programmiersprachen wie Java oder Visual Basic.Diese werden von den Softwareherstellern mit zusätzlichen Technologien ausgestattet, die dieProgrammiersprachen um Fähigkeiten zur einfacheren dynamischen Erzeugung von XML-Do-kumenten erweitern.

Der Einsatz dieser Technologien garantiert die Korrektheit der dynamisch generierten Dokumen-te nicht oder nur bis zu einem sehr begrenzten Grad. Für das erzeugte XML wird in der Regelnur sichergestellt, dass es wohlgeformt ist, es sich also wirklich um ein XML-Dokument handelt.Dies war in Zeiten, in denen die Datenbestände des World-Wide Web fast ausschließlich statischeDokumente umfasste, auch sinnvoll und ausreichend. Da aber moderne Web-Anwendungen imgroßen Umfang XML-Dokumente bestimmter Auszeichnungssprachen erzeugen, ist festzustel-len, dass diese Technologien den daraus erwachsenden neuen Anforderungen nicht mehr gerechtwerden. Es reicht also nicht nur aus, zu überprüfen, ob es sich bei der generierten Struktur umein XML-Dokument handelt, vielmehr muss auch garantiert werden, dass das Dokument zu einerdefinierten Auszeichnungssprache gehört, also gültig ist. Diese Eigenschaft der Gültigkeit mussbei den verfügbaren Technologien aber für jede Web-Anwendung durch aufwendige Testläufenachgeprüft werden.

Um das genaue Problem der Generierung von gültigen XML-Dokumenten zu illustrieren, sei alsBeispiel die Erzeugung einer Begrüßung genannt. Mit dem Einsatz der Technologie JavaServer-Pages (JSP) lautet ein solches Programm wie folgt:

<html ><head >< t i t l e >A Simple S e r v e r Page </ t i t l e > </ head ><body><% i f ( C a l e n d a r . g e t I n s t a n c e ( ) . g e t ( C a l e n d a r .AM_PM) = =

C a l e n d a r .AM) { % ><ul >< l i >Good Morning </ l i > </ ul >

<% } e l s e { % ><ul >< l i >Good A f t e r n o o n </ l i > </ ul >

<% } %></ body>

</ html >

Abhängig von der aktuellen Uhrzeit erzeugt diese simple Web-Anwendung ein Dokument mitunterschiedlichen Begrüßungstexten für den Vor- und Nachmittag. Der Interpreter für JSP akzep-tiert dieses korrekte Programm. Die beiden durch das Programm generierten XML-Dokumentesind ebenfalls gültig gemäß der verwendeten Auszeichnungssprache.

Angenommen der Programmierer hätte nun vergessen, den Begrüßungstext in das XML-Ele-ment li einzufügen, ergibt sich der folgende Quelltext:

<html ><head >< t i t l e >A Simple S e r v e r Page </ t i t l e > </ head ><body><% i f ( C a l e n d a r . g e t I n s t a n c e ( ) . g e t ( C a l e n d a r .AM_PM) = =

C a l e n d a r .AM) { % ><ul >Good Morning </ ul >

<% } e l s e { % ><ul >Good A f t e r n o o n </ ul >

<% } %></ body>

</ html >

In diesem Fall würde der JSP-Interpreter erneut das Programm als korrekt akzeptieren, obwohlzur Laufzeit XML-Dokumente erzeugt werden, die ungültig sind, denn innerhalb eines Elementsmit dem Namen ul muss für die gezeigte Auszeichnungssprache XHTML mindestens ein li-Element folgen. Fehler dieser Art sind offensichtlich schon frühzeitig erkennbar. Es wird da-mit deutlich, dass die Korrektheit der erzeugten XML-Dokumente mit JSP nicht in dem Maßesichergestellt wird, wie es möglich und sinnvoll wäre.

Nicht neu ist das Anliegen nach der Unterstützung von XML durch eine Programmiersprache:XML-Dokumente sollen in einer Programmiersprache nicht nur auf einfache Weise generiertwerden können, sondern sollten gleichzeitig die Eigenschaft Gültigkeit für die erzeugten Do-kumente weitgehend bereits zur Zeit der Programmübersetzung sicherstellen. Mit der Program-miersprache Java – und den bisher vorgenommenen Erweiterungen dieser Sprache – ist diesesZiel nicht erreicht worden.

Ansätze aus jüngster Zeit zur Bewältigung dieses Problems weisen indes den Nachteil auf, dassdie Gültigkeit der erzeugten Dokumente nur relativ eingeschränkt garantiert werden kann. Siegenerieren aus der Sprachbeschreibung der Auszeichnungsprache Datentypen der verwendetenProgrammiersprache, womit die Bedingungen der Auszeichnungssprache nun durch das Typsys-tem getestet werden können. Die Genauigkeit dieser Überprüfung, die zur Zeit der Programm-übersetzung abläuft, beruht nun im Wesentlichen auf den Möglichkeiten des Typsystems derProgrammiersprache und einer möglichst guten Abbildung der Bedingungen der Auszeichnungs-sprache in das Typsystem. Die meisten Abbildungen von Sprachbeschreibungen in Datentypensind allerdings mit einem Verlust von Semantik verbunden, denn einige Eigenschaften der Gül-tigkeit sind nicht oder nur mit großen Umständen durch das Typsystem einer Standard-Program-miersprache ausdrückbar. Weiterhin ist dieses Vorgehen mit einem hohen Einarbeitungsaufwandfür den Programmierer verbunden, dem sowohl die Kenntnis der Sprachbeschreibung der Aus-zeichnungssprache als auch das Wissen über die daraus erzeugten Datentypen abverlangt wird.Auch muss die Transformation für jede neue Auszeichnungssprache und für jede noch so kleineÄnderung an einer vorhandenen Sprachbeschreibung erneut durchgeführt werden.

1.2. ZIELSETZUNG UND AUFBAU DER ARBEIT 5

Zusätzlich unterschieden diese Techniken zwischen einer Repräsentation von XML-Dokumen-ten in Form von Zeichenketten und der Repräsentation durch Instanzen der aus der Sprachbe-schreibung erzeugten Datentypen, wodurch eine explizite Konvertierung zwischen diesen beidenDarstellungen erforderlich wird. Besonders umständlich wird dieser Ansatz bei der Verwendunggrößerer konstanter XML-Dokumente, die entweder auf objektorientiertem Wege sehr mühsamerzeugt werden müssen oder durch die Konvertierung einer eingelesenen Zeichenkette erstelltwerden können. Die unterschiedliche Darstellung von XML-Dokumenten ist ein ernster Bruchin dem eingesetzten objektorientierten Programmierparadigma. Wünschenswert ist deshalb ei-ne Integration von XML-Dokumenten in eine Programmiersprache, die nur eine Repräsentationvorsieht.

Aus diesen Gründen und wegen dem eingangs geschilderten Wandel von statischen Web-Do-kumenten zu komponentenbasierten Web-Anwendungen ergibt sich die Forderung nach leichtverwendbaren Programmiersprachen, die die Korrektheit der generierten XML-Dokumente be-reits zur Zeit der Programmübersetzung sicherstellen.

Java ist zur Zeit die Programmiersprache der Wahl, wenn es um die Entwicklung von Web-Anwendungen geht. Sie bietet sich daher für eine Modifikation geradezu an. Die in dieser Arbeitvorgestellte Lösung präsentiert deshalb eine objektorientierte Integration von XML-Dokumentenin die Programmiersprache Java.

1.2 Zielsetzung und Aufbau der Arbeit

In dieser Arbeit wird eine Erweiterung für die Programmiersprache Java definiert und als Präpro-zessor implementiert, die die unterschiedlichen Repräsentationen von XML-Dokumenten in Formvon Zeichenketten und durch eine Struktur von Objekten überwindet. Diese Java-Erweiterung– XML-Objekte (XOBE) – erlaubt es unter anderem erstmals mit einem erweiterten Typsys-tem die Gültigkeit der generierten XML-Dokumente bereits zur Zeit der Programmübersetzungso weit wie möglich sicherzustellen. Dabei werden die XML-Dokumente im XOBE-Programmausschließlich durch XML-Syntax notiert.

Die Ziele dieser Erweiterung sind im Einzelnen:

1. Integration von XML-Dokumenten in das objektorientierte Klassenkonzept,

2. komfortable Zugriffsmöglichkeiten auf den Inhalt dieser XML-Dokumente und

3. weitestgehende Garantie der Gültigkeit der generierten Dokumente bereits zur Zeit derProgrammübersetzung.

Das vorherige Beispiel, in dem ein XML-Dokument generiert werden soll, das einen von deraktuellen Uhrzeit abhängigen Begrüßungstext enthält, kann dann wie folgt formuliert werden:

ximport xhtml � t r a n s i t i o n a l . d t d ;

Als erstes muss im XOBE-Programm deklariert werden für welche Sprachbeschreibung XML-Dokumente verarbeitet werden, was durch das neue Schlüsselwort ximport erfolgt.

h tml welcomePage ( ) {u l p h r a s e ;

i f ( C a l e n d a r . g e t I n s t a n c e ( ) . g e t ( C a l e n d a r .AM_PM) = =C a l e n d a r .AM)

p h r a s e = < ul >< l i >Good Morning < / l i > ;e l s e

p h r a s e = < ul >< l i >Good Af te rnoon </ l i > ;

re turn < html ><head >

< t i t l e >A Simple S e r v e r Page < / t i t l e ></ head ><body >{ p h r a s e } </ body >

</ html > ;} / / welcomePage

Im Anschluss kann eine Methode definiert werden, die das XML-Dokument, ein XML-Objekt,als Resultat zurückliefert. Durch die Verwendung von XML-Syntax werden in XOBE stets XML-Objekte erzeugt, das heißt, das Generieren und Analysieren von XML geschieht konzeptuell aus-schließlich auf der Ebene von Objekten. Deshalb führt XOBE für jeden Elementtyp einer ver-einbarten Sprachbeschreibung eine eigene Klasse ein, die nach der Deklaration wie eingebauteKlassen oder atomare Datentypen benutzt werden können. Eine explizite Generierung von Java-Klassen aus der Sprachbeschreibung entfällt deshalb. Durch den Bezeichner aus der Sprachbe-schreibung wird eine solche Klasse angesprochen, wie es bei einer Variablen- oder Methodende-klaration nötig ist. XML-Objekte können wie alle Objekte in Java an Variablen zugewiesen undmanipuliert werden; zusätzlich ist ein Einfügen in den Inhalt eines neuen XML-Objekts möglich.

Mit XOBE kann die Gültigkeit für generierte XML-Dokumente weitgehend bereits zur Zeit derProgrammübersetzung sichergestellt werden. Dadurch ergeben sich für den Programmierer vonWeb-Anwendungen gegenüber der herkömmlichen Entwicklung die folgenden Vorteile:

1. XOBE-Programme sind effizienter, weil weniger dynamische Typumwandlungen und Über-prüfungen der Gültigkeit zur Laufzeit benötigt werden.

2. Ein Programm in XOBE ist zuverlässiger, da auf die Programmierung von Recovery-Pro-zeduren, die nötig sind, um Fehler bei Typumwandlungen oder Gültigkeitsüberprüfungenabzufangen, verzichtet werden kann.

1.2. ZIELSETZUNG UND AUFBAU DER ARBEIT 7

3. XOBE erlaubt eine schnellere Entwicklung von Implementierungen, weil intensive Test-läufe wegfallen, die nötig sind, um die Korrektheit der dynamisch erzeugten XML-Doku-mente plausibel zu machen.

4. Web-Anwendungen und Web-Services, die in XOBE implementiert wurden, sind besser zuwarten, da die Programmstruktur der Quelltexte einfacher und übersichtlicher gegliedertist.

Gliederung

Dieser Einführung folgt im Anschluss Kapitel 2, das die Grundlagen von Web-Anwendungendarlegt. Es beginnt dabei zunächst mit XML und den damit verbundenen Möglichkeiten zurSprachbeschreibung von Auszeichnungssprachen. Anschließend werden zwei eng mit XML ver-bundene Standards vorgestellt; XPath dient zur Selektion von Inhalten aus einem XML-Doku-ment, während das Dokument-Objektmodell (DOM) die Schnittstelle für Programmiersprachenzu XML darstellt. Auf die Verarbeitung von syntaktischen Strukturen wird anschließend eben-falls eingegangen. Das wichtigste globale Informationssystem ist mit seinen Web-Anwendungenzur Zeit das World-Wide Web, dessen Architektur mit den verschiedenen technologischen Mög-lichkeiten zur Programmierung von Web-Anwendungen in Abschnitt 2.5 erläutert wird. Dabeiwerden die wichtigsten Implementierungstechniken für Web-Anwendungen vorgestellt, die vonrein statischen Dokumenten, über eine dynamisierte Benutzerseite bis hin zu vollwertigen An-wendungen auf der Anbieterseite reichen. Den Schluss des Kapitels bildet die Einordnung dervorliegenden Arbeit in den Kontext der beschriebenen Forschungsarbeiten.

Nach den Grundlagen folgt der Schwerpunkt dieser Arbeit, der in drei Kapitel unterteilt ist: InKapitel 3 wird die Spracherweiterung XML-Objekte (XOBE) der Programmiersprache Java vor-gestellt, die es erlaubt mit XML-Dokumenten in Java auf objektorientierte Weise zu arbeiten.XML-Dokumente werden in XOBE durch XML-Objekte repräsentiert, deren Klassen durch dieDeklaration der Sprachbeschreibung der verwendeten Auszeichnungssprache automatisch be-kannt sind. Für die Erzeugung von XML-Objekten und den Zugriff auf deren Inhalt werden neueSprachkonstrukte definiert.

Kapitel 4 formalisiert das XOBE zu Grunde liegende Typsystem und stellt einen Algorithmusvor, mit dem es möglich wird, die Gültigkeit der in einem XOBE-Programm verarbeiteten XML-Objekte bereits zur Zeit der Programmübersetzung weitestgehend sicherzustellen. Es wird be-wiesen, dass der Algorithmus für das Typsystem in XOBE korrekt arbeitet und stets terminiert.

Kapitel 5 definiert die Transformation der XOBE-Programme in reine Java-Programme. Dazumüssen die XML-Objekte in Java repräsentiert werden, was in dieser Arbeit mit dem DOM ge-schieht. Zusätzlich ist eine Abbildung der neu definierten Sprachkonstrukte notwendig. Das Ka-pitel endet mit der Präsentation von ersten Messdaten der Rechenleistung des im Rahmen dieserArbeit implementierten Prototypen.


In Kapitel 6 wird die Praxistauglichkeit der vorgestellten Spracherweiterung durch die Imple-mentierung zweier Web-Anwendungen untersucht. Die Arbeit schließt mit einer Zusammenfas-sung und dem Ausblick.

Kapitel 2

Grundlagen und verwandte Arbeiten

Die Extensible-Markup-Language (XML) bietet die Möglichkeit, für die verschiedensten An-wendungsgebiete eigene Auszeichnungssprachen zu definieren. Damit ist es für unterschiedlicheAnwendungen möglich, über ein standardisiertes Datenformat systemübergreifend zu kommuni-zieren. Die Daten werden dabei in Form von Dokumenten ausgetauscht. Dokumente der gleichenArt werden zu einer Auszeichnungssprache zusammengefasst, die mittels einer Sprachbeschrei-bung definiert wird.

In diesem Kapitel werden die grundlegenden Begriffe aus dem Bereich der Extensible-Markup-Language eingeführt, die zum Verständnis der vorliegenden Arbeit notwendig sind. Für die Be-schreibung von Auszeichnungssprachen werden zusätzlich die erweiterten Konzepte von XML-Schema vorgestellt. Zudem werden die Möglichkeiten von XPath zur Selektion von Daten auseinem Dokument dargelegt, sowie der Ansatz des Dokument-Objektmodells zur Repräsentationvon XML im Programm präsentiert. Das verwandte Gebiet der Programmgenerierung ist Gegen-stand des Abschnitts 2.4.

Im Anschluß daran wird das World-Wide Web (WWW) mit seinen Grundlagen als globalesDatenhaltungssystem erläutert. Mit der Hypertext-Markup-Language ist das WWW die größteAnwendung von XML. Da es sich herausstellt, dass die statischen Präsentationsmöglichkeitenim WWW nicht den neuen Anforderungen genügen, die durch dynamisch zu erstellende Doku-mente entstehen, werden danach Ansätze vorgestellt, die die Programmierung von Web-Anwen-dungen zum Ziel haben. Diese generieren und verarbeiten vielfach XML, weshalb im AnschlussMöglichkeiten zur Repräsentation von XML behandelt werden.

Nach einer Diskussion der Vor- und Nachteile der vorgestellten Ansätze mit einer anschließendenEinordnung der vorliegenden Arbeit in diesen Kontext wird dieses Kapitel beendet.

10 KAPITEL 2. GRUNDLAGEN UND VERWANDTE ARBEITEN

2.1 Extensible-Markup-Language

Die Extensible-Markup-Language (XML) [W3C98c] ist seit 1998 eine Empfehlung des World-Wide Web-Konsortiums (W3C), das mit seinen Empfehlungen De-Facto-Standards für das World-Wide Web setzt. Die Darstellung dieses Abschnitts folgt [ABS00]. Sie ist keine umfassende Be-schreibung von XML sondern stellt den für das Verständnis dieser Arbeit nötigen Teil vor. Einevollständige Definition liegt mit der Spezifikation [W3C98c] vor; eine ausführliche Behandlungdes Themas findet sich ebenfalls in [Bra98, GP00].

Die Extensible-Markup-Language baut auf den Erfahrungen der Standard-Generalized-Markup-Language (SGML) [Gol90, Fly98] auf, einer gut 15 Jahre alten Entwicklung aus dem Bereichder Dokumentenverarbeitung, die inzwischen als ISO Standard (ISO 8879) vorliegt. Die Grund-idee dieses Vorläufers besteht darin, die logische Struktur eines Dokuments konsequent von derGestaltung für eine Präsentation des Dokuments, sei es an einem Bildschirm oder auf einemDrucker, zu trennen. Eine Anforderung, die für eine der wesentlichen Anwendungen von SGML,dem Austausch von Dokumenten im Verlagswesen, maßgeblich ist. Die Ausbreitung des World-Wide Webs und damit der Hypertext-Markup-Language (HTML), einer weiteren Anwendungvon SGML, sorgt für eine erste Verschiebung des Anwendungsgebietes vom reinen Dokumen-tenaustausches hin zum Datenaustausch. Diese Verschiebung führt schließlich zur Spezifikationvon XML als vereinfachte Variante von SGML.

Im Kern besteht XML aus nichts anderem als einer Syntax zum Austausch von Daten. Es ge-winnt erst dadurch an Bedeutung, dass diese Syntax standardisiert ist und in einer Vielzahl vonGebieten und Programmen Anwendung findet. Beispielsweise bietet XML für eine Organisationoder Benutzergruppe die Möglichkeit, den Datentransfer zu spezifizieren, um Daten zwischenverschiedenen Anwendungen auszutauschen. Durch die breite Unterstützung, die XML zur Zeiterfährt, ist es sehr wahrscheinlich, dass XML in der nahen Zukunft zum Standard für den Daten-austausch im WWW wird.

Eine der Anforderungen an XML besteht darin, dass Dokumente für den Menschen lesbar seinsollen. Aus diesem Grund wird XML textuell repräsentiert. Ihre Struktur erhalten XML-Doku-mente durch Elemente. Elemente beginnen stets mit einem Start-Tag, z. B. <book>, und endenmit einem End-Tag, beispielsweise </book>. Diese Tags werden auch Textauszeichnungen ge-nannt. Zwischen einem Start- und einem End-Tag kann textueller Inhalt, also Zeichendaten, wei-tere Elemente oder eine Mischung aus beidem stehen. Ein Element besteht somit aus dem Start-und dem End-Tag, sowie dem Text und der Struktur zwischen den beiden Tags, dem sogenanntenInhalt. Steht ein Element im Inhalt eines anderen Elements spricht man von einem Subelement.Für Elemente, deren Inhalt leer ist, existiert mit <offer/> eine abkürzende Schreibweise; Start-und End-Tags werden also in einem Tag zusammengefasst. Mit den Elementnamen innerhalb derTags und der Struktur des Inhalts werden die einzelnen Elemente in Elementtypen unterschieden.Die in einem Dokument auftretenden Elementtypen werden dabei vom Benutzer selbst definiert.

Ein weiterer Bestandteil von XML-Dokumenten sind Attribute, die den Elementen zugeordnetsind. Attribute bestehen aus einem Namen und einem Wert und werden innerhalb eines Start-

2.1. EXTENSIBLE-MARKUP-LANGUAGE 11

Tags angegeben. In dem Beispiel <price currency="EUR">wird für das Element pricedas Attribut currency auf den Wert EUR gesetzt. Analog zu den Elementtypen werden dieAttributnamen, die Werte die die Attribute annehmen können sowie die Zuordnung zu den ver-schiedenen Elementtypen als Attributtypen ebenfalls vom Benutzer definiert. Zusätzlich könnenXML-Dokumente mit Kommentar versehen werden, z. B. durch .

Damit es sich bei einem Dokument um ein XML-Dokument handelt, müssen einige Bedingun-gen erfüllt sein. Zunächst müssen alle Elemente korrekt geschachtelt sein und damit eine klam-merartigen Struktur bilden. Weiterhin müssen Attribute eindeutig sein. Das bedeutet, dass jedesAttribut in einem Element nur einmal auftreten darf. Dadurch unterscheiden sich Attribute we-sentlich von Elementen, denn im Gegensatz zu Attributen dürfen Subelemente innerhalb einesElements mehrfach vorkommen. Ein weiterer Unterschied besteht darin, dass die Werte von At-tributen keine Elemente enthalten dürfen. Sind alle angesprochenen Anforderungen erfüllt, wirdvon einem wohlgeformten Dokument gesprochen. Die Eigenschaft wohlgeformt stellt eine ziem-lich schwache Bedingung an XML-Dokumente, denn es wird lediglich sichergestellt, dass sichein eingelesenes Dokument in einer baumartigen Struktur repräsentieren lässt. Die folgende ver-einfachte Grammatik beschreibt den Aufbau von XML-Dokumenten.

Definition 2.1 (XML-Dokument)Ein XML-Dokument ist nach folgender Grammatik aufgebaut:

<Document> � <Element><Element> � <EmptyElementTag> | <STag> <Content> <ETag><STag> � "<" <Name> (<Attribute>)* ">"<Attribute> � <Name> "=" <AttValue><ETag> � "</" <Name> ">"<Content> � (<Element> | <CharData> |<Comment>)*<EmptyElementTag> � "<" <Name> (<Attribute>)* "/>"<Comment> � ""

Das Nichtterminalsymbol <AttValue> steht hier für eine Zeichenkette in einfachen (’) oder dop-pelten Hochkommata ("), <Name> für einen Elementname und <CharData> für alphanumeri-sche Zeichendaten. �

Als durchgehendes Beispiel dient in dieser Arbeit das folgende Szenario; es zeigt ein Beispielfür ein XML-Dokument.

Beispiel 2.1Eine Anwendung realisiert ein zentrales Verzeichnis antiquarischer Bücher, zu dem eine großeAnzahl von unabhängigen Antiquariaten mit ihren Angebotslisten beitragen. In dem Verzeich-nis können Benutzer der Anwendung nach Büchern suchen und erhalten Informationen über dieZustände der gefundenen Exemplare sowie über die von den Antiquariaten festgelegten Preise.Besteht ein Kaufinteresse von Seiten des Benutzers, kann er den oder die Titel in einen Ein-kaufskorb ablegen und bestellen. Die Bestellung wird von der Anwendung an das entsprechendeAntiquariat weitergeleitet, welches sich dann um die Auslieferung der Bücher kümmern muss.

Für die Übermittlung der Angebotslisten an die Anwendung haben sich die Antiquariate auf ein

Datenformat in XML geeinigt. Das folgende Dokument wurde vom St. Jürgen Antiquariat am20.2.2002 an die Anwendung übermittelt:

1 <aoml date =" 2 0 . 2 . 2 0 0 2 ">2 <ant iquary >3 <name> St . J ü r g e n A n t i q u a r i a t </name>4 <address > R a t z e b u r g e r A l l e e 4 0 , 2 3 5 6 2 Lübeck </ address >5 <email > s t . j u e r g e n a n t i q u a r i a t @ t � o n l i n e . de </ email >6 </ ant iquary >7 < o f f e r >8 <book c a t a l o g =" V a r i a ">9 < t i t l e > L o t t e i n Weimar </ t i t l e >

10 <author >Thomas Mann </ author >11 < c o n d i t i o n >Einband f i n g e r f l e c k i g , Rücken v e r b l a ß t

</ c o n d i t i o n >12 8 . 0 0 </ pr ice >13 </ book>14 <book c a t a l o g =" V a r i a ">15 < t i t l e > Buddenbrooks </ t i t l e >16 <author >Thomas Mann </ author >17 < c o n d i t i o n >Einband v e r b l i c h e n , B e s i t z e r v e r m e r k a u f

Vs . </ c o n d i t i o n >18 25 .00 </ pr ice >19 </ book>20 </ o f f e r >21 </ aoml>

Listing 2.1: Dokument in XML

Die gesamten Daten werden von dem Element aoml beinhaltet, für das das Attribut datumauf den Wert 20.2.2002 gesetzt wurde. Zunächst werden die Daten für das übermittelndeAntiquariat aufgeführt, die das Element antiquary umfasst. Neben dem Namen, im Elementname, und der Adresse des Antiquariats, im Element address, wird dessen Emailadresse, imElement email, mit übertragen. Im Element offer erfolgt anschließend die Auflistung dervom Antiquariat angebotenen Artikel.

In diesem Fall werden zwei Bücher, erkennbar an den Elementtypen book, in das zentrale Ver-zeichnis eingestellt, die durch Titel, Autor, einer Zustandsangabe und dem Preis mit den Elemen-ten title, author, condition und price beschrieben sind. Für das Element book kannman durch die Angabe des Attributs catalog bestimmen, unter welchen Rubriken das Buchim zentralen Verzeichnis auftreten soll. Im Element price wird mit dem Attribut currencyangegeben, auf welche Währung sich die Preisangabe des Elements bezieht. �


2.1.1 Dokumenttypen für Auszeichnungssprachen

Wie im vorigen Abschnitt dargestellt, ist es mit XML möglich, Dokumente oder Daten durchTextauszeichnungen zu strukturieren. In vielen Anwendungen ist es allerdings sinnvoll, Doku-mente mit gleichartiger Struktur zu einer Klasse von Dokumenten zusammenzufassen, um dieseauf ähnliche Art und Weise zu verarbeiten. Eine Klasse gleichartiger Dokumente wird als Aus-zeichnungssprache („markup language“) bezeichnet und in XML durch eine Dokumenttyp-De-finition (DTD) spezifiziert. Eine DTD abstrahiert dabei von den konkreten Dokumenten einerAuszeichnungssprache auf deren Struktur, ähnlich wie in der Theorie der Formalen Spracheneine Sprache von Wörtern durch ihre Grammatik beschrieben wird.

Wie bereits beschrieben bilden Elemente und Elementtypen das wesentliche Strukturierungsmit-tel in XML. In der DTD besteht nun die Möglichkeit, Elementtypen durch Angabe einer Dekla-ration genauer zu spezifizieren, und damit den Inhalt dieser Elemente festzulegen. Eine Element-typ-Deklaration besteht dabei aus der Zuordnung von einem regulären Ausdruck [Sal73], demsogenannten Inhaltsmodell („content model“), zu einem Elementnamen. Der reguläre Ausdruckwird mittels Operatoren über den Elementnamen der DTD gebildet und kann sogar rekursiv sein.Unterstützt werden die beiden zweistelligen Operationen reguläre Konkatenation („sequence“)(Operator: ,) und reguläre Vereinigung („choice“) (Operator: |) sowie die einstelligen Opera-tionen Kleene-Stern (Operatoren: *, +)1 und Optional (Operator: ?). Um Zeichendaten im Inhalteines Elements zu erlauben, ist der atomare Basisdatentyp beliebige Zeichenkette (#PCDATA)vorgesehen. Der reguläre Ausdruck darf aber auch leer (EMPTY) sein oder beliebige Elementty-pen (ANY) zulassen.

Analog zur Elementtyp-Deklaration werden in der DTD Attributtypen durch eine Attributtyp-Deklaration spezifiziert. Da Attribute in einem XML-Dokument die Eigenschaften von Elemen-ten beschreiben, ist jeder Attributtyp einem Elementtyp eindeutig zugeordnet. Da, wie bereitserwähnt, der Wert eines Attributs aus keinen Elementen bestehen darf, stehen für Attribute nursehr einfache Typen zur Auswahl. Erlaubt sind Zeichendaten (CDATA) und definierbare Auf-zählungstypen. Mit der Typangabe ID wird spezifiziert, dass es sich bei diesem Attribut, umein Schlüsselattribut handelt. Die Werte dieser Attribute müssen Bezeichner sein, die für einbestimmtes Dokument eindeutig sind. Attribute vom Typ IDREF und IDREFS sind Schlüssel-referenzen und verweisen auf einen oder mehrere dieser Schlüsselwerte. Für jeden Attributtypenmuss angegeben werden, in welcher Form es in einem Element aufzutreten hat. Es kann alsoptional (#IMPLIED), verpflichtend (#REQUIRED) oder unveränderlich (#FIXED) deklariertwerden. Weiterhin können Standardwerte für Attribute angegeben werden.

In einer DTD existiert mit den Parameter-Entities eine Möglichkeit häufig auftretende, längerereguläre Ausdrücke abkürzend zu bezeichnen. Innerhalb der DTD wird dann dieser Bezeichneranstatt des längeren Ausdrucks verwendet.

Definition 2.2 (Dokumenttyp-Definition)Eine Dokumenttyp-Definition entspricht der folgenden Grammatik:

1Der Operator * steht für eine Liste, die auch leer sein darf, + für eine Liste mit mindestens einem Element.

<DoctypeDecl> � "<!DOCTYPE" <Name> "[" <MarkupDecl> "]" ">"<MarkupDecl> � <ElementDecl> | <AttListDecl> | <EntityDecl>

<ElementDecl> � "<!ELEMENT" <Name> <ContentSpec> ">"<ContentSpec> � "EMPTY" | "ANY" | <Mixed> | <Children><Mixed> � "(" "#PCDATA" ("|" <Name>)* ")*" | "(" "#PCDATA" ")"<Children> � (<Choice> | <Seq>) ("?" | "*" | "+")?<Cp> � (<Name> | <PEReference> | <Choice> | <Seq>) ("?" | "*" | "+")?<Choice> � "(" <Cp> ( "|" <Cp> )* ")"<Seq> � "(" <Cp> ("," <Cp> )* ")"

<AttrListDecl> � "<!ATTLIST" <Name> <AttDef>* ">"<AttDef> � <Name> <AttType> <DefaultDecl><AttType> � "CDATA" | "ID" | "IDREF" | "IDREFS" | <Enumeration><Enumeration> � "(" <Name> ("|" <Name>)* ")"<DefaultDecl> � "#REQUIRED" | "#IMPLIED" | "#FIXED" <AttValue>

<EntityDecl> � "<!ENTITY" "%" <Name> <EntityValue> ">"<EntityValue> � (""" (<CharData> | <PEReference>)* """)

| ("’" (<CharData> | <PEReference>)* "’")<PEReference> � "%" <Name> ";"

Das Nichtterminalsymbol <Name> steht hier für einen Elementnamen. Mit <AttValue> werdenerneut Zeichenketten in einfachen (’) oder doppelten Hochkommata (") und mit <CharData>alphanumerische Zeichendaten bezeichnet. �

Mit einer definierten Auszeichnungssprache, spezifiziert durch eine DTD, kann für ein gegebe-nes XML-Dokument getestet werden, ob es ein Dokument dieser Auszeichnungssprache ist. Wer-den die Anforderungen der DTD von einem Dokument erfüllt, spricht man von einem gültigen(„valid“) Dokument. Anders als bei der Wohldefiniertheit ist für die Überprüfung der Gültigkeiteines Dokuments eine vorgegebene DTD notwendig. Damit ein Dokument als gültig erkanntwird, muss es sämtliche Anforderungen der DTD erfüllen. Dazu gehört, dass im Dokumentnur Elemente auftreten, die auch in der DTD deklariert wurden, und diese korrekt verschachteltsind. Dies bedeutet, dass die Inhalte der konkreten Elemente eines Dokuments den Inhaltsmodel-len der Elementtypen entsprechen. Weiterhin darf ein Element nur Attribute enthalten, die auchfür diesen Elementtypen deklariert wurden. Die Werte der Attribute müssen zu den deklariertenWertebereichen der Attributtypen passen. Die Reihenfolge der Attribute eines Elements ist belie-big. Außerdem wird noch die Eindeutigkeit der Schlüsselattribute gefordert, sowie die Existenzder Schlüsselwerte, falls sie referenziert werden.

Eine ganze Reihe dieser Anforderungen lassen sich für XML-Dokumente, die von einem Pro-gramm dynamisch erzeugt werden, statisch, zum Zeitpunkt der Programmübersetzung, überprü-fen. Ausgenommen sind die Eindeutigkeit der Schlüsselattribute sowie die Existenz der Schlüs-selwerte. Auch ist es möglich, dass ein Programm versucht, aus einer bereits leeren Elementli-ste ein weiteres Element zu entfernen, was auch erst während des Programmablaufs festgestelltwerden kann. Im weiteren Verlauf dieser Arbeit wird diese statisch überprüfbare Eigenschaft mit

statischer Gültigkeit bezeichnet.

Mit einer DTD lässt sich nun die Auszeichnungssprache des Dokuments aus dem letzten Beispielspezifizieren.

Beispiel 2.2Die Antiquary-Offer-Markup-Language (AOML) wird durch folgende DTD festgelegt:

1 <!DOCTYPE aoml [2 <!ENTITY % f i e l d s " a r t i c l e , c o n d i t i o n , p r i c e " >3

4 <!ELEMENT aoml ( a n t i q u a r y , o f f e r ) >5 <!ELEMENT a n t i q u a r y ( name , a d d r e s s , e m a i l ) >6 <!ELEMENT name (#PCDATA) >7 <!ELEMENT a d d r e s s (#PCDATA) >8 <!ELEMENT e m a i l (#PCDATA) >9 <!ELEMENT o f f e r ( book | r e c o r d ) � >

10 <!ELEMENT book ( t i t l e , a u t h o r ? , % f i e l d s ; ) >11 <!ELEMENT r e c o r d ( t i t l e , a r t i s t , % f i e l d s ; ) >12 <!ELEMENT t i t l e (#PCDATA) >13 <!ELEMENT a u t h o r (#PCDATA) >14 <!ELEMENT a r t i c l e (#PCDATA) >15 <!ELEMENT c o n d i t i o n (#PCDATA) >16 <!ELEMENT a r t i s t (#PCDATA) >17 <!ELEMENT p r i c e (#PCDATA) >18

19 <!ATTLIST aoml d a t e CDATA #IMPLIED >20 <!ATTLIST book c a t a l o g CDATA #IMPLIED >21 <!ATTLIST p r i c e c u r r e n c y CDATA #REQUIRED >22 ] >

Listing 2.2: Dokumenttyp-Definition der AOML

Die DTD deklariert das Entity field und die Elementtypen aoml, antiquary, name, ad-dress, email, offer, book, record, title, author, article, condition, ar-tist und price. So muss beispielsweise ein Element vom Typ antiquary im Inhalt dieElemente name, address und email in dieser Reihenfolge umfassen. Darüber hinaus werdenfür den Elementtyp aoml ein Attribut date, für den Elementtyp book ein Attribut catalogund für den Elementtyp price das Attribut currency vereinbart. �

Das Beispiel, welches in dieser Arbeit durchgängig betrachtet wird, enthält alle Voraussetzun-gen, die zur Vorstellung der Probleme und Lösungswege, die hier verfolgt werden, notwendigsind. Es beinhaltet eine Anwendung, die dynamisch zur Laufzeit XML-Dokumente erzeugt. Diegenerierten Dokumente müssen dabei einer vorgegebenen DTD genügen. Der Sprachumfang derspezifizierten Auszeichnungssprache ist zwar stark eingeschränkt, doch würde eine Erweiterung


des Beispiels auf mehr Elemente und Attribute konzeptionell zu keinen weiteren Erkenntnissenführen. Vielmehr wäre eine Verminderung in der Klarheit der Darstellung zu erwarten.

Ein wesentlicher Kritikpunkt an DTDs ist, dass nur zwei atomare Basisdatentypen, nämlich#PCDATA als Elementinhalt und CDATA als Attributwert, vorgesehen sind. Dies mag für denBereich der Dokumentenverarbeitung ausreichend sein, für den Datenaustausch im World-WideWeb ist es nicht. Im allgemeinen Datenaustausch ist es beispielsweise häufig sinnvoll, für denElementtyp einer Auszeichnungssprache zu spezifizieren, dass das Inhaltmodell vom atomarenBasisdatentyp integer ist. Weitere Einschränkungen von DTDs entstehen durch die globaleSpezifikation von Elementtypen. Lokale Deklarationen eines Elementnamens mit unterschied-lichen Inhaltsmodellen ist deshalb ausgeschlossen. Eine Beschränkung von Schlüsselreferenzenauf die Schlüssel bestimmter Elementtypen ist ebenfalls nicht möglich.

2.1.2 XML-Schema

XML-Schema liegt seit Mai 2001 als Empfehlung des W3C [W3C01c, W3C01d] vor. Es dient –wie die DTDs– zur Spezifikation von Auszeichnungssprachen, bietet aber genauere Möglichkeitzur Definition von Elementtypen, Attributtypen und weiteren Nebenbedingungen. Die Notationeiner Sprachbeschreibung erfolgt mit XML-Schema in der Auszeichnungssprache XML-Schema-Definition-Language (XSDL), die selbst ein eigener XML-Dialekt ist. Die folgende Darstellungbeschränkt sich auf die für diese Arbeit wichtigen Besonderheiten; ausführliche Beschreibungenfinden sich in [W3C01b, vdV02].

In XML-Schema wird unterschieden zwischen Deklarationen, die Komponenten definieren, diein den Dokumenten der Auszeichnungssprache auftreten können, und Definitionen, die Kompo-nenten spezifizieren, die nur schemaintern Verwendung finden. Im Gegensatz zu DTDs könnenElementtypen nun global, geltend in der gesamten Sprachbeschreibung, oder lokal, nur im aktu-ellen Inhaltsmodell gültig, deklariert werden, wodurch unterschiedliche Elementtypen mit ver-schiedenen Inhaltsmodellen bei gleichem Elementnamen möglich werden. Die Deklaration einesElementnamens geschieht in XSDL durch das Element element mit dem Attribut name. Fürden Inhalt von Elementen kann definiert werden, dass er leer ist, nur Text umfasst, nur Elementeenthält oder gemischten Inhalt hat. Für die Inhaltsmodelle der Elementtypen kann neben Konka-tenation (Element sequence) und Vereinigung (Element choice) durch die Operation allabkürzend ausgedrückt werden, dass Elementtypen in beliebiger Reihenfolge auftreten müssen.Durch die Attribute minOccurs und maxOccurs können Nebenbedingungen, die die Häu-figkeiten des Auftretens von Inhaltsmodellen festlegen, genauer spezifiziert werden. Wird dasAttribut maxOccurs mit dem Wert unbounded versehen, so darf sich das entsprechende In-haltsmodell im Dokument beliebig oft wiederholen. Dies ist vergleichbar mit dem Kleene-Stern-Operator in DTDs.

XML-Schema differenziert zwischen einfachen und komplexen Typen. Bei einfachen Typen (Ele-ment simpleType) handelt es sich entweder um eingebaute atomare Basisdatentypen, wiebeispielsweise integer oder string, Aufzählungstypen (Element enumeration) oder um

Ableitungen atomarer Basisdatentypen, deren Wertebereiche eingeschränkt wurden. Auch kön-nen durch einfache Typen Listen- oder Vereinigungstypen („union type“) über einfache Typendefiniert werden. Komplexe Typen (Element complexType) sind dagegen Typen für Element-typen, die aus einem Inhaltsmodell und optionalen Attributdeklarationen bestehen. Sie könnengenauso wie einfache Typen durch einen eindeutigen Typnamen bestimmt sein oder als anony-me Typen direkt in einer Elementtyp-Deklaration auftreten. Das folgende Beispiel zeigt eineElementtyp-Deklaration. Bei der Deklaration eines Elementnamens kann dann entweder ein an-onymer Typ definiert oder auf einen Typnamen verwiesen werden (Attribute type).

Beispiel 2.3In diesem Beispiel wird die Deklaration des Elementtyps aoml der DTD aus Beispiel 2.2 inXML-Schema formuliert; die vollständige Sprachbeschreibung findet sich in Anhang A:

2 < e l e m e n t name=" aoml ">3 <complexType >4 <sequence >5 < e l e m e n t name=" a n t i q u a r y " t y p e =" t _ a n t i q u a r y " / >6 < e l e m e n t name=" o f f e r " t y p e =" t _ o f f e r " / >7 </ sequence >8 < a t t r i b u t e name=" d a t e " t y p e =" s t r i n g " / >9 </ complexType >

10 </ e lement >

Listing 2.3: Schemadefinition AOML

Es zeigt die Spezifikation von aoml durch einen anonymen komplexen Typen als globalen Ele-menttypen. Das Inhaltsmodell besteht wie in der DTD aus der Konkatenation eines antiqua-ry- und eines offer-Elementtyps. Die Inhaltsmodelle und Attribute der lokal deklarierten Ele-menttypen antiquary und offer werden durch die komplexen Typen t_antiquary undt_offer definiert, deren Definitionen bringen konzeptionell nichts Neues, weshalb sie hiernicht weiter ausgeführt sind. Sie finden sich in Anhang A. Das Attribut date ist vom atomarenBasisdatentyp string. �

Ähnlich zur Definition von Parameter-Entities gibt es in XML-Schema die Möglichkeit Inhalts-modelle mit einem Namen zu versehen. Mit diesen benannten Gruppen (Element group) istes möglich die Definitionen von komplexen Typen abzukürzen, indem auf solche benannten In-haltsmodelle referenziert wird.

Von einfachen und komplexen Typen können in XML-Schema, ähnlich wie in objektorientiertenProgrammiersprachen durch Vererbung, Ableitungen gebildet werden. Zu unterscheiden ist da-bei zwischen einer Einschränkung (Element restriction) und einer Erweiterung (Elementextension), die nur für komplexe Typen möglich ist. Bei einer Einschränkung müssen alleInstanzen des abgeleiteten Typs eine gültige Instanz des Basistyps sein, womit der abgeleiteteTyp einen Subtyp des Basistyps bildet. Bei der Ableitung durch Erweiterung wird ein komple-xer Basistyp um weitere Elementtypen oder Attributtypen ergänzt. In einer Dokumenteninstanz

kann dann anstelle des komplexen Basistyps der abgeleitete, erweiterte komplexe Typ auftreten,was mit Typsubstitution bezeichnet wird. Der aktuelle Typ des Elements muss dann allerdingsdurch ein spezielles Attribut (type) ausgezeichnet werden. Eine ähnliche Erweiterung wirddurch Substitutionsgruppen („substitution group“) auf der Basis von Elementtypen eingeführt.XML-Schema erlaubt es, unterschiedliche Elementnamen mit gleichen Elementtypen zu einerSubstitutionsgruppe zusammenzufassen. Im Dokument ist es dann zulässig, ein Element aus derGruppe dort einzusetzen, wo ein anderer Elementtyp aus der Substitutionsgruppe erwartet wird.

Das folgende Beispiel zeigt die Sprachbeschreibung einer kleinen vollständigen Auszeichnungs-sprache mit XML-Schema.

Beispiel 2.4Das Shop-Interchange-Format (SIF) ist ein Datenaustauschformat zur Kommunikation mit demWarenkorb des zentralen Verzeichnis antiquarischer Bücher. Damit lassen sich Nachrichten for-mulieren, um den Warenkorb auszugeben, um Artikel hinzuzufügen oder um Artikel aus demWarenkorb zu entfernen. Das Format ist wie folgt definiert:

1 <schema >2 < e l e m e n t name=" shopReques t " t y p e =" t _ s h o p R e q u e s t " / >3

4 <complexType name=" t _ s h o p R e q u e s t ">5 <sequence >6 < e l e m e n t name=" s h o p p i n g C a r t "

t y p e =" t _ c a r t R e q u e s t " / >7 </ sequence >8 </ complexType >9

10 <complexType name=" t _ c a r t R e q u e s t ">11 <sequence >12 < e l e m e n t name=" a c c o u n t " t y p e =" i n t e g e r " / >13 < cho ice >14 < e l e m e n t name=" add " t y p e =" i n t e g e r " / >15 < e l e m e n t name=" remove " t y p e =" i n t e g e r " / >16 < e l e m e n t name=" g e t "><complexType / > </ e lement >17 </ cho ice >18 </ sequence >19 </ complexType >20

21

22 < e l e m e n t name=" shopResponse " t y p e =" t _ s h o p R e s p o n se " / >23

24 <complexType name=" t _ s h o p R e s p o n s e ">25 <sequence >26 < e l e m e n t name=" s h o p p i n g C a r t "

t y p e =" t _ c a r t R e s p o n s e " / >27 </ sequence >28 </ complexType >29

30 <complexType name=" t _ c a r t R e s p o n s e ">31 <sequence >32 < e l e m e n t name=" a c c o u n t " t y p e =" i n t e g e r " / >33 < e l e m e n t name=" r e q u e s t " t y p e =" t _ r e q u e s t " / >34 < e l e m e n t name=" i t e m s " t y p e =" t _ i t e m s "

minOccurs=" 0 " / >35 </ sequence >36 </ complexType >37

38 <complexType name=" t _ i t e m s ">39 <sequence >40 < e l e m e n t name=" a r t i c l e " t y p e =" i n t e g e r "

minOccurs=" 0 " maxOccurs =" unbounded " / >41 < e l e m e n t name=" d e s c r i p t i o n " t y p e =" s t r i n g "

minOccurs=" 0 " / >42 </ sequence >43 </ complexType >44

45 < s impleType name=" t _ r e q u e s t ">46 < r e s t r i c t i o n base =" s t r i n g ">47 < e n u m e r a t i o n v a l u e =" p r o c e s s e d " / >48 < e n u m e r a t i o n v a l u e =" f a i l " / >49 </ r e s t r i c t i o n >50 </ s impleType >51 </ schema >

Listing 2.4: Schemadefinition SIF

Die Sprachbeschreibung SIF deklariert die beiden globalen Elementtypen shopRequest undshopResponse. Darüber hinaus werden die komplexen Typen t_shopRequest, t_card-Request, t_shopResponse,t_cardResponse und t_items, mit den lokalen Element-typen shoppingCart, account, add, remove, get, request, items, article unddescription definiert. Außerdem wird der einfache Typ t_request durch Einschränkungdes atomaren Typs string als Aufzählungstyp festgelegt. �

XML-Schema geht in einer ganzen Reihe von Punkten über das Dargestellte hinaus. Nicht weiterbetrachtet werden in dieser Arbeit das Inhaltsmodell any, Attributgruppen, die Verhinderungvon Typsubstitution (Attribute: block), das Erzwingen einer Ableitung durch abstrakte Typenund abstrakte Elementtypen, die Verhinderung von Ableitungen (Attribute: final) sowie Ne-benbedingungen wie Eindeutigkeit, Schlüsselattribute und Referenzen auf diese. Für eine detai-

lierte Präsentation wird auf die für XML-Schema angeführte Literatur verwiesen.

2.2 XPath

XPath [W3C99a] ist eine vom W3C standardisierte Sprache zur Adressierung von Elementenund Teilen eines XML-Dokuments. Ursprünglich wurde es für den einheitlichen Gebrauch in derTransformationssprache der XML-Stylesheet-Language (XSLT) [W3C99b] und XML-Pointer-Language [W3C02b] entwickelt. Darüber hinaus werden von XPath Basisfunktionen zur Mani-pulation von Zeichenketten, Zahlen und booleschen Werten zur Verfügung gestellt.

In Definition 2.3 wird spezifiziert, was in dieser Arbeit unter einem XPath-Ausdruck verstandenwerden soll. Dabei handelt es sich, bis auf wenige Ausnahmen, um den gesamten Sprachumfangvon XPath in der Version 1.0. Nicht betrachtet werden abkürzende Notation, Verarbeitungsan-weisungen, absolute Pfadangaben, Union- und Filter-Ausdrücke sowie die von XPath definiertenFunktionen und Operationen auf Zeichenketten, Zahlen und booleschen Werten. Es sei daraufhingewiesen, dass die in Entwicklung befindliche Version 2.0 von XPath [W3C02a] in weitenTeilen umfangreicher ist. Grundsätzlich sind dann auch Bedingungen und Schleifenkonstruktemöglich. Die zusätzlichen Möglichkeiten der neuen Version bieten isoliert betrachtet zwar ei-ne Erweiterung der Ausdrucksmöglichkeit, im Rahmen dieser Arbeit wird XPath aber stets alsErgänzung einer Programmiersprache behandelt, die bereits ähnliche Programmkonstrukte zurVerfügung stellt. Ein weiterer Vorteil der hier verwendeten Version 1.0 von XPath ist die Vorlageals festgelegter Standard. Umfassende Beschreibungen der beiden Versionen findet sich in denSpezifikationen des W3C [W3C99a, W3C02a].

Definition 2.3 (XPath-Ausdruck)Ein XPath-Ausdruck ist nach folgender Grammatik aufgebaut:<LocationPath> � <RelativeLocationPath><RelativeLocationPath> � <Step> | <RelativeLocationPath> "/" <Step><Step> � <AxisSpecifier> <NodeTest> <Predicate>*<AxisSpecifier> � <AxisName> "::"<AxisName> � "ancestor" | "ancestor-or-self" | "attribute" |

"child" | "descendant" | "descendant-or-self" |"following" | "following-sibling" | "parent" |"preceding" | "preceding-sibling" | "self"

<NodeTest> � <NameTest> | <NodeType> "(" ")"<Predicate> � "[" <PredicateExpr> "]"<PredicateExpr> � <Expression><NameTest> � "*" | <Name><NodeType> � "comment" | "text" | "node"

Mit <Expression> wird dabei ein boolescher Ausdruck bezeichnet, der hier nicht weiter aus-geführt wird. Er orientiert sich an Ausdrücken in gebräuchlichen Programmiersprachen. DasNichtterminalsymbol <Name> steht für einen Elementnamen. �

2.2. XPATH 21

Im Folgenden werden die für diese Arbeit relevanten Konstrukte näher erläutert. Jeder XPath-Ausdruck bezieht sich auf einen aktuellen Kontextknoten („context node“), bei dem es sich umeinen beliebigen Knoten innerhalb des XML-Dokuments handeln kann. Dieser Knoten ist nö-tig, um festzulegen an welcher Position im Dokument die Auswertung des Ausdrucks beginnt.Während der Berechnung der Ergebnismenge zu einem Ausdruck kann sich, zum Ermitteln vonTeilergebnissen, der Kontextknoten zeitweilig verändern.

Ein Pfadausdruck in XPath selektiert aus einem XML-Dokument einen einzelnen Knoten oder ei-ne Menge von Knoten.2 Er besteht aus beliebig vielen Lokalisierungsschritten („location step“),die durch das Zeichen / von einander getrennt werden. Vereinfacht dargestellt, bestehen sie ausfolgender Struktur:

<Step> � / �� /<Step> �

Die Semantik der Auswertung dieser Liste von Lokalisierungsschritten, die eine Knotenmenge(„node set“) als Ergebnis liefert, lässt sich durch folgenden Algorithmus in Pseudocode-Notationbeschreiben.

NodeSet p r o c e s s ( Node c o n t e x t , L i s t l o c a t i o n S t e p s ) {NodeSet � � = a p p l y ( l o c a t i o n S t e p s . f i r s t ( ) , c o n t e x t ) ;i f ( l o c a t i o n S t e p s . t a i l ( ) . i sEmpty ( ) )

re turn � � ;e l s e {

NodeSet �� =�

;foreach ( n �� )�� = �� p r o c e s s ( n , l o c a t i o n S t e p s . t a i l ( ) ) ;

re turn �� ;} / / e l s e

} / / p r o c e s s

Listing 2.5: Algorithmus zur Auswertung der Lokalisierungsschritte

Besteht die Liste nur aus einem Lokalisierungsschritt, ist das Ergebnis der Auswertung diesesSchritts das Gesamtergebnis. Für eine Liste mit mehr als einem Lokalisierungsschritt wird zu-nächst der erste Schritt ausgewertet. Anschließend wird jeder Knoten in diesem Zwischenergeb-nis als Kontextknoten mit der Liste ohne den ersten Lokalisierungsschritt weiterverarbeitet. DieTeilresultate dieser rekursiven Aufrufe werden anschließend zum Gesamtergebnis vereinigt.

Jeder Lokalisierungsschritt besteht aus den drei Komponenten Achse („axis“), Knotentest („nodetest“) und beliebig vielen Prädikaten („predicate“). Dies führt, vereinfacht dargestellt, zu einerStruktur, wie folgt:

<Axis>::<NodeTest>[<Predicate> � ] �� [<Predicate> � ]

In XPath existieren die folgenden Achsen, die in zwei Gruppen unterteilt werden: Zum einen gibtes Achsen, die Knoten in Dokumentordnung („document order“) selektieren, und zum anderen

2In XPath wird von einer Knotenmenge gesprochen, obwohl eine Ordnung für diese Menge existiert.


Achsen, die als Ergebnismenge eine Knotenmenge in umgekehrter Dokumentordnung („reversdocument order“) liefern. Mit Dokumentordnung wird dabei die Reihenfolge des Auftretens derersten Zeichen von Elementen, Attributen, Text und Kommentaren im Dokument bezeichnet. DaElemente vor ihrem Inhalt liegen, sind Elemente anhand des Auftretens ihrer Start-Tags in XML

angeordnet. Die Attribute eines Elements liegen vor den Subelementen des Inhalts des Elements.Die umgekehrte Dokumentordnung ist definiert als die Umkehrung der Dokumentordnung.

Dies ist deshalb von Bedeutung, weil sich anschließende Prädikate auf die Positionen in der Listebeziehen können.

� Die Achsen mit Knoten in Dokumentordnung lauten:

– Selbst-Achse („self axis“): Selektion des aktuellen Kontextknotens.

– Kind-Achse („child axis“): Liefert die unmittelbaren Kinderknoten des Kontextkno-tens.

– Nachfahr-Achse („descendant axis“): Gibt die Kinder sowie rekursiv alle Kindeskin-der zurück.

– Nachfahr-oder-Selbst-Achse („descendant-or-self axis“): Bezeichnet alle Kindeskin-der des Kontextknotens inklusive dem aktuellen Kontextknoten.

– Nachfolgende-Geschwister-Achse („following sibling axis“): Wählt alle folgendenGeschwisterknoten des Kontextknotens aus.

– Nachfolger-Achse („following axis“): Selektiert alle nachfolgenden Knoten des ak-tuellen Kontextknotens.

– Attribut-Achse („attribute axis“): Gibt alle Attribute des Kontextknotens zurück.

� Die Achsen mit Knoten in umgekehrter Dokumentordnung sind:

– Eltern-Achse („parent axis“): Liefert den unmittelbaren Elternknoten des Kontext-knotens.

– Vorfahr-Achse („ancestor axis“): Gibt den Elternknoten sowie rekursiv alle weiterenVorfahrenknoten zurück.

– Vorfahr-oder-Selbst-Achse („ancestor-or-self axis“): Bezeichnet alle Vorfahrenkno-ten des Kontextknotens inklusive dem aktuellen Kontextknoten.

– Vorherige-Geschwister-Achse („preceding sibling axis“): Wählt alle Geschwister-knoten des Kontextknotens aus, die vor dem Kontextknoten im Dokument stehen.

– Vorgänger-Achse („preceding axis“): Selektiert alle vor dem aktuellen Kontextknotenauftretenden Knoten.

Beim anschließenden Knotentest wird die durch die Achse ausgewählte Liste von Knoten einge-schränkt. Grundsätzlich stehen folgende Möglichkeiten zur Verfügung:

2.2. XPATH 23

� Durch die Angabe eines Elementnamen werden nur die Elemente aus der selektierten Kno-tenliste ausgewählt, die von diesem Elementtyp sind.

� Alternativ können mit der Angabe eines Knotentyps alle Knoten dieses Typs entlang derbezeichneten Achse selektiert werden. Es stehen dafür folgende Knotentypen zur Auswahl:

– node(): Wählt alle Knoten aus, und bezeichnet damit den Grundtyp aller Knoten-typen.

– text(): Ausschließlich Textknoten werden selektiert.

– comment(): Bezeichnet die Kommentarknoten im Dokument.

Durch die Angabe von einem oder mehreren Prädikaten kann die bereits reduzierte Knotenlisteweiter vermindert werden. Ein Prädikat ist ein beliebiger boolescher Ausdruck, der für jedenKnoten in der Knotenliste ausgewertet wird. Erfüllt ein Knoten das angegebene Prädikat, wirder in die Ergebnisliste übernommen. XPath führt neben den üblichen Relationen und Funktionenauf Zeichenketten, Zahlen und booleschen Werten folgende, zusätzliche elementare Operationenein:

� position(): Liefert die Position des Kontextknotens in der gegenwärtigen Knotenlistezurück.

� last(): Die Operation ermittelt die letzte Position für die selektierte Knotenliste. Diesentspricht damit der Länge der aktuellen Knotenliste.

Die Auswertung eines aus diesen drei Teilen bestehenden Lokalisierungsschritts erfolgt derart,dass zunächst alle Knoten gemäß der angegebenen Achse bezüglich des aktuellen Kontextkno-tens selektiert werden. Danach wird die Knotenmenge auf die Knoten eingeschränkt, die zu-nächst den Knotentest bestehen und im Anschluss daran nacheinander jedes Prädikat erfüllen.Die folgenden Beispiele verdeutlichen dieses Vorgehen.

Beispiel 2.5Um die Anwendung von XPath zu demonstrieren, werden einige Beispiele zur Auszeichnungs-sprache AOML (Beispiel 2.2) angegeben, die sich beispielsweise auf das Dokument aus Bei-spiel 2.1 beziehen können.

1. Der folgende Ausdruck liefert sämtliche Kinderknoten mit dem Elementnamen authorvom aktuellen Kontextknoten:

c h i l d : : a u t h o r

Bei Anwendung des Ausdrucks auf das Dokument aus Beispiel 2.1 mit dem book-Ele-ment aus Zeile 8 als Kontextknoten ergibt sich folgendes Ergebnis:

<author >Thomas Mann </ author >

2. Mit dieser Angabe werden die Kinderknoten des Kontextknotens selektiert, die den Ele-menttyp book haben und hinter dem fünften book-Element stehen:

c h i l d : : book [ p o s i t i o n ( ) > 5 ]

Sei der Elementknoten offer aus Zeile 7 der Kontextknoten für die Auswertung die-ses Ausdrucks, so ergibt sich eine leere Resultatsmenge, da nur zwei Bücher im Angebotdieses Händlers enthalten sind.

3. Die Selektion der Nachfahren vom Elementtyp price, die ein Attribut mit dem Namencurrency und dem Wert EUR besitzen, erfolgt mit diesem Pfadausdruck:

d e s c e n d a n t : : p r i c e [ s t r i n g ( a t t r i b u t e : : c u r r e n c y ) = ="EUR" ]

Für die beispielhafte Auswertung sei der Kontextknoten das Element aoml aus Zeile 1.Dann ergibt sich folgende Ergebnismenge:

 8 . 0 0 </ pr ice > 25 .00 </ pr ice >

�

Beispiel 2.6Dieses Beispiel zeigt eine Anwendung für die Auszeichnungssprache SIF (Beispiel 2.4).

c h i l d : : shopReques t / c h i l d : : s h o p p i n g C a r t [ p o s i t i o n ( ) = = 1 ]

Der Ausdruck liefert das erste shoppingCart-Element, das das Kind eines shopRequest-Elements ist, welches wiederum ein Kind des gegenwärtigen Kontextknotens sein muss. �

Abschließend ist anzumerken, dass XPath-Ausdrücke unabhängig von einer Sprachbeschreibungformuliert werden und sich ausschließlich an der Dokumentenstruktur orientieren.

2.3 Dokument-Objektmodell

Die Daten eines XML-Dokuments liegen durch ihre einfache Form zunächst als reine Textdatenvor. Die Verarbeitung des Inhalts eines XML-Dokuments erfolgt in der Regel durch ein Pro-gramm, weshalb ein universeller Zugriff auf die Daten erforderlich wird. Es liegt nahe, dafürdie logische Sicht auf das Dokument, die implizite Baumstruktur der geschachtelten Elemente,heranzuziehen.

Das Dokument-Objektmodell (DOM) spezifiziert die logische Struktur eines Dokuments, um auseiner Anwendung heraus über diese auf das Dokument zuzugreifen oder es zu manipulieren. DasDOM ermöglicht dem Programmierer das Erzeugen von wohlgeformten Dokumenten, die Na-vigation in deren Struktur, das Hinzufügen, Verändern oder Löschen von Elementen und Inhalt.

2.3. DOKUMENT-OBJEKTMODELL 25

Alles was ein XML-Dokument enthält, kann durch das Dokument-Objektmodell angesprochen,verändert, gelöscht oder hinzugefügt werden.

Das Dokument-Objektmodell wurde vom W3C als Empfehlung [W3C98b, W3C00a] verab-schiedet. In der Spezifikation werden sprach- und plattformneutrale Schnittstellen definiert. Zu-sätzlich werden vom DOM für einige Programmiersprachen sogenannte Sprachbindungen zurVerfügung gestellt. Eine Sprachbindung gibt an, wie die DOM-Schnittstellen für eine konkreteProgrammiersprache umgesetzt werden.

In diesem Abschnitt werden die grundlegenden Schnittstellen der Spezifikation vorgestellt. Eswird eine formale Semantik angegeben, da [W3C98b] diese nur informell beschreibt. Nach ei-ner kurzen Darstellung der Spezifikationsmethode, werden die Schnittstellen definiert. Es fol-gen Beispiele, die Beschreibung von Erweiterungen und Implementierungen sowie eine kritischeEinschätzung des DOM.

2.3.1 Formalisierung

In diesem Abschnitt wird eine Möglichkeit zur Spezifikation von objektorientierten Schnittstel-len vorgestellt. Dabei wird die Idee der abstrakten Datentypen [LZ74, WPP

�83, LEW96] auf-

gegriffen und auf objektorientierte Schnittstellen übertragen. Die Einführung in dieser Arbeiterfolgt nur informell. Die formalen Grundlagen, wie objektorientierte Algebra, Belegungs- undAusführungsfunktion, werden hier nicht erläutert. Detaillierte Darstellungen dazu finden sich in[LV96, Hug99], objektorientierte Typsysteme werden in [Ala97, Ala99] behandelt.

In abstrakten Datentypen wird die Semantik der Operationen durch Gleichungen spezifiziert.Auf ähnliche Weise soll hier die Semantik der objektorientierten Methoden angegeben werden.Dafür ist das Konzept einer Anweisungsgleichung notwendig.

Definition 2.4 (Anweisungsgleichung)Eine Anweisungsgleichung besteht aus den zwei Anweisungen �� und �� und wird notiert durch:

��

��

Eine Anweisungsgleichung ist gültig innerhalb einer objektorientierten Algebra, falls für jedengültigen Anfangszustand nach Auswertung von �� die gleichen Variablenbelegungen und diegleichen Zustände für die beteiligten Objekte erreicht werden, wie nach der Auswertung von �� .Für die beteiligten Objektreferenzen gilt dabei, dass sie bis auf Umbenennung gleich sind.

Als abkürzende Schreibweise wird im Weiteren auch folgendes verwendet:

�� ist äquivalent zu��

�� Dies ist so zu interpretieren, dass nach der Auswertung von � die aufgeführte Gleichung

� ��


gilt, deren Ausdrücke�

und � nur Zugriffsoperationen beinhalten und dadurch die Zustände derObjekte nicht verändern.

Die Semantik einer objektorientierten Schnittstelle wird nun im Weiteren durch eine Menge vonAnweisungsgleichungen spezifiziert. Eine objektorientierte Algebra ist ein Modell einer objekt-orientierten Schnittstelle, falls sämtliche Anweisungsgleichungen der Schnittstelle gültig sind.

Das folgende Beispiel demonstriert den verwendeten Formalismus.

Beispiel 2.7Gegeben sei die Schnittstelle Stack, die die Methoden eines Kellers über ganzen Zahlen defi-niert, in typischer objektorientierter Form:

1 i n t e r f a c e S t a c k {2 s t a t i c S t a c k newStack ( ) ;3 void push ( i n t i ) ;4 void pop ( ) ;5 i n t t o p ( ) ;6 boolean i sEmpty ( ) ;7 } / / S t a c k

Ein zunächst leerer Keller wird mit der Operation newStack erzeugt. Die Methode push er-laubt das Ablegen einer ganzen Zahl auf dem Keller. Die oberste Zahl kann mit der Methode popwieder entfernt werden. Ausgelesen werden kann sie mit der Methode top. Um zu überprüfen,ob der Keller leer ist, steht die Methode isEmpty zur Verfügung.

Die Spezifikation mittels der oben eingeführten Anweisungsgleichungen kann nun wie folgt vor-genommen werden; wobei � für die leere Anweisung steht:

�� newStack �� isEmpty ��

� � � newStack �� true �� push �� isEmpty ��

� � push �� false �� push �� top ��

� � push �� push �� pop ��

Für die Variablen gilt � � Stack, � int und � � boolean. Unter Verwendung der abkürzendenSchreibweise können die ersten drei Gleichungen umgeschrieben werden zu:

� � isEmpty �� newStack �� true

� � isEmpty �� push � �� false

� � top �� push � �� Die erste Gleichung definiert, dass nach der Erzeugung eines Kellers dieser zunächst leer ist.Nach dem Ablegen eines Elements ist ein Keller nicht mehr leer, was die zweite Gleichungangibt. In der Dritten wird spezifiziert, dass nach dem Ablegen eines Elements auf dem Keller


dieses Element das oberste Element ist. Die Anwendung der beiden Methoden push und popnacheinander führt wieder zum ursprünglichen Zustand; dies legt die letzte Gleichung fest. �

2.3.2 Schnittstellen und deren Semantik

Die Beschreibung der Schnittstellen des DOM in diesem Abschnitt beschränkt sich auf die Schnitt-stellen, die für die Konzepte Dokument, Element, Attribut und Kommentar notwendig sind.Weiterhin wird hier nur die konsequent objektorientierte Umsetzung dargestellt. Auf den ver-einfachenden Ansatz, bei dem jedes Objekt im DOM als Knoten verstanden werden kann, wirdhier aus Gründen der Klarheit verzichtet. Für eine weitergehende Spezifikation des DOM seiauf die Empfehlungen des W3C verwiesen. Die Definition der Syntax des DOM erfolgt in dersprach- und plattformneutralen Interface-Definition-Language (IDL) der OMG [Obj02]. Zur Be-schreibung der Semantik wird hier der oben eingeführte formale Ansatz gewählt, während diegenannten Referenzen eine informelle Beschreibung angeben.

Schnittstelle für Dokumente

Ziel des DOM ist es, ein Modell für XML-Dokumente bereitzustellen, weshalb es nötig ist, zu-nächst eine Schnittstelle für Dokumente festzulegen. In Listing 2.6 ist die Schnittstelle darge-stellt. Jedes Dokument besteht, wie in Abschnitt 2.1 erwähnt, aus einem Wurzelelement. Dieses

1 i n t e r f a c e Document {2 a t t r i b u t e Element documentElement ;3 Element c r e a t e E l e m e n t ( in DOMString tagName ) ;4 Text c r e a t e T e x t N o d e ( in DOMString d a t a ) ;5 Comment createComment ( in DOMString d a t a ) ;6 A t t r c r e a t e A t t r i b u t e ( in DOMString name ) ;7 }

Listing 2.6: DOM-Schnittstelle Document

Wurzelelement wird mit dem Attribut documentElement angesprochen. Unter Vorwegnahmeder Attribute parentNode, das auf den Elternknoten innerhalb der baumartigen Repräsentationeines Dokuments verweist, sowie nextSibling und previousSibling, die auf Vorgängerund Nachfolger zeigen, aus der Schnittstelle Node ist eine Formalisierung möglich:

� Das Wurzelelement verweist mittels parentNode auf das Dokumentobjekt.

�� documentElement � parentNode � �


� Das Wurzelelement hat keinen Nachfolger.3

�� documentElement � nextSibling � nil

� Das Wurzelelement hat keinen Vorgänger.�� documentElement � previousSibling � nil

Weiterhin sind in dieser Schnittstelle die Konstruktoren für die Schnittstellen Element, Textund Attribut untergebracht. Da diese Teile eines Dokuments nach Auffassung des DOM nurinnerhalb eines Dokuments auftreten dürfen, fungiert die Schnittstelle als Konstruktor-Klasse(„abstract factory“), ein aus dem objektorientierten Design [GHJV95] bekanntes Muster. DerKonstruktor für die Dokumente selbst wird durch eine Implementierung des DOM definiert undist hier nicht dargestellt.

Schnittstelle für Attribute

Für die Elemente in XML-Dokumenten besteht die Möglichkeit, über Attribute Eigenschaftenfestzulegen. Im DOM werden diese über die Schnittstelle Attr realisiert, die in Listing 2.7 zusehen ist. Jedes XML-Attribut ist über das Attribut ownerDocument einem Dokument zuge-

1 i n t e r f a c e A t t r {2 readonly a t t r i b u t e Document ownerDocument ;3 readonly a t t r i b u t e DOMString name ;4 a t t r i b u t e DOMString v a l u e ;5 }

Listing 2.7: DOM-Schnittstelle Attr

ordnet, besitzt einen unveränderlichen Namen name und verfügt über einen Wert value. DieAttribute sind wie folgt zu formalisieren:

� Nach der Konstruktion eines Attributes a mit dem Namen n, verweist ownerDocumentauf das erzeugende Dokument, und name auf den Namen n.��

� createAttribute ��

� ownerDocument� � �

� name� Wird der Wert value eines Attributes a auf den Wert s gesetzt, so hat der Wert des

Attributes anschließend diesen Wert s.� �� value � � � ��

� value

3Mit nil wird der Wert einer nicht belegten Objektreferenz bezeichnet.


Schnittstellen für Knoten, Elemente, Text und Kommentar

Die Komponenten Element und Text, die, wie in Abschnitt 2.1 beschrieben, innerhalb eines Do-kuments beliebig tief geschachtelt werden können, sind im DOM als Komponente-Kompositum-Struktur („composite component“) realisiert, ein Modellierung, die ebenfalls aus dem objektori-entierten Design [GHJV95] stammt.

Mit Node in Listing 2.8 wird die Komponenten-Schnittstelle der verschachtelten Struktur desDOM definiert. Sie deklariert die Attribute und Methoden der Knoten, die in der baumartigen

1 i n t e r f a c e Node {2 c o n s t uns igned s h o r t ELEMENT_NODE = 1 ;3 c o n s t uns igned s h o r t TEXT_NODE = 3 ;4 c o n s t uns igned s h o r t COMMENT_NODE = 8 ;5 readonly a t t r i b u t e unsigned s h o r t nodeType ;6 readonly a t t r i b u t e Document ownerDocument ;7 readonly a t t r i b u t e Node pa ren tNode ;8 readonly a t t r i b u t e Node p r e v i o u s S i b l i n g ;9 readonly a t t r i b u t e Node n e x t S i b l i n g ;

10

11 Node appendChi ld ( in Node newChild ) ;12 Node i n s e r t B e f o r e ( in Node newChild , in Node r e f C h i l d ) ;13 Node removeChi ld ( in Node o l d C h i l d ) ;14 Node r e p l a c e C h i l d ( in Node newChild , in Node o l d C h i l d ) ;15 readonly a t t r i b u t e Node f i r s t C h i l d ;16 readonly a t t r i b u t e Node l a s t C h i l d ;17 readonly a t t r i b u t e NodeLis t c h i l d N o d e s ;18 }

Listing 2.8: DOM-Schnittstelle Node

Repräsentation eines XML-Dokuments auftreten. Demnach ist das Attribut nodeType der Dis-kriminator der Schnittstellen und ermöglicht die Unterscheidung der Knoten in Kommentar-,Text- oder Elementknoten. Jeder Knoten erhält weiterhin die Möglichkeit über das Attribut ow-nerDocument auf das ihn enthaltende Dokument, durch parentNode auf den Vaterknotenim Baum und über previousSibling und nextSibling auf die Geschwisterknoten le-send zuzugreifen. Eine direkte Manipulation dieser Attribute wird allerdings durch die Attribut-eigenschaft readonly ausgeschlossen. Stattdessen wird eine Veränderung der untergeordnetenBaumstruktur durch die Operationen appendChild, insertBefore, removeChild undreplaceChild für Elementknoten ermöglicht. Für diese sind auch die Attribute first-Child, lastChild und childNodes definiert.

Mit Hilfe der Methode appendChild, die einen Knoten als letztes Kind eines Elements ein-fügt und erst in der Schnittstelle Element definiert wird, können die formalen Spezifikationen


erfolgen:

� Das Attribut previousSibling zeigt stets auf den vorangehenden und nextSib-ling auf den nachfolgenden Knoten.�

� � appendChild �� appendChild ��

� � � � � � � � previousSibling� � � � � � � � nextSibling

� Das Attribut parentNode verweist auf den Elternknoten.

�� appendChild �� parentNode

� Ein neu angelegtes Element besitzt keinen Elternknoten, keinen Vorgänger, keinen Nach-folger und verweist auf das anlegende Dokument. Analoges gilt für Text- und Kommen-tarknoten. ��

� createElement �� ownerDocument � ��

� parentNode � nil�� previousSibling � nil�

� nextSibling � nil

Eine Spezifikation der restlichen Methoden ist erst später möglich und sinnvoll, weil diese nurfür die Kompositum-Schnittstelle Element definiert sind.

Die Schnittstelle Text, die in Listing 2.10 definiert wird, ist eine Spezialisierung der Schnitt-stelle CharacterData (Listing 2.9). Sie beschreibt den Zugriff auf textuellen Inhalt innerhalbdes Dokuments. Die Schnittstelle ist ein Blatt innerhalb der Komponente-Kompositum-Struktur

1 i n t e r f a c e C h a r a c t e r D a t a : Node {2 a t t r i b u t e DOMString d a t a ;3 }

Listing 2.9: DOM-Schnittstelle CharacterData

und kann deshalb keine weiteren Kinder haben. Die formale Spezifikation beschränkt sich aufdas Attribut data der Schnittstelle CharacterData:


1 i n t e r f a c e Text : C h a r a c t e r D a t a {2 } ;

Listing 2.10: DOM-Schnittstelle Text

� Das Attribut nodeType liefert den Wert für Textknoten und mit data kann auf denrepräsentierten Text zugegriffen werden.

�� createTextNode � � ��

�

� nodeType � TEXT_NODE�

� data � �

� Wird data gesetzt, hat das Attribut beim Zugriff den gleichen Wert.

�� data � � � ��

� data � �

1 i n t e r f a c e Comment : C h a r a c t e r D a t a {2 } ;

Listing 2.11: DOM-Schnittstelle Comment

Die Schnittstelle Comment in Listing 2.11 zur Repräsentation von Kommentarknoten ist analogzur Schnittstelle Text definiert.

In Listing 2.12 wird die Schnittstelle Element festgelegt, die für die Kompositum-Struktur imDokument steht. Sie ermöglicht den Zugriff auf die Attribute eines Elements über die MethodengetAttributeNode, setAttributeNode und removeAttributeNode unter Über-gabe der zu manipulierenden Attribute gemäß der Schnittstelle Attr aus Listing 2.7 bzw. unterAngabe der Attributnamen. Attribute können ausgelesen, gesetzt und gelöscht werden. Eben-falls stehen die Methoden getAttribute, setAttribute und removeAttribute mitanaloger Funktionalität zur Verfügung, die allerdings nicht über die Schnittstelle Attr sondernnur über den Attributnamen auf die Attribute zugreifen. Bevor die formale Spezifikation dieserMethoden erfolgt, sind zunächst die aufgeschobenen Methoden aus der Schnittstelle Node zudefinieren.

Das Verhalten des Konstruktors beschreibt folgende Spezifikation:

� Das Attribut nodeType liefert den Wert für Elementknoten nach dem Erzeugen einesneuen Elements e, tagName den Tagnamen und lastChild sowie firstChild ver-


1 i n t e r f a c e Element : Node {2 readonly a t t r i b u t e DOMString tagName ;3 readonly a t t r i b u t e NameNodeMap a t t r i b u t e s ;4 A t t r g e t A t t r i b u t e N o d e ( in DOMString name ) ;5 A t t r s e t A t t r i b u t e N o d e ( in A t t r newAtt r ) ;6 A t t r r e m o v e A t t r i b u t e N o d e ( in A t t r o l d A t t r ) ;7 DOMString g e t A t t r i b u t e ( in DOMString name ) ;8 void s e t A t t r i b u t e ( in DOMString name , in DOMString

v a l u e ) ;9 void r e m o v e A t t r i b u t e ( in DOMString name ) ;

10 NodeLis t getElementsByTagName ( in DOMString name ) ;11 }

Listing 2.12: DOM-Schnittstelle Element

weisen auf keine Knoten, weil noch keine Kinderknoten eingefügt wurden.� � � � �

� createElement �� nodeType � ELEMENT_NODE�� tagName � ��

� lastChild � nil�� firstChild � nil

Mit der Methode appendChild kann ein Knoten als letztes Kind unterhalb eines Elementseingefügt werden, sie ist der Konstruktor für die baumartige Hierarchie. Um die Übersichtlichkeitin der formalen Spezifikation zu verbessern, wird der Rückgabewert der Methode nur in derersten Definition betrachtet:

� Die Methode appendChild liefert den eingefügten Knoten.��

� appendChild �� appendChild ��

� Der Knoten � � soll bei�� eingefügt werden, obwohl er schon in dem Dokument an

��

existiert, dann entspricht dies dem einmaligen Einfügen von � � in�� . Mit anderen Worten

wird � � implizit aus�� entfernt und dann in

�� eingefügt.� �

� � appendChild �� appendChild ��

� � appendChild ��

Mit der Methode insertBefore werden Knoten in Elemente eingefügt. Falls der zweite Pa-rameter gesetzt ist, wird vor diesem Knoten ansonsten als letztes Kind dieses Elements in derHierarchie eingefügt. Der Rückgabewert der Methode wird nur in der ersten Spezifikation ange-geben:


� Die Methode insertBefore liefert den eingefügten Knoten.��

� insertBefore �� insertBefore ��

� Der Knoten � � soll vor � � � � eingefügt, werden, also muss er direkt vor dem Einfügen von� � � � als letzter Knoten eingefügt werden.� �

� appendChild �� insertBefore ��


� Der Knoten � � soll vor � � � � eingefügt werden, der aber nicht als letzter eingefügt wurde,dann kann man auch erst � � einfügen und dann den Knoten �� als letzten einfügen.� �

� appendChild �� insertBefore ��

� insertBefore �� appendChild ��

Mit der Methode removeChildwerden Knoten aus der Hierarchie entfernt. Sie liefert den ge-löschten Knoten als Rückgabewert, der wieder nur in der ersten formalen Spezifikation betrachtetwird:

� Die Methode removeChild liefert den gelöschten Knoten.��

� removeChild �� removeChild ��

� Die drei Attribute parentNode, previousSibling und nextSibling sind nichtmehr gesetzt, nachdem ein Knoten � � gelöscht wurde.

�� removeChild �� parentNode � � �

� � � previousSibling � � �� nextSibling � � �

� Soll das Element � � aus der Hierarchie entfernt werden, nachdem es zuvor eingefügt wur-de, heben sich die beiden Methoden auf.� �

� appendChild �� removeChild ��

� Soll ein Knoten � � gelöscht werden, nachdem ein anderer Knoten �� zunächst als letzterKnoten eingefügt wurde, kann auch erst das Element gelöscht und dann das letzte Elementeingefügt werden.� �

� appendChild �� removeChild ��

� removeChild �� appendChild ��


Die Methode replaceChild ersetzt einen Kinderknoten an einem Element durch einen neu-en Knoten. Der alte Knoten wird aus der Hierarchie entfernt. Der Rückgabewert wird wiederzunächst in der ersten Spezifikation festgelegt und dann vernachlässigt:

� Die Methode replaceChild liefert den zu ersetzenden Knoten.��

� replaceChild �� replaceChild ��

� Wird erst ein Knoten � � eingefügt und dann durch einen Knoten � � ersetzt, so kann auchnur der Knoten � � eingefügt werden.� �

� appendChild �� replaceChild ��

� appendChild �� Soll ein Knoten � � durch � � ersetzt werden und wurde zuvor ein weitere Knoten �� einge-

fügt, dann kann auch erst die Ersetzung vor dem Einfügen vorgenommen werden.� �� appendBefore �� replaceChild ��

� replaceChild �� appendChild ��

Das Attribut lastChild ermöglicht einen Zugriff auf das letzte Kind eines Elements, fallsdieses existiert:

� Nach dem Einfügen eines Knotens �� an letzter Stelle, verweist das Attribut lastChildauf diesen. � �

� appendChild �� lastChild � �

Mit dem Attribut firstChild wird der Zugriff auf das erste Kind eines Elements ermöglicht,falls dieses existiert:

� Wird ein Knoten � als erster Kinderknoten in ein Element�

eingefügt, so verweist dasAttribut firstChild auf diesen.� � � � �

� createElement �� appendChild �� firstChild � �

� Wurden mindestens zwei Knoten � � und � � � � in ein Element�

eingefügt und wird an-schließend auf den ersten Knoten mittels firstChild zugegriffen, so kann man auchvor dem Einfügen von � � � � auf das erste Element zugreifen.��


� � � �� firstChild

��

�� appendChild ��

� � � �� firstChild ��

� appendChild ��

��


1 i n t e r f a c e NodeLis t {2 Node i t em ( in uns igned long i n d e x ) ;3 readonly a t t r i b u t e unsigned long l e n g t h ;4 }

Listing 2.13: DOM-Schnittstelle NodeList

Die Methode childNodes liefert eine Liste mit den Kinderknoten eines Elements. Die Schnitt-stelle für die Liste NodeList ist in Listing 2.13 dargestellt. Das Attribut length gibt die Län-ge einer Liste an und die Methode item ermöglicht die indizierte Selektion einzelner Elementeaus der Liste. Leider wird in der Schnittstelle kein Konstruktor definiert, so dass eine formaleSpezifikation nur über die Methode childNodes für Knoten möglich ist:

� Ist ein Knoten � als letztes Kind an einem Element � eingefügt worden, so ermöglichtdie Methode item den Zugriff auf dieses, indem die Länge der Liste als Index übergebenwird. � �


� childNodes � item � � � childNodes � length �� Soll ein Element der Liste extrahiert werden, das nicht das letzte Element ist, so ist dies

unabhängig davon, ob das letzte Element vor oder nach dem Zugriff eingefügt wurde.�� appendChild ��

� childNodes � length ��

� childNodes � item � � ��

��

�� childNodes � length ��

� � � � �� childNodes � item � � ��


��

Ziemlich analog zur Spezifikation der Methode childNodes kann die Formalisierung derMethode getElementsByTagName erfolgen, wobei auf die entsprechenden Tagnamen derElemente Rücksicht genommen werden muss. Es werden dann nur die Kinderknoten in einerKnotenliste zurückgegeben, die sowohl Elemente sind, als auch mit ihrem Tag dem Parameterentsprechen.

Das Attribut attributes der Schnittstelle Element erlaubt den Zugriff auf die Attributeeines Elements. Diese werden in der Struktur NamedNodeMap vorgehalten, deren Schnittstellein Listing 2.14 zu sehen ist. Es sind drei Methoden vorgegeben, die den Zugriff auf Attribute,das Einfügen und das Löschen von Attributen regeln und folgender Formalisierung unterliegen:

� Wird ein Attribut�

erzeugt, auf den Wert � gesetzt und mit setNamedItem in die Map� eingefügt, so liefert getNamedItem anschließend dieses Attribut

�.��

� createAttribute �� value � � �� setNamedItem � � �

�� getNamedItem ��


1 i n t e r f a c e NamedNodeMap {2 A t t r getNamedItem ( in DOMString name ) ;3 A t t r setNamedItem ( in A t t r a r g ) ;4 A t t r removeNamedItem ( in DOMString name ) ;5 }

Listing 2.14: DOM-Schnittstelle NamedNodeMap

� Wird ein Attribut�� mit Namen � � erzeugt und in die Map � durch setNamedItem ein-

gefügt und wird außerdem ein Attribut�� mittels seines Namens � � über getNameItem

ausgelesen, so ist das Ergebnis unabhängig von der Reihenfolge der beiden Operationen,falls sich � � und � � unterscheiden.��

� createAttribute �� value � � �� setNamedItem � � � � �� getNamedItem ��

��

�

�� getNamedItem ��

� createAttribute �� value � � �� setNamedItem � � � �

��

�

� Ein zunächst mittels setNamedItem eingefügtes Attribut�� ist nach der Anwendung

der Operation removeNamedItem nicht mehr in der Map � .�� createAttribute �� value � � �� setNamedItem � � � �� removeNamedItem ��

��

�

� � � � �� createAttribute ��

� value � � � �� Die Operationen setNamedItem und removeNamedItem sind unabhängig in ihrer

Reihenfolge, falls die Operationen sich auf unterschiedliche Attribute beziehen.��

� createAttribute �� value � � �� setNamedItem � � � �� removeNamedItem ��

��

�

�� removeNamedItem ��

� createAttribute �� value � � �� setNamedItem � � �

��

�

Die Methoden setAttributeNode,getAttributeNode,removeAttributeNodewer-den analog den Methoden der Schnittstelle NamedNodeMap formalisiert, weshalb auf derenSpezifikation an dieser Stelle verzichtet wird.

Mit der Methode setAttributewird der Wert eines Attributs eines Elements neu gesetzt. Istdas Attribut noch nicht vorhanden, wird es erzeugt. Die Methode getAttribute liefert denaktuellen Wert eines Attributs, während das Löschen eines Attributs mit der Methode remove-Attribute erfolgt. Das Verhalten der Methoden wird durch folgende formale Spezifikationbestimmt:

� Die Methode getAttributewird durch die Methode getNamedItem aus der Schnitt-stelle NamedNodeMap (siehe Listing 2.14) definiert.�

� getAttribute �� getAttributeNode �� value

� Für die Methode setAttribute erfolgt eine Abbildung auf die Methode setName-dItem unter vorheriger Erzeugung eines neuen Attributs.

� �� setAttribute ��

��

� ownerDocument �createAttribute ��

� value � � �� setAttributeNode � � �

��

�

� Die Methode removeAttribute wird durch die Methode removeNamedItem spe-zifiziert.� �

� removeAttribute �� removeAttributeNode ��

Das Attribut attribute ermöglicht einen lesenden Zugriff auf die Attribute eines Elementsüber die Schnittstelle NamedNodeMap.

� Wird auf das Attribut attributes eines Elements�

die Operation getNamedItemangewendet, entspricht dies der Ausführung der Methode getAttributeNode für dasElement

�.�� attributes � getNamedItem ��

� getAttributeNode ��

Anwendungsbeispiele

Im restlichen Abschnitt werden zwei Beispiele für die Anwendung des DOM präsentiert.

Beispiel 2.8In diesem Beispiel wird das XML-Fragment

8 <book c a t a l o g =" V a r i a ">9 < t i t l e > L o t t e i n Weimar </ t i t l e >

10 <author >Thomas Mann </ author >11 < c o n d i t i o n > Einband f i n g e r f l e c k i g , Rücken

v e r b l a ß t </ c o n d i t i o n >12 8 . 0 0 </ pr ice >13 </ book>

des Dokuments aus Listing 2.1 betrachtet. Eine Erzeugung dieses Fragments aus einem Pro-gramm heraus wird unter Verwendung des DOM mit folgenden Anweisungen erreicht. Die Va-riable d ist dabei eine Variable der Schnittstelle Document und verweist auf ein Objekt, dasdiese implementiert.

1 bk = d . c r e a t e E l e m e n t ( " book " ) ;2 bk . s e t A t t r i b u t e ( " c a t a l o g " , " V a r i a " ) ;3 t t l = d . c r e a t e E l e m e n t ( " t i t l e " ) ;4 t t l . appendChi ld ( d . c r e a t e T e x t N o d e ( " L o t t e i n Weimar " ) ) ;5 a t h r = d . c r e a t e E l e m e n t ( " a u t h o r " ) ;6 a t h r . appendChi ld ( d . c r e a t e T e x t N o d e ( " Thomas Mann" ) ) ;7 c n d t n = d . c r e a t e E l e m e n t ( " c o n d i t i o n " ) ;8 c n d t n . appendChi ld ( d . c r e a t e T e x t N o d e ( " Einband f i n g e r f l e c k i g

, Rücken v e r b l a ß t " ) ) ;9 p r c = d . c r e a t e E l e m e n t ( " p r i c e " ) ;

10 p r c . appendChi ld ( d . c r e a t e T e x t N o d e ( " 8 . 0 0 " ) ) ;11 p r c . s e t A t t r i b u t e ( " c u r r e n c y " , "EUR" ) ;12 bk . appendChi ld ( t t l ) ;13 bk . appendChi ld ( a t h r ) ;14 bk . appendChi ld ( c n d t n ) ;15 bk . appendChi ld ( p r c ) ;

Es zeigt sich, dass mit der Anwendung der Methode createElement (1,3,5,7,9), create-textNode (4,6,8,10), setAttribute (2,11) und appendChild (4,6,8,10,12-15) aus demDOM das XML-Fragment auf einfache Weise im Programm kreiert werden kann. �

Da das DOM eine universelle Schnittstelle für XML-Dokumente bereitstellt, also für jede Aus-zeichnungssprache verwendbar ist, können auch ungültige Dokumente erzeugt werden, wie dasnachstehende Beispiel demonstriert.

Beispiel 2.9Es bezieht sich auf die Programmanweisung aus dem vorherigen Beispiel. In diesem sei diefolgende Zeile ausgetauscht.

5 a t h r = d . c r e a t e E l e m e n t ( " a r t i s t " ) ;

Dies führt zu DOM-Instanzen, die nachstehendes XML-Fragment repräsentieren:

8 <book c a t a l o g =" V a r i a ">9 < t i t l e > L o t t e i n Weimar </ t i t l e >

10 < a r t i s t >Thomas Mann </ a r t i s t >11 < c o n d i t i o n > Einband f i n g e r f l e c k i g , Rücken

v e r b l a ß t </ c o n d i t i o n >12 8 . 0 0 </ pr ice >13 </ book>

Für dieses Fragment ergibt die Überprüfung der Gültigkeit gemäß der Sprachbeschreibung ausBeispiel 2.2 eine Verletzung dieser Eigenschaft. �

Abschließend kann demnach festgestellt werden, dass das DOM eine universelle Schnittstellefür die Verarbeitung von XML in einer Programmiersprache bereitstellt. Sie realisiert einen ein-


heitlichen und austauschbaren Zugriff für XML-basierte Anwendungen. Eine Überprüfung derGültigkeit gemäß einer zu Grunde liegenden Sprachbeschreibung findet, wie das letzte Beispielzeigt, nicht statt. So kann im repräsentierten XML-Dokument beliebig eingefügt und gelöschtwerden, solange nur die Baumstruktur nicht verletzt wird.

2.3.3 Implementierungen und Erweiterungen

Nachdem im letzten Abschnitt die wichtigsten Schnittstellen des DOM definiert und deren An-wendung an Beispielen illustriert wurden, zählt dieser Abschnitt aktuelle DOM-Implementie-rungen auf und gibt einen Einblick in den aktuellen Stand des Standardisierungsprozesses. DasDOM definiert, wie gezeigt, lediglich Schnittstellen und legt nicht fest, wie diese zu implemen-tieren sind. Dies bedeutet für ein Programm, das das DOM einsetzen möchte, die Einbindungeiner DOM-Implementierung. Für die Programmiersprache Java sind inzwischen sowohl Imple-mentierungen namhafter Unternehmen, wie

� XML Parser for Java [IBM03] von IBM,

� Java API for XML Precessing (JAXP) [Sun01b] von Sun,

� XML Developer’s Kit for Java [Ora02] von Oracle,

als auch Open-Source-Entwicklungen, u. a.

� Xerces Java Parser [Apa01] vom Apache XML Project und

� GNU JAXP Project [Fre01] der Free Software Foundation

verfügbar. Durch die Festlegung aller Implementierungen auf den gemeinsamen Standard DOM

ergibt sich für den Entwickler der Vorteil, dass die eingesetzte DOM-Implementierung nahezubeliebig austauschbar ist.

Die Spezifikation des DOM gliedert sich in drei Ebenen („level“), die aufeinander aufbauen.Inzwischen wurde die 2. Ebene (DOM Level 2) als Empfehlung des W3C [W3C00a] herausge-geben. Gegenüber der 1. Ebene wird das Modell um zusätzliche Funktionalitäten erweitert. Sogibt es seitdem Schnittstellen zum Traversieren eines Dokuments und zur Selektion von Doku-mentbereichen. Zusätzlich wird ein Ereignismodell definiert und der Zugriff auf Präsentationsin-formationen, sogenannte Style-Sheets [W3C96, W3C98a], erlaubt. Auch können nun Dokumentedurch unterschiedliche Sichten („view“) angesprochen werden. Die gerade in Vorbereitung be-findliche dritte Ebene der Spezifikation definiert weiter Schnittstellen zum Laden und Speichernvon Dokumenten und zum Zugriff auf das Dokument über XPath-Ausdrücke. Darüber hinausgibt es Methoden, um die Gültigkeit eines Dokuments während der Laufzeit der Anwendung zuüberprüfen. Trotz dieser vielversprechenden Neuerung kann das DOM aber die statische Gültig-keit nicht zum Zeitpunkt der Programmübersetzung garantieren.


2.4 Verarbeitung syntaktischer Strukturen

Applikationen, die auf XML basieren, haben zweifellos mit der Verarbeitung syntaktischer Struk-turen [Lin79, Lin81] zu tun, einer gut 20 Jahre alten Idee, mit der sich unter anderem das Gebietdes Übersetzerbaus befasst. Im Folgenden soll der Aspekt der Verarbeitung von syntaktischenStrukturen, d. h. der Generierung und Umformung von Strukturen grammatikbasierter Sprachen,näher betrachtet werden.

Programmgeneratoren sind Programme, die mittels einer Eingabe Programmcode als Ausgabeerzeugen. Typische Beispiele hierfür sind Compiler-Compiler aus dem Übersetzerbau und CA-SE-Werkzeuge aus der Softwaretechnik. Beim Generieren von Programmen per Programm istes wesentlich, dass die erzeugten Programmteile syntaktisch korrekt sind. Ist dies nicht der Fall,kann das erzeugte Programm nicht ausgeführt werden. Für eine korrigierte Version muss daserzeugende Programm mit sämtlichen Eingaben erneut ablaufen.

Das Problem bei der Programmierung von Programmgeneratoren liegt nun darin, Sprachmittelzur Verfügung zu stellen, die es erlauben, bereits zur Zeit der Programmübersetzung eine Aus-sage darüber zu treffen, ob die vom übersetzten Programm erzeugten Programme syntaktischkorrekt sind. Es ist einsichtig, dass Ansätze zur Programmierung von Programmgeneratoren, diedie zu erzeugenden syntaktischen Strukturen – die Programme oder Programmteile – mit Ope-rationen auf Zeichenkettenebene verarbeiten, dieser Anforderung nicht gerecht werden können.Fehler können bei diesem Verfahren lediglich empirisch, durch aufwendiges Testen ausgeschlos-sen werden. Zur Lösung dieses Problems muss eine Sprachbeschreibung, die in der Regel inForm einer Grammatik definiert ist, für die zu erzeugenden syntaktischen Strukturen vorliegen.Dabei werden für die Nichtterminalsymbole der Grammatik neue Datentypen definiert und zu-geordnet, was im Wesentlichen der abstrakten Syntax entspricht. Zusätzlich werden Operationeneingeführt, die es erlauben, aus Werten der Basisdatentypen diese Nichtterminaltypen zu erzeu-gen, sowie weitere Operationen, um nach unterschiedlichen Regelvarianten zu selektieren.

Die Konstruktoroperationen, die Werte der Nichtterminaltypen erzeugen, erhalten als Parametersyntaktische Strukturen in konkreter Syntax, die zusätzlich auch, an zur zu Grunde liegendenSprachbeschreibung konformen Positionen, Variablen der Nichtterminaltypen enthalten können.Damit ist es möglich, dass bereits generierte Strukturen ineinander geschachtelt werden können,und nicht nur von links nach rechts erzeugt werden müssen, was bei einer Verarbeitung aufZeichenkettenebene erforderlich ist. Dies hat den Vorteil, dass der Anwendungsprogrammierernicht ausschließlich mit der ungewohnten abstrakten Syntax arbeiten muss, sondern weiterhindie vertrautere konkrete Syntax einsetzen kann.

Eine Übersetzung dieser Generatorprogramme geschieht mit einem erweiterten Compiler, derneben dem eigentlichen Programm zusätzlich die zu Grunde liegende Grammatik der zu gene-rierenden syntaktischen Strukturen einliest und berücksichtigt. Der wesentliche Vorteil diesesVorgehens besteht, neben einer übersichtlicheren Programmstruktur, in der Sicherstellung dersyntaktischen Korrektheit der durch das Programm generierten syntaktischen Strukturen zur Zeitder Programmübersetzung. Die Einschränkungen werden darin gesehen, dass für große Gram-

2.5. WEB-ANWENDUNGEN 41

matiken möglicherweise eine hohe Anzahl von Nichtterminaltypen entstehen und darin, dassbei Prozeduren, die auf unterschiedlichen Nichtterminaltypen arbeiten, aber die gleiche Funk-tionalität erfüllen, durch das strikte Typsystem eine mühsame und aufwendige Implementierungnotwendig wird.

Es liegt auf der Hand, dass sich der beschriebene Ansatz sehr gut für eine ProgrammiermethodikXML-basierter Anwendungen adaptieren lässt. Denn die zu verarbeitenden XML-Dokumentesind ebenfalls syntaktische Strukturen und eine Sprachbeschreibung ist in Form einer DTD odereines XML-Schemas gegeben.

2.5 Web-Anwendungen

Nachdem in Abschnitt 2.1 die Extensible-Markup-Language vorgestellt wurde, die eine uni-verselle Möglichkeit für den Datenaustausch vorsieht, wendet sich dieser Abschnitt dem World-Wide Web (WWW) zu, dem mittlerweile größten und am meisten genutzten Informationssystem.Mit der Hypertext-Markup-Language (HTML) realisiert das WWW sicherlich die am weitestenverbreitete Anwendung von XML.

Das World-Wide Web, das sich im wissenschaftlichen Umfeld entwickeln konnte, wird inzwi-schen zum Großteil kommerziell genutzt. Betrachtet man die breiten Nutzungsmöglichkeiten,die das Web inzwischen bietet, angefangen von Bankanwendungen bis hin zum Versandhaus,so kann man nicht mehr nur von einer bloßen Informationssammlung oder einem Hyperlinksys-tem im ursprünglichen Sinne sprechen. Vielmehr werden von einzelnen Anbietern vollwertigeAnwendungen realisiert, die das WWW lediglich als Infrastruktur der Implementierung nutzen;Anwendungen dieser Art werden im folgenden als Web-Anwendungen bezeichnet.

Der Abschnitt beginnt mit einer grundlegenden Einführung in den Aufbau des Internets, umein Verständnis für die Problematik zu schaffen, bevor auf die verschiedenen Aspekte der In-formationspräsentation im WWW eingegangen wird. Als weiterführende Literatur sei an dieserStelle auf [Kro95, Tol97b] verwiesen. Die traditionelle Präsentation statischer Dokumente wirdin Abschnitt 2.5.2 vorgestellt, während im Nachfolgenden die erweiterten Ansätze für dynamischerstellten Inhalt diskutiert werden.

2.5.1 Das Internet und seine Dienste

Das Internet wird gebildet von einem weltweiten Verbund von Rechnern, die über ihre Ver-knüpfungen untereinander Daten austauschen. Die Computer werden durch sogenannte Internet-Protokoll-Adressen (IP-Nummern) eindeutig identifiziert. Trotz der Notwendigkeit von eindeu-tigen IP-Nummern sind die Rechner im Internet nicht hierarchisch strukturiert, was ursächlichin den militärischen Anfängen begründet liegt. Eine der damaligen Hauptanforderungen an dasNetz war eine möglichst hohe Ausfallsicherheit. Mit einer dezentralen, netzartigen Organisati-


on, die wesentlich zum Erfolg des Internets beitrug, kann im Gegensatz zu einer hierarchischenStruktur diese Anforderung besser erfüllt werden. Trotzdem muss die Eindeutigkeit der IP-Num-mern sichergestellt werden, was durch eine zentrale Vergabe geschieht. Zusätzlich werden durchdas Domain-Name-System (DNS) Rechnernamen vergeben, denen die IP-Nummern der Rechnereindeutig zugeordnet werden, um das Arbeiten mit Computern im Internet für die Anwender zuvereinfachen.

Damit eine Kommunikation im Internet über unterschiedliche Software- und Hardware-Grenzenhinweg überhaupt funktioniert, müssen die eingesetzten Protokolle standardisiert sein. Im In-ternet erfolgt dies durch die Request-For-Comments-Dokumente (RFC). In diesen werden dieeinzelnen Protokolle definiert und beschrieben, die sich unterschiedlichen logischen Schich-ten (ähnlich dem ISO/OSI-Schichtenmodell (ISO 7498) [Int94, Tan96]) zuordnen lassen. Je-de Schicht implementiert und kapselt eine bestimmte Funktionalität, auf die die nächsthöhereSchicht aufbauen kann. In dieser hierarchischen Anordnung befinden sich auf der untersten Ebe-ne die Netzprotokolle der lokalen Netzwerksysteme, wie z. B. das Ethernet. Auf der nächstenEbene, auf der auch das Internet-Protocol (IP) anzusiedeln ist, werden Netzverbindungsproto-kolle realisiert, die für Verknüpfungen zwischen lokalen Netzwerksystemen sorgen. Darauf auf-bauend liegt die Schicht der Transportprotokolle, in der das Transfer-Control-Protocol (TCP) füreine zuverlässige Kommunikation sorgt. Damit wird die korrekte Auslieferung von Daten zwi-schen verschiedenen Rechnern sichergestellt. Ganz oben in der Protokollhierarchie liegen die so-genannten Dienstprotokolle, die im Weiteren angesprochen werden. Der Benutzer braucht keinegenaue Kenntnis über die technischen Details und den Aufbau der einzelnen Protokollschichtenzu haben, lediglich die Funktionalität der Dienstprotokolle sollte dem Benutzer bekannt sein,damit er diese sinnvoll einsetzen kann.

Dienstprotokolle, oder kurz Dienste, realisieren praktisch schon spezielle Anwendungen, durchdie das Internet erst sinnvoll genutzt wird. Die verschiedenen Dienste verrichten eine Vielzahlvon unterschiedlichen Funktionalitäten. Um einen Dienst auf einem entfernt liegenden Rechnerzu nutzen, muss dieser den Dienst implementieren, d. h. es muss ein Programm gestartet sein undablaufen, das das zugehörige Dienstprotokoll versteht. Ist dies der Fall, ist es möglich durch einentsprechendes ausführbares Programm von einem anderen Computer aus, den entfernt liegen-den Rechner mittels dieses Dienstes zu erreichen. Beispielsweise ist es mit dem sehr einfachenDienst ping möglich, zu ermitteln, ob ein bestimmter Rechner vom aktuellen Computer aus überdas Internet erreichbar ist. Weitere Dienste sind der Dienst telnet, mit dem es möglich ist, sichauf einem entfernt liegenden Rechner anzumelden und auf diesem zu arbeiten, der Dienst ftp(File Transfer Protocol), mit dem Dateien zwischen zwei Rechnern hin- und herkopiert werdenkönnen, und der Dienst zum Verschicken von elektronischer Mail (Email) mittels SMTP (SimpleMail Transfer Protocol).

Der populärste Dienst des Internets ist aber inzwischen das World-Wide Web, für das der BegriffInternet bereits zum Synonym geworden ist. Das Hypertext-Transfer-Protocol (HTTP) realisiertdiesen Dienst. Die folgenden Zahlen verdeutlichen mit welcher raschen Geschwindigkeit dasWachstum des Internets erfolgte. Waren im Januar 1993 weltweit erst 1.313.000 Rechner ansInternet angeschlossen, betrug die Anzahl im Januar 2003 bereits 171.638.297 [Int03]. Ähnlich


rasant ist die Entwicklung bei den im Internet arbeitenden WWW-Servern, die von 130 Rechnerim Juni 1993 auf 40.444.778 im Mai 2003 anwuchsen [Net03]. Damit hat das WWW wesentlichzur Verbreitung des Internets beigetragen.

Die Arbeitsweise des Webs folgt einer typischen Client/Server-Architektur. WWW-Server hal-ten dabei Daten und Informationen vor, die von Client-Rechnern im Internet bei Bedarf abge-rufen werden können. Client-Rechner können sich also, falls notwendig, mit Servern verbindenund mittels eines geeigneten Programms dort abgelegte Informationen darstellen und verarbeiten.Dies leisten unter anderem die weit verbreiteten grafischen WWW-Browser Netscape Communi-cator oder Internet Explorer. Jeder Internetteilnehmer kann aber nicht nur über einen Browser imWWW abgelegte Informationen nutzen, sondern er kann zusätzlich auch einen eigenen WWW-Server einrichten, dort eigene Daten ablegen und damit zum Informationsangebot im Web beitra-gen. Ein solcher Rechner sollte aber sinnvollerweise permanent arbeiten und dauerhaft mit demInternet verbunden sein.

2.5.2 Präsentation von statischen Dokumenten

Wie bereits im letzten Abschnitt erwähnt stellen WWW-Server Daten und Informationen zurVerfügung. Diese Daten werden sehr häufig in Form einer Datei abgelegt. Jede Datei wird dabeimit dem Uniform-Resource-Locator (URL) [BLMM94] im Web eindeutig identifiziert. DieseURL-Adresse besteht im ersten Teil zunächst aus der Art der Übertragung, dem Dienstproto-koll. Durch diese Angabe ist es möglich, dass WWW-Browser nicht nur die Kommunikationüber den Dienst HTTP realisieren, sondern zusätzlich auch eine Verbindung über andere Dienstewie beispielsweise ftp erlauben. In einem zweiten Teil wird der Server eindeutig identifiziert,was sowohl über seinen vom DNS verwalteten Rechnernamen als auch durch seine IP-Adressegeschehen kann. Der letzte Teil besteht aus einer Pfadangabe und dem Dateinamen der bereitge-stellten Datei.

Das World-Wide Web legt nicht fest, in welchem Format die auf den Web-Servern abgelegten Da-teien vorliegen müssen. Damit besteht die Möglichkeit, Informationen in jeder Form abzulegen.Verbreitet sind Daten im Textformat (ASCII-Dateien), als Dokumente (PS- und PDF-Dateien)bis hin zu Bildern (JPEG, GIF u. a.) sowie Audio- und Video-Dateien. Selbst die Übertragungvon ausführbaren Programmen in Binärformat oder Bytecode (Java) ist möglich.

Die meisten Dateien oder Dokumente, die Informationen im WWW bereithalten, liegen aller-dings im Format der Hypertext-Markup-Language (HTML) [RLHJ97] vor, für deren Übertra-gung im Internet das Hypertext Transfer Protocol (HTTP) vorgesehen ist. Bei HTML handelt essich um eine Anwendung von SGML und inzwischen unter dem Namen XHTML auch von XML

[W3C00b], die für die Speicherung von Informationen in Form eines Hypertextsystems ausgelegtist. Die im Hypertextsystem abgelegten Daten, man spricht auch von Seiten, werden durch einenBrowser dem Benutzer geeignet präsentiert. Ein Hypertextsystem zeichnet sich durch sogenann-te Hyperlinks aus, die verschiedene Dokumente oder Dokumentteile miteinander verknüpfen.Diese Verknüpfung wird vorgenommen, um weitere Informationen zu den vorliegenden Daten

in Beziehung zu setzen. Die durch einen Hyperlink referenzierte Datei kann sich wiederum aufbeliebigen WWW-Servern im Internet befinden und wird mittels ihrer URL adressiert. DemBenutzer bietet sich während der Präsentation einer Seite im Browser die Möglichkeit durch An-wählen von Hyperlinks, auf verwiesene Seiten zu verzweigen. Eine ausführliche Beschreibungvon HTML findet sich in [Tol97a]; das nachstehende Beispiel gibt einen Eindruck von HTML.

Beispiel 2.10Im Folgenden ist eine HTML-Seite als Ergebnis einer möglichen Suche im zentralen Verzeichnisantiquarischer Bücher zu sehen:

1 <html >2 <head >< t i t l e > S u c h e r g e b n i s </ t i t l e > </ head >3 <body>4 <h1> S u c h e r g e b n i s im V e r z e i c h n i s vom 2 0 . 2 . 2 0 0 2 </h1>5 Die f o l g e n d e n T i t e l wurden ge funden : 6 <ul >7 < l i >8 Thomas Mann , L o t t e i n Weimar ,9 Einband f i n g e r f l e c k i g , Rücken v e r b l a ß t .

EUR 8 . 0 0 10 St . J ü r g e n A n t i q u a r i a t , B e s t e l l u n g

an :11 <a hre f =" m a i l t o : s t . j u e r g e n a n t i q u a r i a t @ t �

o n l i n e . de ">12 s t . j u e r g e n a n t i q u a r i a t @ t � o n l i n e . de </a> 13 </ l i >14 < l i >

...

25 </ l i >26 </ ul >27 <hr> </ hr>28 <a hre f =" suche . h tml ">Neue Suche </a>29 </ body>30 </ html >

Listing 2.15: Dokument in HTML

Sie zeigt die Auflistung der gefundenen Bücher. Zusätzlich wird für jedes Buch aufgeführt, wel-ches Antiquariat es führt. Über einen Hyperlink ist es möglich, eine Email als Bestellung an dasentsprechende Antiquariat zu versenden. Am Fuße der Seite kann mit einem weiteren Hyperlinkerneut auf die Seite für die Suche verzweigt werden.

Die Darstellung des Dokuments im Browser ist in Abbildung 2.1 zu sehen. �


Abbildung 2.1: Anzeige des HTML-Dokuments im Browser.

HTML ist eine Auszeichnungssprache zur Präsentation von Web-Seiten. Die ursprüngliche Ideevon SGML, die logischen Dokumentenstruktur von der eigentlichen Präsentationsgestaltung durchden Browser strikt zu trennen, ist in HTML mit der Zeit mehr und mehr abgeschwächt worden.Durch eine Vielzahl neuer Elementtypen in den jüngsten Versionen, die ausschließlich der For-matierung und Präsentation des Inhalts dienen, wird HTML dem Anspruch von SGML immerweniger gerecht. Die Unzufriedenheit an dieser Entwicklung ist mit ein Grund, der zur Spezifi-kation von XML beitrug.

2.5.3 Dynamisierung des Webs auf der Client-Seite

Mit statischen HTML-Seiten ist es möglich, Informationen über das WWW einer breiten Öf-fentlichkeit zu präsentieren. Was nicht realisiert werden kann, ist ein Dialog mit dem Nutzer derangebotenen Informationen. Diese Einschränkung war die Hauptmotivation, die zur Entwicklungeiner Reihe von Technologien führte, um den Dialog zwischen Benutzer und dem Web-Serverzu ermöglichen. Informationssysteme, die diese Art von Kommunikation realisieren, werden imFolgenden als Web-Anwendungen bezeichnet. Typische Web-Anwendungen sind beispielsweiseBanken, Versandhäuser und Auktionshäuser im WWW. Viele dieser Programme sind außerdeman ein eigenständiges Datenbanksystem angeschlossen, und verknüpfen damit dieses mit demWeb.

Nötig für einen Dialog im WWW ist einerseits die Eingabe von Daten auf der Clientseite, alsauch eine Übertragung der Daten auf den Server, sowie deren dortige Verarbeitung. Mit Formu-


laren in HTML existiert bereits eine einfache Form zur Übermittlung von Daten vom Benutzer andie Web-Anwendung. Weitere Möglichkeiten, die zusätzlich mit einer stärkeren Dynamisierungder Anwendung auf der Client-Seite einhergehen, wie ECMA-Script und Applets, werden in die-sem Abschnitt vorgestellt. Dadurch wird es möglich, dass Web-Anwendungen für den Benutzerein ähnliches Eingabeverhalten zeigen, wie dieser es von Standardprogrammen her gewohnt ist.

ECMA-Script

Die von der European Computer Manufacturers Association (ECMA) standardisierte Program-miersprache ECMA-Script [ECM99] findet sich im Browser unter der Bezeichnung Java-Script[Net97a] wieder. Damit ist es möglich, Programmteile in eine HTML-Seite zu integrieren. DerJava-Script-Teil wird dabei durch ein spezielles Element von HTML abgegrenzt.

Da es sich bei Java-Script um eine Skriptsprache handelt, wird das Programm erst zur Laufzeitübersetzt und ausgeführt. Dies geschieht allerdings nicht auf der Server- sondern auf der Client-Seite einer Web-Anwendung, nachdem das Dokument heruntergeladen wurde. Selbst Teile deraktuellen HTML-Seite können damit dynamisch generiert werden, was entweder auf der Ebenevon Zeichenketten erfolgt oder durch den Zugriff auf die DOM-Repräsentation des Dokumentsgeschieht. Ein großer Vorteil von Java-Script ist die mögliche Verlagerung von Rechenschrittenvom Server auf den Client-Rechner. Für den Benutzer einer Anwendung stellt die Interpreta-tion von unbekannten Programmen allerdings ein Sicherheitsproblem dar, denn er kann nichtsicher sein, dass nur unschädlicher Code ausgeführt wird. Um dieses Problem zu entschärfen, istdie Ausführung von Java-Script-Programmen nur unter erheblichen Einschränkungen gestattet;beispielsweise ist kein Zugriff auf die lokale Festplatte möglich.

Java Applets

Die Programmiersprache Java [AG98] erhebt den Anspruch, die Programmiersprache für Web-Anwendungen zu sein. Sie ist objektorientiert und besitzt ein striktes Typsystem. Der Java-Über-setzer erzeugt einmalig prozessorunabhängigen Zwischencode, den sogenannten Bytecode, derzur Ausführung von der Laufzeitumgebung („Java Virtual Machine“) (JVM) interpretiert wird.Durch die Generierung des Bytecodes, sind Java-Programme auf nahezu allen Rechner-Archi-tekturen lauffähig, also plattformunabhängig. Aus diesem Grund ist die Sprache gut für Anwen-dungsteile auf der Client-Seite geeignet. Java-Programme, die auf dem Client-Rechner ablaufen,heißen Java Applets. Für deren Ausführung wird der Bytecode vom Server auf den Client über-tragen und in der dortigen JVM des Browsers interpretiert. Im Vergleich zu Anwendungen inprozessorabhängigem Maschinencode sind Programme als Bytecode in der Ausführung meistlangsamer. Durch die Integration von sogenannten Just-In-Time-Übersetzern („JIT compiler“) indie JVM wird aber versucht, diesem Nachteil zu begegnen.

Java selbst ist eine vollwertige höhere Programmiersprache, die dem Programmierer einiges bie-tet. So steht mit der Java-API („application programming interface“) [Sun01a] eine sehr um-


fangreiche Klassenbibliothek zur Verfügung. Dadurch ist es unter anderem möglich, auf ein-fache Weise eine komfortable grafische Benutzeroberfläche zu gestalten. Problemlos möglichist auch die Anbindung einer Anwendung an ein Datenbanksystem. Dafür existieren die daten-bankunabhängig definierten Schnittstellen JDBC („Java Database Connectivity“) [EHF01] undSQLJ („Standard Query Language for Java“) [SBK

�99]. Mit diesen kann eine Java-Anwendung

durch das Erzeugen entsprechender SQL-Anweisungen Anfragen an eine Datenbank stellen undDaten in der Datenbank manipulieren oder löschen. Damit der Zugriff über JDBC oder SQLJvon Java aus auf ein Datenbanksystem möglich wird, muss dieses einen entsprechenden Treiberbereitstellen, der die Verbindung zwischen Java und der Datenbank herstellt.

2.5.4 Dynamisierung des Webs auf der Server-Seite

In diesem Abschnitt werden verschiedene, existierende technische Ansätze vorgestellt, die es er-lauben, HTML-Dokumente oder, allgemeiner, XML-Dokumente dynamisch auf dem Web-Serverzu generieren.

Common Gateway-Interface

Eine der ältesten Möglichkeiten für die Erzeugung dynamischer Dokumente durch eine Web-An-wendung wurde durch das Common Gateway-Interface (CGI) [CAR98, Gai95, Gun96] bereits1995 definiert. Diese Schnittstelle erlaubt es, ein beliebiges Programm mit einer festen URL zuverknüpfen. Bei der Anwahl dieser URL durch einen Benutzer, wird vom WWW-Server nichteine statische Seite an den Browser zurückgeschickt. Stattdessen wird das zugehörige, exter-ne Programm vom WWW-Server zur Ausführung gebracht. Dieses externen Programm ist nundafür zuständig, eine korrekte Web-Seite zu erzeugen.

Durch CGI wird eine Schnittstelle normiert, die regelt, wie dem externen Programm Daten undParameter vom Web-Server übergeben und wie vom externen Programm die generierten Web-Seiten zum Web-Server zurückgeliefert werden. Mit CGI können durch ein externes Programmaktuelle Informationen in Form von HTML für Anwender präsentiert werden. Ein manuelles Er-stellen von Seiten ist in diesem Fall nicht notwendig und in der Regel nicht möglich, da diedynamisch erzeugten Seiten häufig von aktuellen Parametern und Daten abhängen. Für das Ein-lesen von Daten zur Übertragung an das externe Programm können beispielsweise Formulare inHTML genutzt werden.

Erfolgt die Implementierung einer CGI-Anwendung in einer Programmiersprache, die ihre aus-führbaren Programme in nativen Programmcode übersetzen, so wird das Programm dadurchplattformabhängig, eine Eigenschaft, die man bei Web-Anwendungen meist vermeiden möch-te. Um trotz der Realisierung mittels CGI eine Plattformunabhängigkeit zu erreichen, wird dieWeb-Anwendung häufig in einer Skriptsprache wie Perl [WS92] oder Ruby [Mat01] realisiert.Auch bieten Skriptsprachen im Vergleich zu gängigen Standardprogrammiersprachen eher eine


Unterstützung von CGI durch Bibliotheksfunktionen.

Ein weiterer Nachteil von CGI ist, dass durch das zustandslose Übertragungsprotokoll HTTPeine Kommunikation des Benutzers mit der Web-Anwendung über mehrere Web-Seiten hinwegnur mit erhöhtem Aufwand möglich ist. Man spricht bei HTTP auch von einer gedächtnislosenVerbindung. Die Erweiterung FastCGI [Bro96] ermöglicht solche dauerhaften Verbindungen.

Die externen Programme in CGI werden in einem eigenen Prozess ausgeführt. Das Ablaufen ineinem neuen Prozess für jedes externe Programm wird als Nachteil von CGI angesehen, da dasErzeugen eines neuen Prozesses durch das Betriebssystem mit erheblichen Aufwand verbundenist. Andererseits hat es den Vorteil, dass bei einem Absturz des externen Programms durch einenunberücksichtigten Fehler in der Anwendung nicht auch der Web-Server selbst beendet wird.Dieses Verhalten kann bei Web-Anwendungen auftreten, die nicht durch CGI sondern über ei-ne spezielle Schnittstelle des Web-Servers [Net97b, Apa00] Parameter und Daten austauschen.Diese alternative Implementierungstechnik von Web-Anwendungen wird häufig auch als Server-API bezeichnet. Sie wird in dieser Arbeit nicht weiter vertieft; es sei auf die angegebene Literaturverwiesen.

Server-Side Includes

Eine andere Möglichkeit, um HTML-Seiten mit dynamischen Daten zu erzeugen, ist mit denServer-Side Includes (SSI) [Gun96, Inf97a, Apa03] gegeben. SSI, die auch als „parsed HTML“bezeichnet werden, reichern statische HTML-Seiten zur Laufzeit um weitere Daten, die beispiels-weise aus einer Datenbank stammen können, an. Dabei haben die statischen HTML-Seiten zu-sätzlich spezielle Markierungen, die über HTML hinausgehen, um deutlich zu machen, an wel-chen Stellen welche Änderungen zur Laufzeit vorgenommen werden sollen. Die Anweisungen inden Markierungen der erweiterten Seiten werden vom Web-Server selbst oder von einem spezi-ellen CGI-Programm ausgeführt. Die Ergebnisse werden anschließend in die umgebende HTML-Seite integriert und an den Anwender übermittelt. Die zusätzlichen Markierungen einer für SSIausgelegten, erweiterten HTML-Seite werden in der Regel von einem Web-Server, der kein SSIunterstützt, als Kommentar behandelt.

Java Servlets

Die Java Servlets [Cow01, HC98, Wil99] sind eine Implementierungsmöglichkeit für Web-An-wendungen, bei der die Funktionalität einer Programmiersprache, in diesem Fall Java [AG98], inden Web-Server integriert wurde. Die Laufzeitumgebung von Java läuft dabei permanent im Hin-tergrund des Web-Servers, der bei Bedarf einen neuen Java-Thread eines Servlets startet. Servletssind dabei ganz normale Java-Anwendungen. Der Programmierer einer Web-Anwendung erhältmit der Entwicklungsumgebung für Servlets neben der Standard-Java-Bibliothek weitere Biblio-theksfunktionen, die den Komfort erhöhen. So gibt es Methoden zum automatischen Einlesenund Dekodieren von HTTP-Anfragen, zum Lesen und Schreiben von HTML sowie zur Verarbei-


tung von sogenannten Sitzungen, also dauerhaften Verbindungen zum Anwender. Dadurch kanneine Web-Anwendung auch eine permanente Datenbankverbindung etablieren. Die Kommuni-kation eines Servlets mit dem Web-Server erfolgt direkt und der Austausch von Daten zwischeneinzelnen Servlets ist ohne Umwege möglich.

Im Vergleich zu CGI bieten Servlets einige Vorteile. Zunächst ist eine als Servlet implementier-te Web-Anwendung plattformunabhängig und damit ohne erneute Übersetzung portierbar alleindurch die Wahl der Programmiersprache Java. Weiterhin ist ein Servlet effizienter als ein CGI-Programm, weil nicht stets ein neuer Prozess gestartet werden muss. Stattdessen wird bei Be-darf ein weniger aufwendiger Java-Thread aktiviert. Wird eine Web-Anwendung, die mit CGIumgesetzt wurde, mehrfach aufgerufen, so liegt auch der ausführbare Programmtext dieser An-wendung mehrfach im Speicher. Bei einer Servlet-Realisierung, die mehrfach abläuft, wird derProgrammtext stattdessen nur einmal in den Speicher geladen. Die Servlet-Engine startet nämlichin diesem Fall mehrere Threads, die alle auf die selbe Java-Klasse im Speicher zurückgreifen.Außerdem besitzt die Servlet-Engine noch Optimierungsmöglichkeiten für die zu ladenden Java-Klassen durch Caching.

JavaServer-Pages

Was SSI für CGI ist, sind die JavaServer-Pages (JSP) [PL01, PLC99, FK00] für Java Servlets.JSP bestehen aus statischen XML- oder HTML-Dokumenten, die mit reinen Java-Anweisungenangereichert sind. Diese Anweisungen generieren zur Laufzeit weitere XML- oder HTML-Frag-mente, die in die statische Seite an den entsprechenden Stellen eingesetzt werden. Da JSP vomJSP-Präprozessor in Servlets umgesetzt werden, kann man JSP als Servlet-Aufsatz interpretie-ren. Durch unterschiedliche Typen spezieller Elemente in JSP können die eingebetteten Java-Anweisungen in JSP so voneinander unterschieden werden, dass diese an verschiedenen Stel-len in das resultierende Servlet übersetzt werden. Damit wird der Programmaufbau von Servlet-Klassen in JSP reflektiert. Während der Ausführung der Web-Anwendung werden dann die ausden JSP erzeugten Servlets ausgeführt. Liegt für eine Seite noch kein Servlet vor, wird diesesdynamisch generiert und anschließend ausgeführt.

Als großer Vorteil von JSP wird die durch sie mögliche Trennung von Präsentationslayout undProgrammlogik angeführt. Dabei soll in einer Web-Anwendung die Präsentation mit Hilfe vonJSP realisiert werden, während die Programmführung mit Servlets implementiert wird. Eine An-wendung besteht demnach aus einer Kombination von JSP und Servlets.

2.5.5 Diskussion

Es folgt eine kurze Zusammenfassung der vorgestellten Web-Technologien.

Die Fülle unterschiedlicher Techniken für die Implementierung von Web-Anwendungen, die indiesem Abschnitt dargestellt wurden, lässt erkennen, dass sich mit der fortschreitenden Nutzung


des World-Wide Webs die Anforderungen an das System veränderten. Jede neue Aufgabe brach-te dabei ein neue technische Lösung mit sich, die nur selten eine vorherige erweiterte. Mit denstatischen Dokumenten eines Hypertextsystems, auf die der Benutzer lediglich lesend zugreifenkonnte, begann die Anwendung des WWW. Es folgte schnell die Forderung nach Web-Anwen-dungen mit dynamischen Web-Seiten und Interaktivität zur Übermittlung von Benutzereingaben.Diese weitreichenden Veränderungen erforderten sowohl eine Erweiterung der Client-Seite (Ja-va-Script, Applets), als auch eine Anpassung auf der Server-Seite (CGI). Da durch die Weiter-entwicklung der Server-Seite für jeden Benutzer stets ein neuer Prozess gestartet wird, wurde sieschnell als zu schwerfällig kritisiert. Es kam zur Entwicklung direkter Schnittstellen zum Server,um die Anwendung im Serverprozess selbst ablaufen zu lassen (Server-API). Gleichzeitig wurdeeine einfache Unterstützung für weitgehend konstante Web-Dokumente erarbeitet (SSI).

Doch die vollständige Integration der Programmteile einer Web-Anwendung in den Server birgtden Nachteil, dass bei fehlerhafter Implementierung der gesamte Web-Server zusammenbrechenkann. Weitere Nachteile, wie Abhängigkeit von bestimmten Serverimplementierungen und vonbestimmten Rechnerarchitekturen, auf denen der Server mit der Anwendung ausgeführt wird,konnten mit dem Einsatz der Programmiersprache Java für Web-Anwendungen (Servlets) über-wunden werden. Java bietet zusätzlich den Vorteil, dass das Programm nicht in einem separaten,aufwendigen Prozess ablaufen muss, sondern in einem eigenständigen, weniger aufwendigenThread ausgeführt wird, der dadurch die Stabilität des Web-Servers nicht gefährdet. Selbst dieeinfache Einbindung weitgehend konstanter Web-Seiten ist vorgesehen (JSP).

Die folgende Tabelle fasst die Eigenschaften in den Spalten für alle vorgestellten Technologien,die in den Zeilen aufgeführt sind, zusammen. Trifft für eine Technik eine Eigenschaft zu, so wird

programmiersprachen- eigenständiger server- portier- plattform-unabhängig Prozess/Thread unabhängig bar unabhängig

CGI � P � � / � � / �

Server-API � � � � �

SSI � � / � � � �

Servlets � T � � �JSP � T � � �

der Eintrag mit einem � markiert, ansonsten wird ein � angegeben. Beispielsweise ist CGI un-abhängig von einer konkreten Programmiersprache definiert ( � ), läuft in einem eigenen Prozess(P) und ist unabhängig von einer konkreten Serverimplementierung ( � ). Die Portierbarkeit unddie Plattformunabhängigkeit4 hängen bei CGI aber von der gewählten Programmiersprache ab( � / � ). Für Java wird zusätzlich der Ablauf im eigenen Thread (T) angezeigt.

Durch die inzwischen weitverbreitete kommerzielle Nutzung des WWW ist erkannt worden,dass eine Standardisierung von Auszeichnungssprachen, Protokollen und Programmierschnitt-

4Der wesentliche Unterschied zwischen den Eigenschaften Portierbarkeit und Plattformunabhängigkeit liegt dar-in, dass der Quelltext portierbarer Programme für unterschiedliche Rechnerarchitekturen angepasst und neu über-setzt werden darf. Dies ist bei plattformunabhängigen Programmen nicht erlaubt.

2.6. VERARBEITUNG UND REPRÄSENTATION VON XML 51

stellen notwendig ist. Im Rahmen des W3C, dem Zusammenschluss der an einer Standardisie-rung interessierten Firmen und Organisationen, wird dies durchgeführt und vorangetrieben. DasZiel ist ein weiteres Divergieren der Darstellungsmöglichkeiten von Informationen im Web sowievon deren Übertragungsarten zu unterbinden.

2.6 Verarbeitung und Repräsentation von XML

Der letzte Abschnitt präsentierte Technologien zur Implementierung von Web-Anwendungen.Dieser Abschnitt konzentriert sich auf technische Möglichkeiten zur Verarbeitung und Repräsen-tation von XML-Dokumenten und XML-Fragmenten in Programmiersprachen. Dies ist eine fürWeb-Anwendungen wichtige Fähigkeit, da diese die übermittelten Daten auf dem Server verar-beiten und mit zur Laufzeit generierten XML-Fragmenten beantworten. Es werden verschiedene,existierende technische Ansätze kurz vorgestellt, die es erlauben, HTML-Dokumente oder, all-gemeiner, XML-Dokumente zu verarbeiten. Primär unterscheiden sie sich in der Repräsentationder XML-Fragmente.

Der Abschnitt gliedert sich in vier Teile. Als erstes wird auf die Verarbeitung von XML aufder Basis von Zeichenketten eingegangen. Anschließend werden Methoden, die erst einfache,später höhere Objektmodelle verwenden, beschrieben und abschließend erfolgt die Darstellungvon Ansätzen, die die statische Gültigkeit zur Zeit der Programmübersetzung garantieren.

2.6.1 Verarbeitung von XML als Zeichenkette

Der einfachste Weg, um XML in einem Programm zu verarbeiten, besteht in der Verwendung dervon der Programmiersprache zur Verfügung gestellten Datentypen für Zeichenketten und dendarauf aufbauenden Operationen. XML-Fragmente werden dann wie gewöhnliche Zeichenkettenohne jegliche Struktur behandelt. Mit den verbreiteten Web-Technologien CGI, SSI, Servlets undJSP ist eine solche Verarbeitung möglich und gängige Praxis.

Generell kann man sagen, dass die Verarbeitung von XML auf der Basis von Zeichenketten einenwesentlichen Nachteil mit sich bringt. Es kann zur Zeit der Programmübersetzung weder sicher-gestellt werden, ob die generierten XML-Fragmente wohlgeformt sind, noch ist eine Überprüfungder Gültigkeit möglich. Die sowohl in CGI als auch in Servlets fehlende Unterstützung für grö-ßere, konstante XML-Fragmente, die eine umständliche Generierung notwendig macht, ist durchSSI und JSP aufgehoben worden.


2.6.2 Einfache Objektmodelle

Eine Verbesserung gegenüber der Verarbeitung von XML-Fragmenten auf der Ebene von Zei-chenketten liegt in der Definition eines einfachen Objektmodells mit Klassen für die Knoteneines XML-Fragments. Dadurch werden beliebige XML-Dokumente durch eine objektorientierteDatenstruktur repräsentiert, die ausgelesen und verändert werden kann. Der wichtigste Vertreterdieses Ansatzes ist das DOM. Daneben existiert für die Programmiersprache Java ein unabhän-giges Objektmodell für XML mit dem Namen Java-DOM (JDOM) [JDO], das besser auf dieEigenheiten der Sprache abgestimmt ist. Diese Arbeit geht auf JDOM nicht näher ein, sondernverweist auf die detaillierte Darstellung in [Har02].

Dokument-Objektmodell

Das Dokument-Objektmodell (DOM) wurde bereits in Abschnitt 2.3 ausführlich vorgestellt. DerAnsatz ist weit verbreitet und wird von vielen Programmiersprachen unterstützt. Es ist der bishereinzige standardisierte und sprachneutrale Weg zur Verarbeitung von XML.

Konstante XML-Fragmente müssen in einfachen Dokumentmodellen entweder in streng objekt-orientierter Weise ausprogrammiert werden, was sehr mühsam ist, oder durch das Einlesen desXML-Fragments als Zeichenkette erzeugt werden, was eine Überprüfung der Gültigkeit zur Lauf-zeit erforderlich macht. Die Eigenschaft Wohlgeformtheit wird im Vergleich zur Verarbeitung alsZeichenketten jedoch für die dynamisch generierten XML-Fragmente zur Zeit der Programm-übersetzung garantiert. Die Überprüfung der Gültigkeit dagegen ist ebenfalls erst zur Laufzeitmöglich.

2.6.3 Höhere Objektmodelle

Neben den einfachen Objektmodellen können XML-Fragmente auch durch höhere Objektmo-delle repräsentiert werden. Deren Verwendung setzt voraus, dass eine Anwendung sich auf dieVerarbeitung von Dokumenten einer oder mehrere fester Auszeichnungssprachen beschränkt.Diese Annahme stellt zwar im Allgemeinen eine Einschränkung dar, wird aber von den mei-sten Web-Anwendungen eingehalten. Die Idee dieses Ansatzes ist, aus der Sprachbeschreibungder verwendeten Auszeichnungssprache Datentypen oder Klassen der Programmiersprache zugenerieren. Dabei werden die Datentypen und Klassen derart definiert, dass sie die durch dieSprachbeschreibung intendierte Semantik der Dokumentstruktur so gut wie möglich in der Pro-grammiersprache reproduzieren.

Eine ganze Reihe von Vorschlägen [Bou02] für höhere Objektmodelle, an denen sich nahezu je-der namhafte Softwarehersteller, wie Sun mit JAXB, Microsoft mit .Net Framework, Exolab mitCastor, Delphi mit Data Binding Wizard und Oracle mit XML Class Generator [Sun03, Mic01,Exo02, Bor01, Ora01] beteiligt, sind in jüngster Zeit vorgelegt worden. In der Regel sind die-


se Ansätze auf spezielle Programmiersprachen zugeschnitten. Eine Standardisierung ist zur Zeitnicht vorgesehen. Diese Arbeit beschränkt sich auf eine kurze Darstellung von JAXB und demValidating-DOM, einer Entwicklung aus früheren Forschungsarbeiten.

Java Architecture for XML Binding

Für die Programmierung von Web-Anwendungen und Web-Services wird von der Firma Sundas Entwicklungswerkzeug Java Architecture for XML Binding (JAXB) [Sun03] zur Verfü-gung gestellt. Dieses verfügt über einen Schema-Übersetzer, den der Programmierer mit einerSprachbeschreibung, sei es eine DTD oder ein XML-Schema, startet. Als Ergebnis erhält erden Quellcode von Typen- und Klassendefinitionen für Elementdeklarationen und Typdefinitio-nen der Sprachbeschreibung. Jede Klasse definiert eigene Instanzvariablen, in denen die Inhalteund Attribute der repräsentierten XML-Fragmente abgelegt werden. Spezielle Zugriffsmethodenerlauben das Auslesen und Ändern dieser Daten. Weiterhin werden sogenannte unmarshal-Methoden erzeugt, die ein einfaches Einlesen von XML in die generierten Klassenstrukturen er-möglichen. Umgekehrt können aber auch über Methoden namens marshal aus den Instanzender internen Darstellung die repräsentierten XML-Fragmente erstellt werden. Mit der ebenfallsgenerierten Methode validate kann ein Test auf Gültigkeit der aktuellen Objekte zur Sprach-beschreibung durchgeführt werden. Dem Entwickler steht es nun frei, die generierten Klassenum anwendungsspezifische Methoden zu erweitern und sie in den Programmen der Anwendungeinzusetzen. Auch kann er die Voreinstellung des Schema-Übersetzers durch sogenannte Bin-dungsschemata („binding schema“) überschreiben. Damit ist eine Veränderung der generiertenKlassen-, Variablen- und Methodennamen sowie ein Einfluss auf erzeugte Typkonvertierungen,Klassenkonstruktoren, typsichere Aufzählungsklassen und Schnittstellen möglich.

In JAXB erfolgt eine Überprüfung auf Gültigkeit in den marshal- und unmarshal-Metho-den und kann zusätzlich während der Laufzeit durch Aufruf einer validate-Methode ange-stoßen werden. Zusätzlich wird durch die speziellen Zugriffsmethoden der generierten Klassenund das Java-Typsystem schon eine Vielzahl von möglicherweise ungültigen Objektzuständenausgeschlossen. Aber gerade bei nicht trivialen, verschachtelten Inhaltsmodellen zeigt JAXBSchwächen, denn es ergeben sich entweder sehr komplizierte Datenstrukturen oder welche, diedas Inhaltsmodell nur sehr ungenügend reflektiert. Die statische Gültigkeit während der gesam-ten Lebenszyklen der Objekte ist damit in JAXB nicht garantiert. Ein weiterer Nachteil ist darinzu sehen, dass eine etwaige Änderung der Sprachbeschreibung eine erneute Generierung derKlassen nach sich zieht. Auch wird für den Programmierer die Komplexität der Softwareent-wicklung künstlich erhöht. Denn er muss sich neben der Sprachbeschreibung zusätzlich in dasBindungsschema einarbeiten, welches für nicht triviale Fälle schnell kompliziert wird.

Validating-DOM

Validating-DOM (VDOM) [KL02] ist eine Erweiterung des DOM zum höheren Objektmodell.


Ähnlich wie bei JAXB wird für jede Elementdefinition in der Sprachbeschreibung ein neueSchnittstellendefinition generiert. Diese Schnittstellen, die Erweiterungen der DOM-SchnittstelleElement sind, enthalten spezielle Methoden zum Einfügen und Entfernen von Attributen undInhalten. Die Deklaration der Methodensignaturen ist dabei in einer solchen Weise konstruiert,dass das Inhaltsmodell der Elementtypen durch das Typsystem weitgehend sichergestellt werdenkann. Zusätzlich werden nur zulässige Attribute und Attributwerte akzeptiert. In VDOM werdenkonstante XML-Fragmente durch ein neues Sprachkonstrukt mit dem Namen Parameterized-XML (PXML) unterstützt.

Höhere Objektmodelle verfügen wie einfache Objektmodelle, mit Ausnahme des VDOM, überkeine Erleichterung zur Verarbeitung von konstanten XML-Fragmenten. Aus diesem Grund mussdie Generierung von konstanten XML-Fragmenten entweder durch verschachtelte Konstruktor-und Methodenaufrufe oder durch das Einlesen einer festen Zeichenkette erfolgen. Das erste Vor-gehen ist für den Programmierer sehr mühsam, während das zweite einer Überprüfung der Gül-tigkeit zur Laufzeit bedarf. Die Wohlgeformtheit von dynamisch generierten Dokumenten zurZeit der Programmübersetzung wird durch höhere Objektmodelle sichergestellt. Die Gültigkeitfür diese Dokumente kann meist nur eingeschränkt garantiert werden. Ausschlaggebend für dieQualität dieser Überprüfung ist die Wahl des Objektmodells und der verwendeten Programmier-sprache.

2.6.4 Garantie der statischen Gültigkeit

In diesem Abschnitt werden Ansätze zur Repräsentation von XML vorgestellt, die es erlauben,bereits zur Zeit der Programmübersetzung zu garantieren, dass die von der Web-Anwendungerzeugten Dokumente statisch gültig sind. Nur diese Entwicklungen sind wirklich vergleichbarmit der Spracherweiterung, die diese Arbeit vorstellt.

XDuce

Die Sprache XDuce [HVP00] ist eine funktionale Programmiersprache, die speziell zur Verarbei-tung von XML entwickelt wurde. Sie definiert sogenannte reguläre Ausdruckstypen, deren WerteXML-Fragmente repräsentieren. Diese Werte werden durch spezielle Konstruktoren erzeugt undkönnen, wie in funktionalen Programmiersprachen verbreitet, durch Pattern-Matching analysiertwerden. XDuce unterstützt Typinferenz für Pattern und Variablen, es führt eine Subtyp-Analyseauf der Basis von Baumautomaten [RS97] durch, um die Gültigkeit der Instanzen von regulärenAusdruckstypen bereits zum Zeitpunkt der Programmübersetzung sicherzustellen.


BigWig

BigWig [BMS01] ist eine iterative Programmiersprache zur Entwicklung von interaktiven Web-Services. Sie führt getypte XML-Dokument-Schablonen („templates“) ein, die ausgezeichneteLücken enthalten können. Um im Programm dynamisch XML-Dokumente zu erzeugen, bestehtdie Möglichkeit, diese Lücken zur Laufzeit mit anderen Schablonen oder Zeichenketten zu sub-stituieren. Für sämtliche Schablonen überprüft BigWig die dynamisch berechneten Dokumenteauf Gültigkeit bzgl. einer gegebenen DTD bereits zum Zeitpunkt der Programmübersetzung.Dies geschieht durch zwei Datenflussanalysen [NNH99], die einen Graphen konstruieren, dersämtliche mögliche Dokumente endlich darstellt. Der Graph wird dann analysiert, um Schablo-nen zu erkennen, die gegen die Gültigkeit verstoßen. Der BigWig-Quelltext wird in eine Kombi-nation von Programmen unterschiedlicher Standard-Web-Technologien wie HTML, CGI, App-lets und JavaScript übersetzt. Seit kurzer Zeit ist BigWig auch für die Programmiersprache Javaunter dem Namen JWig [CMS02] verfügbar.

XL und XQuery

Einen weiteren anspruchsvollen Ansatz präsentiert die Sprachspezifikation von XL [FGK02].XL ist eine eigenständige XML-Programmiersprache speziell zur Implementierung von Web-Services. Sie übernimmt die Sprachkonstrukte aus XQuery [W3C02c] und erweitert diese umhöhere und deklarative Sprachkonstrukte zu einer vollständigen Programmiersprache. Zusätzlichwerden imperative Sprachkonstrukte wie Fallunterscheidungen, Schleife und Ausnahmen inte-griert, wodurch XL zu einer Mischung aus funktionaler und imperativer Programmiersprachewird. Wie im zukünftigen Standard für Anfragesprachen von XML-Datenbanksystemen XQue-ry [W3C02c] soll XL, das auf XQuery beruht, die statische Gültigkeit für dynamisch erzeugteXML-Fragmente unterstützen.

2.6.5 Diskussion

In diesem Abschnitt werden die dargestellten Ansätze zur Verarbeitung von XML-Fragmentenzusammengefasst.

Die folgende Tabelle stellt in ihren Spalten dar, in wie fern die unterschiedlichen Verarbeitungs-formen von XML, die in den Zeilen aufgeführt sind, konstante XML-Fragmente unterstützen,sowie die Eigenschaften Wohlgeformtheit und statische Gültigkeit bereits zum Zeitpunkt derProgrammübersetzung garantieren. Durch die Angabe eines � wird illustriert, dass der Ansatzüber die entsprechende Eigenschaft verfügt. Ist dies nicht der Fall, wird ein � aufgeführt. Beider Eigenschaft der statischen Gültigkeit wird für Techniken, die diese nicht im vollen Umfangsicherstellen, ein � angezeigt. Zum Beispiel ist eine einfache Einbindung von konstanten XML-Fragmenten in JAXB nicht vorgesehen ( � ), die Eigenschaft der Wohlgeformtheit wird dagegengarantiert ( � ), während die statische Gültigkeit nur begrenzt zugesichert werden kann ( � ).


konstante ÜbersetzungsgarantienXML-Fragmente Wohlgeformtheit statische Gültigkeit

Zeichenkette � � �

SSI, JSP � � �

DOM, JDOM � � �

JAXB, CASTOR � � �

VDOM � � �

XDuce, BigWig, XL, XOBE � � �

Die Hauptbeobachtung aus der Tabelle ist, dass nur XDuce, BigWig und XL wirklich vergleich-bar sind mit dem Vorschlag, den diese Arbeit mit XML-Objekte (XOBE) vorstellt. Die ande-ren Ansätze verwenden zur Repräsentation von XML-Fragmenten entweder nur Zeichenkettenoder trennen streng zwischen einer Repräsentation als Zeichenkette und einer Repräsentation alsObjekt. Im restlichen Abschnitt werden kurz die wesentlichen Unterschiede zwischen XDuce,BigWig und XL zu dem in den nächsten Kapiteln eingeführten XOBE beschrieben.

Im Vergleich zu XOBE implementiert XDuce ebenfalls einen Subtyp-Algorithmus, der aber aufregulären Baumautomaten basiert. Er operiert deshalb auf einer zusätzlichen internen Reprä-sentation für die regulären Ausdruckstypen, was durch die notwendigen Konvertierungen eineIneffizienz des Verfahrens darstellt. Auf diese interne Repräsentation verzichtet der Algorith-mus dieser Arbeit, der in Abschnitt 4.6 vorgestellt wird. Weiterhin ist es mit XOBE, durch Er-weiterung der Programmiersprache Java, einfacher, ein Programm an andere Komponenten wiebeispielsweise Datenbanksysteme anzubinden.

Verglichen mit XOBE können die in BigWig eingeführten Schablonen als Methoden begriffenwerden, die XML-Objekte zurückliefern. Die Argumente dieser Methoden korrespondieren dannmit den Lücken der Schablonen. Damit ist dieses Sprachmittel in XOBE voll darstellbar. DerAlgorithmus zur Typanalyse in BigWig basiert auf einer Datenflussanalyse und ist deshalb nurschwer mit dem Algorithmus in XOBE vergleichbar. Weiterhin scheint das Typsystem dieserArbeit verglichen mit BigWig ausdrucksstärker zu sein, weil es möglich ist, den Subtyp-Al-gorithmus sehr natürlich um Typerweiterungen und Typeinschränkungen aus XML-Schema zuerweitern (Abschnitt 4.8). Dies ist in BigWig wohl nur schwer erreichbar.

XL ist definiert als eigenständige Programmiersprache für Web-Services. Im Unterschied dazuist XOBE eine Erweiterung von Java, einer bereits weit verbreiteten und bewährten Program-miersprache für Web-Anwendungen und Web-Services. Es ist naheliegend, dass XOBE mit derVerwendung von bereits entwickelten Bibliotheken und Programmen in Java erheblich profitie-ren kann.

2.7. EINORDNUNG DIESER ARBEIT 57

2.7 Einordnung dieser Arbeit

In diesem Abschnitt werden zunächst die Eigenschaften der zuvor beschriebenen Techniken zurVerarbeitung und Repräsentation von XML, zusammengefasst, bevor wiederholt die Zielsetzungdieser Arbeit klargestellt wird. Die Verarbeitung und Repräsentation von XML wird verstärkt beiWeb-Anwendungen (2.5) eingesetzt, für die die unterschiedlichsten Implementierungstechnikenexistieren.

Die Verarbeitung von XML mit den Mitteln von Zeichenketten, wie dies bei SSI über CGI undJSP auf der Grundlagen von Servlets erfolgt, ist völlig unzureichend. Zwar werden konstanteXML-Fragmente relativ komfortabel unterstützt, doch wird für generierte XML-Fragmente wederdie Eigenschaft wohldefiniert noch die statische Gültigkeit zur Zeit der Programmübersetzunggarantiert. Selbst eine Überprüfung der Eigenschaften zur Laufzeit der Web-Anwendung ist nichtvorgesehen.

Einfache Objektmodelle sind zur Zeit der einzige standardisierte Weg zur Verarbeitung vonXML-Fragmenten. Sie sind so allgemein definiert, dass eine Verarbeitung von XML-Dokumen-ten beliebiger Auszeichnungssprachen, deren Sprachbeschreibung der Anwendung nicht einmalbekannt sein muss, durchgeführt werden kann. Die Einbindung konstanter XML-Fragmente istnicht vorgesehen. Die Eigenschaft der Wohldefiniertheit wird zur Zeit der Programmübersetzungfür alle generierten XML-Fragmente garantiert, während die statische Gültigkeit bei gegebenerSprachbeschreibung für den selben Zeitpunkt nicht sichergestellt werden kann. Allerdings wirdeiner Überprüfung zur Laufzeit, die zusätzliche Rechenzeit in Anspruch nimmt, unterstützt.

Bei der Verarbeitung von XML-Dokumenten mit höheren Objektmodellen müssen alle verwen-deten Auszeichnungssprachen zum Zeitpunkt der Programmierung feststehen. Mit dieser An-nahme kann sich die interne Repräsentation von XML eng an den Bedingungen der Sprach-beschreibung orientieren, wodurch die Überprüfung auf Gültigkeit erleichtert wird. Höhere Ob-jektmodelle stellen die Wohldefiniertheit während der Programmübersetzung sicher, die statischeGültigkeit wird nur mit Einschränkung garantiert. Die Überprüfung der gesamten statischen Gül-tigkeit ist zur Laufzeit der Anwendung möglich. Bisher ist keine Unterstützung von konstantenXML-Fragmenten integriert.

Ansätze, die die statische Gültigkeit bei der Verarbeitung von XML-Fragmenten zur Zeit der Pro-grammübersetzung sicherstellen, gibt es nur vereinzelt. Eine Entwicklung realisiert eine funk-tionale Programmiersprache mit eingeschränktem Sprachumfang, weshalb ein Verwendung fürWeb-Anwendungen und Web-Services nur begrenzt möglich ist. Desweiteren ist in der in Stan-dardisierung befindlichen Anfragesprache für XML-Datenbanksysteme eine Überprüfung aufstatische Gültigkeit vorgesehen. Darauf aufbauend wurde eine Programmiersprache für Web-Services definiert, die sowohl über deklarative als auch iterative Sprachkonstrukte verfügt. Fürletztere Sprachen ist eine erste Implementierung zur Zeit noch in der Entwicklungsphase. Ver-fügbar dagegen ist eine Java-Erweiterung, die ebenfalls die statische Gültigkeit garantiert, aberEinschränkungen hinsichtlich der erweiterten Beschreibungsmöglichkeiten von XML-Schemaaufweist.


Insgesamt ist folgende Schlussfolgerung zu ziehen: Es ist – bis auf eine Ausnahme – bisher nichtmöglich, mit einer objektorientierten Programmiertechnik Web-Anwendungen zu erstellen, dieeine Verarbeitung von XML-Fragmenten unter Garantie der statischen Gültigkeit vorsieht. (Le-diglich die parallel zu dieser Arbeit entstandene Java-Erweiterung JWig geht einen Schritt indiese Richtung.) Stattdessen muss mit Hilfe von intensiven Testläufen die Korrektheit der er-zeugten XML-Fragmente plausibel gemacht werden. Dieser Nachteil besteht bei einer ganzenReihe der beschriebenen und weit verbreiteten Technologien zur Verarbeitung und Repräsenta-tion von XML. Andere Entwicklungen können zwar die statische Gültigkeit in sehr begrenztemMaße sicherstellen, verlangen aber vom Programmierer neben der Kenntnis der eingesetztenAuszeichnungssprache, noch eine Abbildung der Sprachbeschreibung in Datentypen der Pro-grammiersprache.

Mit dieser Arbeit soll durch eine Erweiterung der Programmiersprache Java eine objektorien-tierte Integration von XML-Fragmenten erreicht werden. Die Erweiterung soll dabei für die ver-arbeiteten XML-Fragmente die statische Gültigkeit bereits zur Zeit der Programmübersetzungsicherstellen, wodurch auf intensive Testläufe und aufwendige Überprüfungen zur Laufzeit ver-zichtet werden kann. Einzellösungen zur komfortablen Formulierung statischer XML-Teile, wiesie mit SSI und JSP in 2.5.4 ausdrückbar sind, können mit dieser Java-Erweiterung ebenfallsrealisiert werden.

Die Grundlagen der Java-Erweiterung bildet die Deklaration einer XML-Sprachbeschreibung, seies eine DTD oder ein XML-Schema, im Programm, wodurch die Sprachbeschreibung zum Zeit-punkt der Programmübersetzung feststeht. Aufbauend auf der Sprachbeschreibung werden neueSprachkonstrukte eingeführt, um XML-Fragmente zu erzeugen und im Programm zu verarbei-ten. Auch ist die Selektion von Inhalten und Elementen aus XML-Fragmenten über XPath (2.2)möglich. Da jedem XML-Fragment ein eindeutiger Typ aus der Sprachbeschreibung zugeordnetist, kann anhand einer Typanalyse zum Zeitpunkt der Programmübersetzung überprüft werden,ob das Programm ausschließlich statisch gültige XML-Fragmente verarbeitet. Eine prototypi-sche Implementierung der Java-Erweiterung wurde als Präprozessor realisiert und transformiertdie XOBE-Programme in reinen Java-Quelltext. Als interne Repräsentation der XML-Fragmentekommt dabei das DOM (2.3) zur Anwendung.

Kapitel 3

XML-Objekte

Bei der Programmierung von Anwendungen mit JSP, wie im letzten Kapitel demonstriert, hatsich gezeigt, dass eine Integration von XML-Syntax in eine Programmiersprache für Web-An-wendungen wie Java sinnvoll ist. Trotzdem ist der Ansatz der JSP, wie im Abschnitt 2.5 aus-führlich diskutiert, nicht ausreichend. Die Unzulänglichkeit liegt einerseits in der fehlenden sta-tischen Überprüfung der XML-Syntax hinlänglich der Eigenschaften Wohlgeformtheit und Gül-tigkeit und andererseits im unklaren Objektmodell, das hinter den XML-Konstrukten steht.

Die unstrittigen Vorteile von XML-Syntax in der Programmiersprache Java werden durch dieJava-Erweiterung XML-Objekte (XOBE) aufgegriffen. XOBE führt weiterhin ein klares Objekt-modell für XML-Dokumente mit Elementen, Attributen und Zeichendaten ein, die sogenanntenXML-Objekte. XML-Objekte werden mit Hilfe von XML-Konstruktoren, die in XML-Syntax no-tiert werden, erzeugt. Die Selektion von Werten und Inhalten aus XML-Objekten erfolgt in derstandardisierten und in Abschnitt 2.2 vorgestellten Sprache XPath, um die die Programmierspra-che Java ebenfalls erweitert wird.

Das Kapitel beginnt mit einer informellen Einführung über die neuartigen Sprachkonstrukte inXOBE. Im Anschluss daran erfolgt eine formale Definition der Syntax mit einer Beschreibungder implizierten Semantik. Es folgt ein Abschnitt, der die Anwendung von XOBE mit Beispielendemonstriert.

3.1 Einführung

Die Spracherweiterung XOBE ergänzt die Programmiersprache Java um XML-Objekte [LK02].Mit XML-Objekten werden sowohl die baumartige Struktur eines XML-Fragments als auch diedarin enthaltenen Informationen und Daten repräsentiert. Sie sind als eingebaute Datenobjektekonstruiert, so dass sie wie Werte von Basisdatentypen im Programm verwendet werden können.Die Struktur von XML-Objekten muss einer vorgegebenen Sprachbeschreibung entsprechen, in-

60 KAPITEL 3. XML-OBJEKTE

dem diese vorab deklariert wird. Damit werden die Definitionen und Deklarationen der dekla-rierten Sprachbeschreibung als implizite Definitionen von XML-Objektklassen aufgefasst undzur Typisierung der unterschiedlichen XML-Objekte eingesetzt. Die korrekte Typisierung wirdzum Zeitpunkt der Programmübersetzung überprüft.

Vergleichbar mit Zeichenketten vom Typ String, die durch konstante Zeichenketten im Pro-gramm erzeugt werden können, steht als Konstruktor für XML-Objekte deren XML-Syntax zurVerfügung. Mit dem folgenden kleinen Beispiel soll die Idee veranschaulicht werden.

Beispiel 3.1In diesem Beispiel wird die Auszeichnungsprache AOML aus Beispiel 2.2 verwendet.

1 a u t h o r a = < a u t h o r >Thomas Mann </ a u t h o r > ;

Die Zeile zeigt die Zuweisung eines XML-Elements an die Variable a. Die Variable ist deklariertals Variable der XML-Objektklasse author.

2 i n t eu = 8 ;3 p r i c e p = { eu } ;

In der letzten Zeile wird der Variablen p der XML-Objektklasse price ein Element zugewiesen.Das Element hat keinen Inhalt. Stattdessen wird dort der Wert der int-Variablen eu eingesetzt.

4 book b = < book c a t a l o g =" V a r i a ">5 < t i t l e > L o t t e i n Weimar < / t i t l e >6 { a }7 < c o n d i t i o n > Einband f i n g e r f l e c k i g , Rücken

v e r b l a ß t < / c o n d i t i o n >8 {p}9 </ book >;

Hier wird der Variablen b der XML-Objektklasse book das Fragment eines XML-Dokumentszugewiesen. Diesmal werden die XML-Objekte auf die die Variablen a und p verweisen, diezuvor als XML-Objektklassen deklariert wurden, in den Inhalt eingefügt (6,8).

10 S t r i n g eu2 = ( b / c h i l d : : p r i c e / c h i l d : : t e x t ( ) ) . i t em ( 0 ) ;

Die letzte Zeile des Beispiels selektiert aus dem durch die Variable b referenzierten XML-Objektden Inhalt des Kindes price. �

3.2 Syntax und Semantik

In diesem Abschnitt folgt nach obiger informeller Darstellung die Definition der neuen Sprach-konstrukte in XOBE. Dabei werden die neuen Konstrukte in die Java-Grammatik integriert. Auf

3.2. SYNTAX UND SEMANTIK 61

eine Vorstellung der gesamten Java-Syntax wird an dieser Stelle verzichtet; sie findet sich in[GJS96, GJSB00].

3.2.1 Objektmodell

Neben der konkreten Syntax eines XML-Dokuments oder -Fragments ist für XOBE die abstrakte,logische Struktur von XML wesentlich. Die Struktur eines XML-Dokuments ähnelt dabei einemBaum, während die Struktur eines XML-Fragments, das aus mehreren Elementen bestehen kann,einer Reihe von Bäumen, einer sogenannten Hecke, gleicht. Ein XML-Dokument kann damitauch als Spezialfall eines XML-Fragments angesehen werden, weshalb hier im Weiteren nurnoch von XML-Fragmenten gesprochen wird.

In XOBE wird die Struktur und der eigentliche Dateninhalt von XML-Fragmenten durch Instan-zen eines Objektmodells repräsentiert. Dieses Objektmodell ist nicht nur eine Datenstruktur fürXML-Fragmente, sondern ein Objektmodell im Sinne des traditionellen objektorientierten De-signs [RBP

�91]. Es umfasst damit nicht nur die Struktur und Daten der XML-Fragmente, son-

dern schließt auch Identität und Verhalten der repräsentierenden Objekte ein, die als XML-Ob-jekte bezeichnet werden. Für die einzelnen XML-Objekte der baumartigen Objektstruktur wirdzwischen den folgenden Objektklassen unterschieden:

� Elementklassen mit Superklasse Element,

� Attributklassen mit Superklasse Attribute,

� Kommentarklasse Comment.

Das wichtigste Strukturierungsmittel in XML sind Elementtypen, die in der Sprachbeschreibungdeklariert wurden. Elemente unterscheiden sich durch verschiedene Elementnamen, Attributty-pen und Inhaltsmodelle. Anhand dieser Eigenschaften erfolgt in XOBE eine Unterteilung derElementobjekte in spezielle Elementklassen, die von der allgemeinen Elementklasse Elementabgeleitet werden. Durch die Definitionen und Deklarationen der verwendeten Sprachbeschrei-bung werden Spezialisierungen der allgemeinen Superklasse erreicht. Für jedes Element im zurepräsentierenden XML-Fragment existiert eine Instanz einer solchen speziellen Elementklassein der Objektstruktur. Jedes Elementobjekt referenziert seine Attributobjekte sowie die im Inhaltbefindlichen Element-, Text- und Kommentarobjekte, die auch als Kinder bezeichnet werden.Weiterhin findet sich ein Verweis auf das Elternobjekt eines Elementobjekts.

Jedes Elementobjekt verweist auf eine zugeordnete Menge von Attributobjekten. Jedes Attri-butobjekt verweist auf seinen Attributnamen und den Attributwert. Anders als im Datenmodellvon XPath [W3C99a] wird in XOBE nicht verlangt, dass ein Attribut auf sein Elementobjektverweist. Attributobjekte werden analog zu den Elementobjekten in unterschiedliche speziel-le Attributklassen unterteilt, die sich von der allgemeinen Attributklasse Attribute ableiten.

Die in der Sprachbeschreibung deklarierten Eigenschaften Attributname und Attributtyp definie-ren die verschiedenen Spezialisierungen der allgemeinen Superklasse. Attributtypen, für die inder Sprachbeschreibung ein Vorgabewert vorliegt, werden in der Objektstruktur so behandelt, alswären sie im Element aufgeführt.

Im Inhalt von Elementen können in XML Zeichendaten auftreten, die in XOBE durch Instan-zen der Klasse String aus der Java-Bibliothek repräsentiert werden. Zeichenketten, die Zei-chendaten repräsentieren, müssen immer aus mindestens einem Zeichen bestehen. Andernfallswerden sie aus der Objektstruktur entfernt. Zeichenketten gehen in der Objektstruktur niemalseiner anderen Zeichenkette als direkter Geschwisterknoten voraus oder folgen unmittelbar einersolchen. Für jeden Kommentar im repräsentierten XML-Fragment existiert ein Kommentarobjektder Kommentarklasse Comment in der Objektstruktur. Diese verweisen auf den Kommentartext,der ebenfalls in Form einer Zeichenkette vorliegt.

Im XOBE-Objektmodell wird auf eine spezielle Klasse zur Repräsentation ganzer XML-Frag-mente verzichtet. Instanzen einer solchen Klasse, wie sie im DOM oder im Datenmodell vonXPath definiert sind, dienen lediglich dazu, den Einstiegspunkt oder die Wurzel der Objektstruk-tur zu markieren und verweist auf die Zeichenketten, Element- und Kommentarobjekte, die fürden Inhalt des zu repräsentierenden XML-Fragments auf der äußersten Ebene stehen. Ein Auf-treten solcher Objekte innerhalb des verschachtelten Baumes ist dort nicht erlaubt.

Wie in XPath (siehe Abschnitt 2.2) wird auch in XOBE eine Ordnung für die Objekte der Ob-jektstruktur definiert. Mit Dokumentordnung wird dabei die Reihenfolge aller Objekte einer Ob-jektstruktur bezeichnet, die mit der Reihenfolge des Auftreten des ersten Zeichens der XML-Repräsentation eines jeden Objekts im Dokument korrespondiert. Das Dokumentobjekt ist stetsdas erste Objekt in Dokumentordnung, während Elternobjekte vor ihren Kindobjekten liegen.Dadurch sind Elementobjekte anhand des Auftretens ihrer Start-Tags in XML angeordnet. DieAttributobjekte eines Elements liegen vor den Kinderobjekten des Inhalts des Elements. Die um-gekehrte Dokumentordnung ist definiert als die Umkehrung der Dokumentordnung.

3.2.2 Klassen

Die Bestandteile von Daten oder Dokumenten in XML, die Elemente und Attribute, haben imAllgemeinen unterschiedliche Elementtypen und Attributtypen, wie in 2.1.1 beschrieben wurde.Diese Typen werden in einer Sprachbeschreibung deklariert und definiert. In XOBE werden ausder Sprachbeschreibung die Deklarationen der Elementnamen mit der angegebenen Inhaltsde-finition und die Definitionen benannter Gruppen sowie komplexer Typen berücksichtigt. Dafürmuss die Sprachbeschreibung im XOBE-Programm explizit deklariert werden.

Definition 3.1 (Schemadeklaration)Eine Schemadeklaration in XOBE erfolgt über die folgende Syntax:

<ImportDeclaration> � . . . | "ximport" <URI> ";"Mit <ImportDeclaration> wird ein Nichtterminal aus der Java-Grammatik bezeichnet und durch

die Zeichen �� wird angezeigt, dass die bestehende Grammatikregel der Java-Syntax erweitertwird. Eine <URI> referenziert eine DTD oder ein XML-Schema. �

Nach der obigen Grammatik ist es erlaubt, dass ein XOBE-Programm mehrere Sprachbeschrei-bungen deklariert. Dies ist bei unterschiedlichen Bezeichnern in den Sprachbeschreibungen auchproblemlos möglich. Werden allerdings Bezeichner in unterschiedlichen Sprachbeschreibungenmehrfach verwendet, so ist der Einsatz qualifizierender Klassenbezeichner notwendig. Dies stellteine zukünftige Erweiterungsmöglichkeit von XOBE dar.

Die Typen der im Programm deklarierten Sprachbeschreibung werden implizit als Klassendefini-tionen für XML-Objekte interpretiert. Sie stehen nach der Deklaration über den Elementnamen,Gruppennamen oder Typnamen unmittelbar zur Verfügung. Eine explizite Erzeugung von Java-Quelltext für die XML-Objekt-Klassen findet nicht statt. XML-Objekte sind demnach Instan-zen von Elementtypen, Gruppen oder Basistypen, die in der deklarierten Sprachbeschreibungdefiniert wurden. Damit repräsentiert der Wert jedes XML-Objekts ein XML-Fragment, das ver-schachtelte Elemente und Zeichendaten beinhalten kann. Durch eine Schemadeklaration werdenin einem XOBE-Programm XML-Objekt-Klassen vereinbart. Diese impliziten Klassen sind alsendgültig (Java-Terminus: final) vereinbart. Damit ist es nicht möglich, von diesen Klassenweitere Subklassen abzuleiten.

Im XOBE-Programm wird XML ausschließlich unter Verwendung von XML-Objekten verarbei-tet, d. h. auf die Repräsentation als Zeichenkette wird während des Programmablaufs verzich-tet. Trotzdem gibt es Fälle, in denen eine Umwandlung in eine Zeichenkette erforderlich wird.Dies wird notwendig, wenn von einem Programm XML-Daten an die Außenwelt kommuniziertwerden, zum Beispiel als Resultat eines Java-Servlets. Für diesen Zweck wird die Methode to-String für XML-Objekte zur Verfügung gestellt.

3.2.3 Deklaration von Variablen

Wie für jede Klasse in Java ist es mit XOBE möglich, Variablen für XML-Objektklassen zudeklarieren. Die Variablen dieser Klassen werden auch als XML-Variablen bezeichnet.

Definition 3.2 (XML-Variablendeklaration)Eine XML-Variablendeklaration ist durch folgende Grammatik definiert:

<Type> � (<BasicType> | <XMLType> | <Name>) ("[" "]")*<XMLType> � "xml" "<" (<Name> | "(" <ChoiceType> ")") ("+" | "*")? ">"<ChoiceType> � <Name> | <Name> "|" <ChoiceType>

Mit <Type>, <BasicType> und <Name> werden Nichtterminale aus der Java-Grammatik be-zeichnet. �

Die Definition zeigt, dass XML-Variablen durch das Schlüsselwort xml gefolgt von spitzenKlammern (<, >) mit dem Typbezeichner aus der Sprachbeschreibung deklariert werden. Mitder Anweisung xml<title> t; wird beispielsweise die Variable t der XML-Objektklassedeklariert, die durch die Elementtypdeklaration title in der Sprachbeschreibung impliziert

wird. In eindeutigen Fällen kann auf die Angabe des Schlüsselworts sowie der spitzen Klam-mern verzichtet werden. Die abkürzende Schreibweise lautet dann title t;. Zusätzlich ist esmöglich Variablen zu deklarieren, die zur Laufzeit auf unterschiedliche XML-Objekte verweisenkönnen. Mit xml<(book|record)> i; wird eine solche Variable deklariert, der entwederein XML-Objekt vom Typ book oder vom Typ record zugewiesen werden kann. Mit Hilfeeiner Spezialisierung „down-cast“ (xml<book>) i kann eine solche Referenz in eine der Va-rianten umgewandelt werden. Die abkürzende Schreibweise ist bei Variablendeklarationen fürunterschiedliche XML-Objekte und für die in Abschnitt 3.2.5 eingeführten Elementlisten nichtzulässig.

3.2.4 Konstruktoren

In XOBE-Programmen werden XML-Objekte mit Hilfe von Ausdrücken erzeugt, die als XML-Objekt-Konstruktoren bezeichnet werden. Die Syntax dieser Ausdrücke besteht nicht nur auswohldefiniertem XML, sondern muss auch die Bedingungen der statischen Gültigkeit erfüllen.

Als Erweiterung zur reinen XML-Syntax wird es gestattet, andere Java-Werte, Java-Objekte oderXML-Objekte in einen XML-Objekt-Konstruktor einzufügen. Syntaktisch werden diese Einfü-gepunkte mit geschweiften Klammern von der umgebenen XML-Notation abgegrenzt. Dies ent-spricht der Vorgehensweise, wie sie auch in XML-Anfragesprachen wie XQuery [W3C02c] zufinden ist. Die eingefügten Werte und Objekte sind allerdings nur an Stellen erlaubt, die nicht dieEigenschaften Wohldefiniertheit und statische Gültigkeit verletzen.

Definition 3.3 (XML-Objekt-Konstruktor)Ein XML-Objekt-Konstruktor ist nach folgender Grammatik aufgebaut:

<Literal> � . . . | <Element><Element> � <EmptyElementTag> | <STag> <Content> <ETag><STag> � "<" <Name_XML> (<Attribute>)* ">"<Attribute> � <Name_XML> "=" (<AttValue> | "{"<Expression>"}")<ETag> � "</" <Name_XML> ">"<Content> � (<Element> | <CharData> | <Comment> |

"{"<Expression>"}")*<EmptyElementTag> � "<" <Name_XML> (<Attribute>)* "/>"<Comment> � ""

<AttValue> ist dabei eine Zeichenkette in einfachen (’) oder doppelten Hochkommata ("), <Na-me_XML> ein Elementname und <CharData> sowie <CommentData> bedeuten alphanume-rische Zeichendaten. Mit <Literal> und <Expression> werden Nichtterminalsymbole aus derJava-Grammatik bezeichnet. �

Für XML-Konstruktoren wird gefordert, dass die Bedingungen der Sprachbeschreibung einge-halten werden. Erlaubt wird aber, dass int-Werte an Stellen eingesetzt werden, an denen lautSprachbeschreibung Werte vom Basisdatentyp integer erwartet werden. Analoges gilt fürZeichenketten der Klasse String, die an string-Positionen zulässig sind. Bereits in Ab-

schnitt 3.1 wurden Beispiele für XML-Konstruktoren gezeigt.

3.2.5 Elementliste

XOBE stellt als zusätzliche Klasse eine Liste von XML-Objekten zur Verfügung. Da es sich hierin der Regel um Listen von XML-Elementen handelt, wird auch verkürzend von Elementlistengesprochen, obwohl allgemeine Listen von XML-Objekten gemeint sind. Gerade für Schleifen-konstrukte und Rekursionen sind Elementlisten gut geeignet, um eine beliebige Anzahl gleicheroder unterschiedlicher Elemente aufzunehmen.

Für die Deklaration einer Elementliste gibt es zwei Varianten. Eine Erste kann über die in Ab-schnitt 3.2.3 eingeführten Operatoren + und * vorgenommen werden. Beispielsweise deklariertdie Anweisung xml<author*> al; die Variable al als eine Liste von author-Elemen-ten. Die zweite Möglichkeit besteht darin, dass der Name einer in der deklarierten Sprachbe-schreibung definierten benannten Gruppe herangezogen wird, die bereits durch das Attribut ma-xOccurs="unbounded" als Liste definiert wurde. Die Syntax und Semantik einer Liste vonXML-Objekten wird durch die Definition einer spezifizierten Schnittstelle festgelegt.

Definition 3.4 (Liste über XML-Objekte)Eine Liste über XML-Objekte sei durch folgende Schnittstelle definiert:

1 i n t e r f a c e XMLList<XMLObject > : XMLObject {2 s t a t i c XMLList < >( ) ;3 s t a t i c XMLList + ( in XMLList l , in XMLObject o ) ;4 XMLObject i t em ( in i n t i ) ;5 i n t g e t L e n g t h ( ) ;6 s t a t i c XMLList + ( in XMLObject o , in XMLList l ) ;7 s t a t i c XMLList + ( in XMLList l_1 , in XMLList l _ 2 ) ;8 } / / XMLList

Die Operationen und Methoden der Schnittstelle werden durch folgende Anweisungsgleichun-gen mit den Variablen

�� XMLList und � � � � � � � � XMLObject und � int spezifiziert:

�� getLength �� <> ��

� � � � � + � � � � �

� � getLength �� getLength �� + � �

�� item � � � � � � � �� + � ��

� � � � � + � � ��

� � item �� item � � � � �� + � � �

<> + � � �� + <>

�� + � � + � � � �� + � � + � � �

<> +� � ��

�� + �� + �

� � �� + � � � + �

� ��

Wie die Definition zeigt, wird mit <> die leere Elementliste bezeichnet. Der Operator + realisiertdie Konkatenation der Elementliste in drei Varianten, eine zum Hinzufügen eines Elements amEnde der Liste, eine zum Hinzufügen am Anfang der Liste und eine zum Zusammenfügen zweierListen. Zusätzlich liefert die Methode getLength die Länge der Elementliste und die Methodeitem selektiert das Element der Liste an der angegebenen Position. Das erste Element der Listesteht an der Position � .

Da es sich bei Elementlisten wiederum um XML-Objekte handelt, stellt es kein Problem dar, siein XML-Objekt-Konstruktoren einzufügen, wenn dies nach der deklarierten Sprachbeschreibungerlaubt ist.

Anmerkung: Obwohl eine Elementliste ein XML-Objekt ist und deshalb streng genommenebenfalls ein Element der Liste sein könnte, wird dies von diesem Datentyp nicht unterstützt.Stattdessen wird die Konkatenation zweier Listen verwendet. Es wird also stets auf einer flachenListe gearbeitet.

3.2.6 Selektion

Für die Selektion von Daten aus XML-Objekten wird in XOBE die Syntax von XPath, die inAbschnitt 2.2 vorgestellt wurde, verwendet. Die Semantik von XPath wird dafür auf das XO-BE-Objektmodell adaptiert. XPath stellt, wie beschrieben, einen Mechanismus zur Verfügung,um mittels sogenannter Pfadausdrücke bestimmte Knoten aus einem XML-Fragment zu selek-tieren. Da in XOBE XML-Fragmente ausschließlich durch XML-Objekte repräsentiert werden,kann mittels dieser Pfadausdrücke auf Inhaltsdaten und verschachtelte XML-Objekte eines XML-Objekts zugegriffen werden.

Ein Pfadausdruck in XPath bezieht sich stets auf einen Kontextknoten. In XOBE wird dieserdurch eine XML-Objekt-Variable vorgegeben und dem Pfadausdruck syntaktisch vorangestellt.Das Resultat eines Pfadausdrucks besteht in XOBE aus einer Elementliste, die, wie erwähnt,ebenfalls ein XML-Objekt darstellt. Dies ermöglicht es, die Ergebnisse von Pfadausdrücken inXML-Objekt-Konstruktoren weiter zu verwenden.

Definition 3.5 (XPath-Ausdruck)Ein XPath-Ausdruck in XOBE ist nach folgender Grammatik aufgebaut:

<Expression> � . . . | <XPathExpression><XPathExpression> � <Name> "/" <RelativeLocationPath> | <LocationPath><LocationPath> � <RelativeLocationPath> | <AbsoluteLocationPath><AbsoluteLocationPath> � "/" <RelativeLocationPath>?<RelativeLocationPath> � <Step> | <RelativeLocationPath> "/" <Step>

3.3. ANWENDUNGSBEISPIELE 67

<Step> � <AxisSpecifier> <NodeTest> <Predicate>*<AxisSpecifier> � <AxisName> "::"<AxisName> � "ancestor" | "ancestor-or-self" | "attribute" |

"child" | "descendant" | "descendant-or-self" |"following" | "following-sibling" | "parent" |"preceding" | "preceding-sibling" | "self"

<NodeTest> � <NameTest> | <NodeType> "(" ")"<Predicate> � "[" <PredicateExpr> "]"<PredicateExpr> � <Expression><NameTest> � "*" | <Name><NodeType> � "comment" | "text" | "node"

Bei <Expression> und <Name> handelt es sich um Nichtterminale aus der Java-Grammatik. �

Anmerkung: Die zweite Syntax-Variante des Nichtterminalen <XPathExpression> ist nur in-nerhalb von Prädikaten gestattet.

Anmerkung: Die erzeugten Listen der XPath-Ausdrücke sind nicht „live“. Damit ist gemeint,dass eine Veränderung des XML-Dokuments keine geänderte Liste nach sich zieht. Die Liste istnicht mit dem Dokument gekoppelt. Etwaige Änderungen im Dokument werden also nicht in derListe reflektiert und umgekehrt. Wird das Dokument modifiziert während eine Iteration über dieListe stattfindet, ist das Resultat der Iteration undefiniert. Trotzdem haben Änderungen der XML-Objekte in der Liste auch Auswirkungen auf das eigentliche Dokument, denn die Elementlistebesteht, wie in Java üblich, aus Referenzen auf XML-Objekte.

3.3 Anwendungsbeispiele

In diesem Abschnitt werden anhand eines detaillierten Beispiels die in XOBE eingeführtenSprachkonstrukte verdeutlicht. Das Beispiel zeigt einen Web-Dienst, der eine Shop-Anwendungrealisiert, die mit der Außenwelt über ein spezielles XML-Datenformat kommuniziert. Das Da-tenformat, das Verwendung findet, ist das Shop-Interchange-Formart (SIF) aus Abschnitt 2.1.2.

Implementiert wird das Beispiel mit einer Klasse Cart, die einen Einkaufskorb für den Shoprealisiert und in Abbildung 3.1 als UML-Darstellung [BRJ99, RJB99] illustriert ist. Die Klassehat eine Komponente accountNr vom Typ int, die den Einkaufskorb für jeden Kunden ein-deutig identifiziert. Eine weitere Komponente articles der Schnittstelle List aus der Java-Bibliothek registriert die ausgewählten Artikel im Einkaufskorb. Dafür werden die Artikelnum-mern, die vom Typ int sind, in der Liste gespeichert. Zusätzlich deklariert die Klasse die dreiMethoden addArticle, removeArticle und getArticles. Die Methode addArtic-le fügt einen Artikel zum Einkaufskorb hinzu, removeArticle entfernt einen Artikel ausdiesem und getArticles liefert den Inhalt des Einkaufskorb mit den ausgewählten Artikeln.

Das folgende Beispiel zeigt die Realisierung der Methode addArticle.

Abbildung 3.1: Klasse Cart

Beispiel 3.2Die Methode addArticle liefert ein shopResponse-Objekt gemäß dem SIF (Beispiel 2.4)zurück. Als Parameter erhält die Methode die Nummer des Artikels, der hinzugefügt werden soll.

1 shopResponse a d d A r t i c l e ( i n t a r t i c l e N r ) {2 t h i s . a r t i c l e s . add ( a r t i c l e N r ) ;3 re turn < shopResponse >4 < s h o p p i n g C a r t >5 < accoun t >{ t h i s . a ccoun tNr } </ accoun t >6 < r e q u e s t > p r o c e s s e d < / r e q u e s t >7 </ s h o p p i n g C a r t >8 </ shopResponse > ;9 } / / a d d A r t i c l e

Die Methode fügt zunächst die Artikelnummer der Artikelliste mit der Methode add aus derList-Schnittstelle hinzu (2). Anschließend wird mit einem XML-Objekt-Konstruktor, wie imvorherigen Abschnitt definiert, das XML-Objekt der Klasse shopResponse erzeugt und zu-rückgegeben (3-8). Der Konstruktor fügt in den Inhalt des account-Elements die Kunden-nummer, die aus der Komponente accountNr extrahiert wird, ein (5). Hier wird die schonbeschriebene Eigenschaft der Konstruktoren ausgenutzt, dass int-Werte akzeptiert werden, anStellen wo nach der deklarierten Sprachbeschreibung integer-Werte erwartet werden. �

Das Beispiel der Methode addArticle macht plausibel, dass eine Überprüfung der statischenGültigkeit gemäß dem SIF zur Zeit der Programmübersetzung möglich ist, da sämtliche dafürrelevanten Typinformationen zur Verfügung stehen. Das nächste Beispiel zeigt die Implementie-rung der Methode removeArticle der Klasse Cart.

Beispiel 3.3Die Methode removeArticle erhält als Parameter eine Artikelnummer und liefert ein XML-Objekt der Klasse shopResponse.

1 shopResponse r e m o v e A r t i c l e ( i n t a r t i c l e N r ) {2 r e q u e s t done ;3 shopResponse r e s p o n s e ;4

5 i f ( t h i s . a r t i c l e s . remove ( a r t i c l e N r ) )6 done = < r e q u e s t > p r o c e s s e d < / r e q u e s t > ;7 e l s e8 done = < r e q u e s t > f a i l < / r e q u e s t > ;9 r e s p o n s e = < shopResponse >

10 < s h o p p i n g C a r t >11 < accoun t >{ t h i s . a ccoun tNr } </ accoun t >12 { done }13 </ s h o p p i n g C a r t >14 </ shopResponse > ;15 re turn r e s p o n s e ;16 } / / r e m o v e A r t i c l e

In der Methode werden die zwei lokalen XML-Objekt-Variablen done und response unter-schiedlicher XML-Objekt-Klassen deklariert (2,3). Die Zuweisung eines XML-Objekts an dieVariable done hängt vom Erfolg der Löschung des Artikels mit der Nummer articleNraus der Liste articles ab (5). Ist diese erfolgreich, wird ein Element mit Inhalt proces-sed erzeugt (6), ansonsten mit Inhalt fail (8). Der Variablen response wird mit Hilfe einesKonstruktors ein shopResponse-Objekt zugewiesen (9-14). Es enthält ebenfalls wieder dieKundennummer des Einkaufskorbs (11) und zusätzlich die eingefügte Variable done (12). DasBeispiel zeigt wie XML-Objekt-Variablen innerhalb von Konstruktoren verwendet werden kön-nen. �

Es wird erneut offensichtlich, dass die statische Gültigkeit dieser Methode mit den angegebenenTypinformationen zur Programmübersetzung überprüfbar ist. Eine solche Typüberprüfung würdefür die beiden vorgestellten Beispiele ergeben, dass die XML-Objekte gültig, also korrekt, sind.Im folgenden Beispiel wird diese Bedingung nicht eingehalten.

Beispiel 3.4Dieses Beispiel zeigt nicht gültigen XOBE-Quelltext, für den der XOBE-Übersetzer eine ent-sprechende Fehlermeldung liefert.

1 r e q u e s t done ;2 shopResponse r e s p o n s e ;3

4 done = < r e q u e s t > f a i l < / r e q u e s t > ;5 r e s p o n s e = < shopResponse >6 < s h o p p i n g C a r t >7 < accoun t >{ t h i s . a ccoun tNr }

{ done } </ accoun t >8 </ s h o p p i n g C a r t >9 </ shopResponse > ;

Nach Deklaration der beiden Variablen done und response als XML-Objekt-Variablen (1,2),erfolgt eine Zuweisung eines request-Elements an die Variable done (4). In der zweitenZuweisung wird mittels eines Konstruktors ein shopResponse-Objekt an die Variable re-sponse zugewiesen (5-9). Dabei wird sowohl die Kundennummer accountNr als auch dasObjekt der Variablen done in ein account-Element eingebettet (7). Nach der Sprachbeschrei-bung des SIF ist aber ein request-Element nicht im Inhalt eines account-Elements erlaubt.Somit muss dieser Quelltext vom XOBE-Übersetzer abgelehnt werden. �

Nach dem letzten Beispiel mit inkorrektem Programmtext, folgt nun ein Beispiel für Elementli-sten, das die Methode getArticles realisiert.

Beispiel 3.5Die Methode getArticles wird ohne Parameter aufgerufen und liefert erneut ein XML-Ob-jekt der Klasse shopResponse.

1 shopResponse g e t A r t i c l e s ( ) {2 i n t i ;3 xml< a r t i c l e � > c o n t e n t ;4

5 c o n t e n t = < > ;6 f o r ( i = 0 ; i < t h i s . a r t i c l e s . s i z e ( ) ; i = i + 1 )7 c o n t e n t = c o n t e n t + < a r t i c l e > { t h i s . a r t i c l e s . g e t ( i )

} < / a r t i c l e > ;8 re turn < shopResponse >9 < s h o p p i n g C a r t >

10 < accoun t >{ t h i s . a ccoun tNr } </ accoun t >11 < r e q u e s t > p r o c e s s e d < / r e q u e s t >12 { c o n t e n t } 13 </ s h o p p i n g C a r t >14 </ shopResponse > ;15 } / / g e t A r t i c l e s

Die Methode deklariert zwei lokale Variablen; i vom Typ int als Laufvariable in der Schlei-fe und content als XML-Objekt-Variable der Listenklasse article* (2,3). Der Variablencontent wird als erstes eine leere Liste zugewiesen (5). Diese wird anschließend in der for-Schleife (6-7), die über die Artikelnummern der Komponente articles des Einkaufskorbesiteriert, um article-Objekte erweitert (7). Das Beispiel zeigt die Verwendung der Konkaten-ation + für Elementlisten. Die resultierende Elementliste content wird in einen Konstruktor,der ein shopResponse-Objekt erzeugt, eingebettet (8-14). Das shopResponse-Objekt wird

als Ergebnis der Methode zurückgegeben. �

Das letzte Beispiel dieses Abschnittes geht auf die Selektionsmöglichkeiten in XOBE ein. Eszeigt die Implementierung der Methode processRequest, die eine eingehende Anfrage einesKunden verarbeitet.

Beispiel 3.6Die Methode processRequest erhält als Parameter ein XML-Objekt der Klasse shopRe-quest und liefert als Ergebnis ein XML-Objekt der Klasse shopResponse, welches als Ant-wort an den anfragenden Kunden zurückgeschickt wird.

1 shopResponse p r o c e s s R e q u e s t ( shopReques t rq ) {2 C a r t c ;3 xml< shopReques t . s h o p p i n g C a r t > sc ;4

5 sc = ( rq / c h i l d : : shopReques t / c h i l d : : s h o p p i n g C a r t ) . i t em( 0 ) ;

6 c = a l l C a r t s . g e t ( ( sc / c h i l d : : a c c o u n t ) . i t em ( 0 ) ) ;7

8 i f ( ( s c / c h i l d : : add ) . g e t L e n g t h ( ) = = 1 )9 re turn c . a d d A r t i c l e ( ( sc / c h i l d : : add ) . i t em ( 0 ) ) ;

10 e l s e i f ( ( s c / c h i l d : : remove ) . g e t L e n g t h ( ) = = 1 )11 re turn c . r e m o v e A r t i c l e ( ( sc / c h i l d : : remove ) . i t em ( 0 ) ) ;12 e l s e i f ( ( s c / c h i l d : : g e t ) . g e t L e n g t h ( ) = = 1 )13 re turn c . g e t A r t i c l e s ( ) ;14 } / / p r o c e s s R e q u e s t

Die Methode reicht die eingehende Anfrage an den Einkaufskorb des kontaktierenden Kundenweiter und liefert die resultierende Antwort der entsprechenden Methoden des Einkaufskorbs.Um den Einkaufskorb des anfragenden Kunden zu finden, wird die globale Variable allCartsverwendet, die den Zugriff auf alle registrierten Einkaufskörbe des Web-Dienstes ermöglicht.Von der übergebenen Anfrage rq ermittelt die Methode das shoppingCart-Objekt und weistes der Variablen sc zu (5). Anschließend wird das entsprechende Cart-Objekt aus der Men-ge der in Verarbeitung befindlichen Einkaufskörbe allCarts durch die Methode get ausge-wählt (6). In der abschließenden Fallunterscheidung (8-13) werden die drei möglichen Anfrage-typen add, remove oder get differenziert und an die passenden Methoden des Cart-Objektsdelegiert. Die Artikelnummern, die von den Methoden addArticle und removeArticleals Parameter benötigt werden, werden aus dem XML-Objekt der Variablen sc selektiert.

Die Methode processRequest verwendet zur Selektion des Inhalts eines XML-Objekts Pfad-ausdrücke (5-12), wie sie in Abschnitt 3.2.6 beschrieben werden. Die Pfadausdrücke liefern ge-nerell eine Liste von XML-Objekten, so dass für einen Zugriff auf ein bestimmtes Element selbst,die Listenmethode item angewendet werden muss (5,6,9,11). Die Länge der Resultatsliste einesPfadausdrucks kann mittels der Methode getLength (8,10,12) untersucht werden. �


3.4 Bewertung

Zur Konstruktion von XOBE lässt sich zusammenfassend sagen, dass mit der Java-Erweiterungein mächtiges und effizientes Werkzeug für die Programmierung von Web-Anwendungen ge-wonnen wurde. Von Interesse ist dabei einerseits die Möglichkeit, XML-Syntax auf einfache Artund Weise in Java zu verwenden, was durch das Konzept der XML-Objekte erreicht wurde. XML-Fragmente bezeichnen dadurch in einem XOBE-Programm stets XML-Objekte. Eine Unterschei-dung zwischen einer Repräsentation als Zeichenkette und einer Repräsentation als Objektstrukturist damit aufgehoben.

Andererseits wird mit Spracherweiterung gleichzeitig, neben der Wohlgeformtheit, die Eigen-schaft der statischen Gültigkeit bereits zum Zeitpunkt der Programmübersetzung für sämtlicheXML-Objekte, die auch dynamisch erzeugt werden dürfen, sichergestellt. Dies wird durch dieTypüberprüfung der Java-Erweiterung, die Gegenstand des nächsten Kapitels sein wird, erreicht.

Obwohl XOBE mit der statischen Gültigkeit die meisten Anforderungen der Eigenschaft Gül-tigkeit von XML-Schema während der Programmübersetzung garantieren kann, kann für einigewenige Ausnahmen auf eine zusätzliche Überprüfung zur Laufzeit nicht verzichtet werden. DieUrsache dafür liegt darin, dass einige Objekteigenschaften erst zur Laufzeit der Anwendungfeststehen, und damit außerhalb des XOBE-Typsystems liegen. Dies ist vergleichbar mit Fel-dern konstanter Größe („array“) in Standardprogrammiersprachen, bei denen der Zugriffsindexim deklarierten Intervall liegen muss. So wäre es in XOBE durchaus denkbar, dass aus einerElementliste, also einem mit dem Attribut maxOccurs="unbounded" deklarierten Element-typ, die leer ist, noch ein weiteres Element gelöscht werden soll. Weitere Laufzeitüberprüfungensind notwendig für Identitätsbeschränkungen („identity constraints“) sowie abgeleitete Basisda-tentypen, wie eingeschränkte Zeichenkettentypen („restricted string types“) und eingeschränk-te numerische Typen („facets on numeric types“). Fehler dieser Art können erst während desProgrammablaufs erkannt werden und sind dann durch geeignete Ausnahmebehandlungen abzu-fangen. Trotz dieser zusätzlichen Laufzeitberechnungen ist ein Effizienzgewinn gegenüber dervollständigen Überprüfung der Gültigkeit zur Laufzeit, wie es bei Verwendung des DOM not-wendig ist, zu erwarten, da die Überprüfung nur für einige wenige Bedingungen durchgeführtwerden muss.

Abschließend sind als Auswirkungen der Spracherweiterung auf die Programmiersprache Javazu erwähnen, dass eine Ergänzung der eingebauten Wertebereiche für Daten um XML-Fragmentewie auch eine dafür sinnvolle Erweiterung des Typsystems vorgenommen wurde. Wegen derherausragenden Rolle von XML in der Welt der Programmierung von Web-Anwendungen undWeb-Services, sowie möglicherweise der gesamten Software-Entwicklungsbranche, scheint diesein nur konsequenter Schritt zu sein. Die Nachteile, die durch die Erweiterung einer bestehendenProgrammiersprache entstehen, anstatt eine neue Programmiersprache für genau diesen Zweckzu definieren, sind vernachlässigbar gering. Stattdessen überwiegen die Vorteile, die durch dieNutzungsmöglichkeiten von bereits entwickeltem Quelltext und von Bibliotheken entstehen.

Kapitel 4

Ein Typsystem für XOBE

Wie sich bei den Anwendungen des Dokument-Objektmodells im Kapitel 2.3 zeigt, ist die Erzeu-gung von Dokumenten möglich, die gemäß einer Sprachbeschreibung (DTD oder XML-Schema)ungültig sind. Ein wesentlicher Nachteil des DOM besteht darin, dass eine Überprüfung der Gül-tigkeit der in Verarbeitung befindlichen Dokumente erst zur Laufzeit der Anwendung vorgenom-men werden kann. Da die Abwesenheit von Programmteilen, die die Gültigkeit verletzen, nichtgarantiert werden kann, ist im DOM für die dadurch notwendige Überprüfung der Verbrauchzusätzlicher Rechenzeit unvermeidlich.

Um bei der Verarbeitung von Dokumenten deren Gültigkeit auf einfache Art sicherzustellen, istes sinnvoll, eine Typüberprüfung für XML-Objekte zu entwickeln, die die Angaben der Sprachbe-schreibung als Typsystem zu Grunde legt. Bereits in [Hos00] wurde aufbauend auf der Sprachbe-schreibung ein Typsystementwurf für eine derartige Verarbeitung im Rahmen einer funktionalenProgrammiersprache vorgestellt. Diese Idee wird hier weiterverfolgt und ausgebaut; insbesonde-re wird hier der Ansatz in den Kontext des objektorientierten Paradigmas gesetzt. Dafür wird dasXOBE-Typsystem definiert, dessen Ausdruckskraft sich an XML-Schema orientiert.

Das Kapitel beginnt mit einer informellen Einführung der Typen in XOBE. Im Anschluss erfolgteine Formalisierung der Typen und Sprachbeschreibungen, worauf aufbauend die Typinferenz fürXML-Objekte und XPath-Ausdrücke definiert werden. Es folgt der Algorithmus zur Typüberprü-fung. Den Abschluss des Kapitels bilden die Nachweise der Korrektheit des Algorithmus sowieErläuterungen zu Erweiterungen und Vereinfachungen.

4.1 Einführung

Die in Kapitel 3 beschriebene Java-Erweiterung XOBE verwendet zur Programmierung XML-Objekte unterschiedlicher XML-Objekt-Klassen. XML-Klassen werden dabei ausschließlich inder Sprachbeschreibung, die eine Auszeichnungssprache bestimmt, definiert und stehen dem

74 KAPITEL 4. EIN TYPSYSTEM FÜR XOBE

XOBE-Programm durch Deklaration implizit zur Verfügung. Weitere Definitionen von XML-Klassen im XOBE-Programm sind nicht vorgesehen. Aufgabe des Typsystems ist es zunächst,die Typen1 der im XOBE-Programm verwendeten Programmausdrücke zu inferieren. Anschlie-ßend wird anhand der inferierten Typen überprüft, ob die Programmausdrücke an zulässigenPositionen im Programm auftreten.

An einem kleinen Beispiel soll das Vorgehen gezeigt werden.

Beispiel 4.1Das Beispiel 3.1 aus Abschnitt 3.1 zeigte die Zuweisung eines book-Elements an die Variable bder Klasse book. Zuvor wurden die Bezeichner a und p als Variablen der Klassen author undprice deklariert und initialisiert.



Die Aufgabe des XOBE-Typsystems ist es, für diese Zuweisung die Typen der beteiligten Aus-drücke zu inferieren. Für eine Zuweisung sind dies die Typen der linken und rechten Seiten, dieim Weiteren mit � und � bezeichnet werden. Auf der linken Seite der Zuweisung steht die Va-riable b, für die das Typsystem gemäß der Deklaration den Typen � � book inferiert. Die rechteSeite der Zuweisung besteht aus dem Element book, für das der folgende Typ ermittelt wird:2

� � book�@catalog

�string � � title �string � � author � condition �string � � price �

Für diese beiden Typen wird im Anschluss an die Inferenz vom Typsystem die sogenannte Sub-typ-Beziehung überprüft. Denn nur wenn die Ungleichung

�� gilt, wobei mit der Relation � die Subtyp-Beziehung bezeichnet wird, ist der Typ der rechtenSeite ein Subtyp des Typs der linken Seite. Und nur dann ist die obige Zuweisung korrekt undwird vom Typsystem akzeptiert. �

Wie das Beispiel zeigt, besteht das XOBE-Typsystem zur Überprüfung der Typkorrektheit ausmehreren Komponenten. Hinzu kommt noch das Einlesen der zu Grunde liegenden Sprachbe-schreibung. Damit gliedert sich das XOBE-Typsystem in drei Teile:

� Die Formalisierung der Sprachbeschreibung übersetzt die deklarierte Sprachbeschreibungin eine für das Typsystem lesbare Form.

1Da im Weiteren das Typsystem von XOBE vorgestellt wird, wird hier von Typen oder XML-Typen anstatt vonKlassen gesprochen.

2Eine Einführung in die formale Notation für XML-Typen erfolgt im nächsten Abschnitt.

4.1. EINFÜHRUNG 75

� Die Typinferenz, die für XML-Konstruktoren und XPath-Ausdrücke zu unterscheiden ist,dient zur Ermittlung der XML-Typen.

� Der Subtyp-Algorithmus überprüft die Zulässigkeit der ermittelten XML-Typen. Dies istdie Hauptaufgabe bei der Untersuchung der Typkorrektheit von XOBE-Programmen.

Im nächsten Abschnitt wird sich zeigen, dass sich XML-Fragmente durch reguläre Heckenspra-chen formalisieren lassen. Nach [BKMW01] lassen sich reguläre Baumautomaten zu regulärenHeckenautomaten erweitern, die dann reguläre Heckensprachen erkennen. Damit wäre für dieÜberprüfung der Subtyp-Beziehung der klassische Algorithmus zur Entscheidung der Sprachin-klusion zweier Automaten möglich. Dieser berechnet für zwei gegebene Automaten � und ��

zunächst das Komplement � � von � � bevor anschließend der Durchschnitt zwischen � und � �

gebildet wird. Eine Sprachinklusion liegt genau dann vor, wenn das Resultat der Durchschnitts-operation leer ist.

Der Algorithmus arbeitet demnach mit der Berechnung des Komplements, die eine Determini-sierung – also eine Konvertierung eines nicht-deterministischen Automaten in einen determini-stischen Automaten – beinhaltet. In der Regel wird diese mit der Berry-Sethi-Methode [BS86]durch Teilmengen-Konstruktion durchgeführt. Dabei korrespondiert jeder Zustand des zu erzeu-genden deterministischen Automaten mit einer Teilmenge von Zuständen des ursprünglichennicht-deterministischen Automaten. Durch diese Konstruktion kann die Zustandsmenge im All-gemeinen exponentiell anwachsen.

Zu erhöhtem Aufwand führt zusätzlich, dass der Automat, dessen Terminalsymbole die Basis-datentypen der XML-Typen sind, jegliche Informationen über komplexe Typen und deren Typ-definitionen verliert. So sind beispielsweise bei der Überprüfung der Subtyp-Beziehung � book � �record � � � � book

�record � � die Typdefinitionen von book und record irrelevant. Mit anderen

Worten: Die Beziehung kann auch ohne das Wissen der Typdefinitionen verifiziert werden. Derklassische Algorithmus berücksichtigt eine solche Erleichterung nicht; stattdessen werden alleTypen bis zu den Basisdatentypen hin analysiert.

Der Algorithmus von Aiken und Murphy zur Überprüfung der Subtyp-Beziehung von regulä-ren Baumausdrücken [AM91] ist in der Lage, mit komplexen Typen umzugehen. Er arbeitet,wie für Subtyp-Algorithmen vieler Typsystem üblich, von oben nach unten („top-down“). Diesbedeutet, dass er mit einem Paar von Typen, für das die Subtyp-Beziehung überprüft werdensoll, beginnt. Da ein komplexer Typ sich mittels Typkonstruktoren zusammensetzt, kann in je-dem Schritt überprüft werden, ob die obersten Konstruktoren beider Seiten zusammenpassen. Eserfolgt eine rekursive Anwendung auf die Teilkomponenten der Typen, bis Typnamen erreichtwerden, die dann einfach zu überprüfen sind. Da die Typnamen nicht nur für Basisdatentypen,sondern auch für komplexe Typen stehen können, ist die angesprochene Überprüfungsvereinfa-chung möglich.

In [Hos00] wird der Algorithmus von Aiken und Murphy für XML adaptiert und auf Baumau-tomaten mit Rangzahl („ranked tree automata“) angewendet. Bei dieser Methode entsteht derNachteil, dass eine häufige Umwandlung von XML-Typen in Baumautomaten notwendig wird.

Der Algorithmus der in diesem Kapitel (Abschnitt 4.6) vorgestellt wird, kommt ohne diese auf-wendige Konvertierung aus.

Notation

Zur Definition der Formalisierung von Sprachbeschreibungen, für die Darstellung der Typin-ferenz und zur Beschreibung des Subtyp-Algorithmus werden in dieser Arbeit Typisierungs-oder Inferenzregeln verwendet. Die Notation, die ursprünglich im Bereich der Logik entwickelt

[Tak75, Pra65, Fre67] wurde, ist zur Beschreibung von Typsystemen und Semantik von Pro-grammiersprachen [Mit96, Car97] inzwischen weit verbreitet. Eine Inferenzregel besteht auseiner Linie mit einer oder mehreren Prämissen über der Linie und einer Konklusion unter derLinie. Gelten nun sämtliche Prämissen über der Linie, dann darf die Konklusion unterhalb derLinie abgeleitet werden. Folgendes Beispiel illustriert eine solche Inferenzregel:

Beispiel 4.2Das Beispiel zeigt eine Vereinfachung einer Regel, wie sie in einem der folgenden Abschnitteverwendet wird. Dabei wird durch

� � � � notiert, dass das Inhaltsmodell� � vom XML-Type �

ist.

� � � � � ��

� � �� (SIMP CONC)

Die Regel SIMP CONC sagt folgendes aus: Falls ableitbar ist, dass� � � vom Typ � � und

� � �vom Typ � � ist, dann ist ebenfalls ableitbar, dass die Konkatenation

� � �� vom Typ � � � � �

ist. Zum Beispiel sei� � � � 1 und

� � � � zwei mit den Typen � � �b�integer � und � � � i

�string � . Dann kann durch die Regel 1zwei �

b�integer � � i �string � abgeleitet werden, weil sowohl 1 � b �integer � als auch

zwei � i �string � gelten. �

Die Menge von Prämissen über der Linie kann in speziellen Fällen auch leer sein. In einer solchenRegel, die auch als Axiom bezeichnet wird, gilt die Konklusion unterhalb der Linie immer.

Klassischerweise werden Typisierungsregeln verwendet, um Typisierungsurteile („typing judg-ment“) abzuleiten. Ein Typisierungsurteil hat die Form �� . Dabei ist � ein gegebenerKontext, der beispielsweise aus Variablendeklarationen bestehen kann, � ist ein typisierbarerAusdruck und � der Typ von � . Bei leerem Kontext wird auch statt

�� abkürzend � � �

angegeben. In dieser Arbeit werden darüber hinaus weitere Relationen mit Inferenzregeln defi-niert. So erfolgt die Formalisierung der Sprachbeschreibung als auch des Subtyp-Algorithmusunter Angabe von Inferenzregeln.

4.2. FORMALISIERUNG 77

4.2 Formalisierung

Nach der obigen informellen Einführung definiert dieser Abschnitt die formalen Grundlagen,die nötig sind, um später den Algorithmus zur Überprüfung der Typkorrektheit zu formulieren.Dabei wird die Menge der natürlichen Zahlen mit � (die Menge der natürlichen Zahlen inklusiveder Null mit �� ) und die Menge der booleschen Werte mit � angegeben; mit � � � �wird die Potenzmenge von � bezeichnet und steht für die disjunkte Vereinigung.

In XOBE werden XML-Typen durch reguläre Heckenausdrücke („regular hedge expression“)[Mur01] formalisiert, die reguläre Heckensprachen („regular hedge languages“) repräsentieren.Eine Einführung zu regulären Heckensprachen findet sich in [BKMW01]. Heckensprachen sindeng verwandt mit den Baumsprachen („tree languages“), denn eine Hecke („hedge“) ist einegeordnete Sequenz von Bäumen. In der Literatur [Neu99] wird gelegentlich auch von Wald („fo-rest“) gesprochen, doch ist dieser Begriff bereits in der Graphentheorie [Die00, Tur96] als unge-ordnete Menge von Bäumen definiert. Eine ausführliche Einführung zu regulären Baumsprachenfindet sich in [RS97, CDG

�97].

Die folgenden Definitionen für Hecke und reguläre Heckenausdrücke verwendet eine ähnlicheNotation wie [W3C01a].

Definition 4.1 (Hecke)Eine Hecke über einer Menge von Terminalsymbolen �� mit der Menge � von Basis-datentypen und der Menge von Elementnamen ist induktiv definiert:

� ist die leere Hecke,

� mit � � � ist eine Hecke,� � � � mit�� und der Hecke � ist eine Hecke und

�� mit den Hecken � und � ist eine Hecke.

Die Menge aller Hecken sei mit �� bezeichnet und die Menge aller Hecken ohne die leere Heckemit � notiert. �

Wie die Definition zeigt, besteht eine Hecke entweder aus der leeren Hecke, aus einem Basis-datentypen, aus einem Elementnamen mit einer Hecke als Inhalt oder aus der Konkatenationzweier Hecken. Für Hecken ist es möglich reguläre Heckenausdrücke zu definieren, von denenim Weiteren der Arbeit auch kurz von regulären Ausdrücken gesprochen wird.

Definition 4.2 (Regulärer Heckenausdruck)Die Menge der regulären Heckenausdrücke Reg über einer Menge von Terminalsymbolen �� mit der Menge � von Basisdatentypen und der Menge von Elementnamen sowie einer


Menge � von Nichtterminalsymbolen ist rekursiv definiert durch:

�� Reg für die leere Menge,

� � Reg für die leere Hecke,

� � Reg für Basisdatentypen,

� � Reg für komplexe Typen,� � � � � Reg für Elementtypen,

� � � � � � Reg für die Operation reguläre Vereinigung,

� � � � � � Reg für die Operation Konkatenation und

� � � � � Reg für die Operation Kleene-Stern

für alle � � � , � �� ,�� und �

� � � Reg. �

Anmerkung: Für die Operatoren werden die Vorrangregeln in der absteigenden Reihenfolge � ,� und

�festgelegt. Auf die Klammerung eines regulären Heckenausdrucks kann dann in eindeu-

tigen Fällen auch verzichtet werden. Die aus der DTD bekannten Operatoren � und � sind mitregulären Heckenausdrücken ebenfalls darstellbar. So entspricht � � dem Ausdruck � � � � und � �dem Ausdruck � � � .Aufbauend auf regulären Ausdrücken kann die durch einen regulären Ausdruck bezeichneteSprache festgelegt werden.

Definition 4.3 (Sprache eines regulären Heckenausdrucks)Die Heckensprache � � � � über einen regulären Heckenausdruck � � Reg bei einer gegebenenMenge von Produktionen � (wie sie in Definition 4.5 festgelegt werden) sei definiert durch:

� � � � � � �� mit � � � ��

für alle � � � , � �� ,�� und �

� � � Reg. �

Es ist einsichtig, dass es reguläre Ausdrücke gibt, die eine Sprache repräsentieren, die die leereHecke beinhalten. Für alle diese regulären Ausdrücke soll das Prädikat isNullable? erfüllt sein.

Definition 4.4 (Leere-Hecke-Prädikat)Das Leere-Hecke-Prädikat isNullable? � Reg � � entscheidet für einen gegebenen regulärenAusdruck � � Reg und eine Menge � von Produktionen (wie sie in Definition 4.5 definiert


werden), ob die leere Hecke in der Sprache � � � � liegt. Es ist wie folgt rekursiv definiert:

isNullable? � � � � false

isNullable? � �� true

isNullable? � � � � false

isNullable? �� isNullable? � � � mit � � � ��isNullable? � � � � � � � false

isNullable? � � � � � � isNullable? � � �� isNullable? � � �isNullable? � � � � � � isNullable? � � �� isNullable? � � �isNullable? � � � � � true

mit � � � , � �� ,�� und �

� � � Reg. �

Auf der Basis dieser Definitionen lässt sich nun die reguläre Heckengrammatik einführen, die inder Lage ist, eine XML-Sprachbeschreibung formal darzustellen.

Definition 4.5 (Reguläre Heckengrammatik)Eine reguläre Heckengrammatik sei definiert durch � � � � � � � � � � mit

� � � einer Menge von Terminalsymbolen, bestehend aus Basisdatentypen � und einerMenge von Elementnamen (Tags),

� einer Menge von Nichtterminalsymbolen (Namen von Gruppen oder komplexen Typen),

� einem Startausdruck mit � � Reg und

� einer Menge von Produktionsregeln der Form � � � mit � �� und � � Reg, einem regulärenHeckenausdruck über und � .

Für die Regeln der Produktionsmenge � gelten die folgenden zwei Bedingungen:

1. Bei rekursiven Nichtterminalsymbolen tritt die rekursive Anwendung nur an letzter Posi-tion einer Produktion auf.

2. Bei rekursiven Nichtterminalsymbolen gilt für den Ausdruck � vor der rekursiven Anwen-dung � isNullable? � � � .

�

Die in der Definition der Heckengrammatik angegebenen Bedingungen für rekursive Produktio-nen sind notwendig, um die Regularität der Grammatik zu gewährleisten. Dies entspricht derRechtslinearität der regulären Grammatiken [HU79]. Eine Verletzung der Bedingungen würde


zu Grammatiken führen, die mindestens so ausdrucksstark wie kontextfreie Grammatiken sind,wie folgendes Beispiel zeigt:

offer � book�string � � offer � book �string � � �

Da aber sowohl das Entscheidungsproblem für die Sprachinklusion zweier kontextfreier Spra-chen, als auch die Entscheidung, ob eine kontextfreie Grammatik eine reguläre Sprache erzeugt,unentscheidbar sind [HU79], werden die beiden syntaktischen Bedingungen eingeführt.3 Es wirdvon einer wohlgeformten Grammatik gesprochen, falls jede Produktion der Grammatik diese Be-dingungen erfüllt.

Anmerkung: Analog zu XML-Schema ist es in Heckengrammatiken erlaubt, einen Namen so-wohl als Elementnamen in als auch als Nichtterminalsymbole in � zu verwenden. Eine Un-terscheidung wird in dieser Arbeit durch unterschiedliche Schriftarten vorgenommen.

Zusätzlich sei erwähnt, dass der Kleene-Stern-Operator � � eines Heckenausdrucks in einer Hek-kengrammatik stets durch eine rekursive Regel � � � � � � � darstellbar ist. Um aber die Pro-duktionsmengen in der Darlegung dieser Arbeit nicht durch zusätzliche künstliche Produktionenunnötig zu erweitern, wird am Kleene-Stern-Operator festgehalten.

Will man ermitteln, ob eine Heckengrammatik die geforderten Bedingungen der Wohlgeformt-heit einhält, ist ein weiteres Prädikat notwendig. Für dieses wird zunächst als Hilfsprädikat dieBewachtheit auf regulären Ausdrücken hinsichtlich eines Nichtterminalsymbols definiert. Es gibtan, ob das Nichtterminalsymbol nur im Inhalt eines Elementtyps – also bewacht – auftritt.

Definition 4.6 (Bewachtheit)Die Bewachtheit sei ein Prädikat guarded � �� Reg � � , das für einen regulären Ausdruck� � Reg entscheidet, ob ein Nichtterminalsymbol � �� ausschließlich im Inhalt eines Elementsauftritt:

guarded � � � � � true

guarded � � �� true

guarded � � � � � true

guarded � ��

false falls � � �guarded � � � � mit � � � �� sonst

guarded � � � � � � � � true

guarded � � � � � � � guarded � � � �� guarded � � � �guarded � � � � � � � guarded � � � �� guarded � � � �guarded � � � � � � guarded � � � �

mit � � � , � �� ,�� und �

� � � Reg. �3Als Alternative wären auch analoge Bedingungen möglich, die der Linkslinearität bei regulären Grammatiken

entsprechen.


Mit dem Prädikat ist es nun möglich ein Prädikat zu definieren, das für einen regulären Ausdruckverifiziert, ob dieser hinsichtlich eines Nichtterminalsymbols wohlgeformt ist.

Definition 4.7 (Wohlgeformtheit eines regulären Ausdrucks)Die Wohlgeformtheit eines regulären Ausdrucks � � Reg bezüglich eines Nichtterminalsymbols� �� sei ein Prädikat wellformed � � � Reg � � , das wie folgt definiert ist:

wellformed � � � � � true

wellformed � � �� true

wellformed � � � � � true

wellformed � ��

false falls � � �wellformed � � � � mit � � � �� sonst

wellformed � � � � � � � � true

wellformed � � � � � � � wellformed � � � � � wellformed � � � �wellformed � � � � � � �

�guarded � � � � � wellformed � � � � falls isNullable? � � �guarded � � � � � wellformed’� � � � sonst

wellformed � � � � � � guarded � � � �Dabei sei das Hilfsprädikat wellformed’ wie wellformed definiert mit den folgenden Änderungenfür Nichtterminalsymbole und reguläre Konkatenation:

wellformed’� ��

true falls � � �wellformed’� � � � mit � � � �� sonst

wellformed’� � � � � � � guarded � � � �� wellformed’� � � �mit � � � , � �� ,

�� und �

� � � Reg. �

Somit kann die Wohlgeformtheit einer ganzen Heckengrammatik überprüft werden.

Definition 4.8 (Wohlgeformtheit einer Heckengrammatik)Eine reguläre Heckengrammatik � � � � � � � � � � ist wohlgeformt, falls gilt:

�

�� wellformed � � � �

mit � �� und � � Reg. �

Anmerkung: Die Bedingung der Wohlgeformtheit wird von einer Heckengrammatik, die durchdie Formalisierung einer DTD oder eines XML-Schemas entsteht, stets erfüllt. Dies liegt daran,dass XML-Schema keine rekursiven Gruppen erlaubt und in einer DTD Gruppen nur durch Pa-rameter-Entities nachgebildet werden können, die ebenfalls nicht rekursiv definiert sein dürfen.

Der folgende Satz lässt sich für reguläre Heckengrammatiken aufstellen.


Satz 4.1Die von regulären Heckengrammatiken erzeugten Sprachen entsprechen regulären Baumspra-chen.

Beweis: In [Hos00] werden unter der Bezeichnung reguläre Ausdruckstypen ebenfalls Hecken-grammatiken verwendet. Bis auf den Kleene-Stern unterscheiden sich diese nicht von den Hecken-grammatiken in dieser Arbeit. Da ein Kleene-Stern, wie erwähnt, stets durch eine zusätzlicheProduktion ausgedrückt werden kann, stellt dieser keine Erweiterung des Sprachumfangs dar.In [Hos00] wird die Konstruktion eines regulären Baumautomaten aus einer regulären Hecken-grammatik angegeben, der exakt die gleiche Sprache erkennt, die die Heckengrammatik erzeugt.Weiterhin ist für reguläre Baumautomaten bekannt, dass diese reguläre Baumsprachen akzeptie-ren [RS97]. Somit erzeugen die Heckengrammatiken dieser Arbeit ebenfalls reguläre Baumspra-chen. �

Dass eine Heckengrammatik eine Baumsprache erzeugt, ist zunächst verwunderlich. In [Hos00]wird aber gezeigt, dass eine Hecke stets durch einen Baum darstellbar ist.

Die Hauptaufgabe des Typsystems ist, die Subtyp-Beziehung zweier XML-Typen zu überprüfen.Die Subtyp-Beziehung lässt sich durch eine reguläre Ungleichung ausdrücken und ist über dieHeckensprachen der regulären Ausdrücke definiert.

Definition 4.9 (Reguläre Ungleichung)Eine reguläre Ungleichung, oder kurz Ungleichung, zweier regulärer Ausdrücke sei definiertdurch:

� � � � � � ��

für � � � � Reg. �

Es wird von einer trivial inkonsistenten Ungleichung gesprochen, falls die leere Hecke in derSprache des linken regulären Ausdrucks enthalten ist, aber nicht in der Sprache des rechtenAusdrucks.

Definition 4.10 (Inkonsistenz)Eine reguläre Ungleichung heißt inkonsistent, falls gilt:

inc � � � � � � isNullable? � � �� isNullable? � � �

mit � � � � Reg. �

Für die spätere Formulierung des Subtyp-Algorithmus wird eine Funktion benötigt, die die füh-renden Terminalsymbole eines regulären Ausdrucks ermittelt, was die folgende Funktion leistet.

Definition 4.11 (Führende Terminalsymbole)Die Menge der führenden Terminalsymbole eines regulären Ausdrucks � � Reg sei definiert

4.3. XML-SCHEMA ALS HECKENGRAMMATIK 83

durch die Funktion term � Reg � � � � . Sie ist rekursiv definiert durch:

term � � � � � �term � �� term � � � � � � �term �� term � � � mit � � � ��

term � � � � � � � � � �term � � � � � � term � � � term � � �term � � � � � �

�term � � � term � � � falls isNullable? � � �term � � � falls � isNullable? � � �

term � � � � � term � � �mit � � � , � �� ,

�� und �

� � � Reg. �

Die Operation ist rekursiv definiert und liefert die führenden Terminalsymbole eines regulärenAusdrucks. Trifft die Operation auf ein Nichtterminalsymbol zu, wird die Operation mit dessenProduktionsdefinition aufgerufen. Für die reguläre Konkatenation wird das Prädikat isNullable?herangezogen, um zu ermitteln, ob die Operation rekursiv auf beide oder nur auf den erstenTeilausdruck angewendet werden muss.

4.3 XML-Schema als Heckengrammatik

Die Typüberprüfung eines XOBE-Programms erfolgt mit einem Algorithmus, der auf der Basisvon Heckengrammatiken arbeitet, wie sie im letzten Abschnitt eingeführt wurden. Aus diesemGrund ist es notwendig, dass XML-Typen, die durch Deklaration der Sprachbeschreibung einemXOBE-Programm bekannt sind, in dieser Form dargestellt werden. Dieser Abschnitt definiert dieFormalisierung von XML-Schemata als Heckengrammatiken. Die formale Beschreibung bestehtaus zwei Relationen.

Definition 4.12 (Formalisierung einer Sprachbeschreibung)Gegeben sei ein XML-Schema � , dann ist die Formalisierung von � definiert durch zwei Rela-tionen:

�� formalisiert die Komponente � als regulären Heckenausdruck.

� �� formalisiert die Komponente � als Produktionsregel.

Dabei sei � � Reg und � �� . �

In der Definition der Formalisierungsrelationen steht der Operator � als abkürzende Schreibwei-se für sämtliche Permutationen von Konkatenationen der beteiligten regulären Ausdrücke. Die

Hilfsfunktion occurs, die im Folgenden definiert wird, erweitert einen regulären Ausdruck der-art, dass die Bedingungen der Attribute minOccurs und maxOccurs berücksichtigt werden.So ergibt sich beispielsweise für occurs � � �� das Resultat � � � � � � � �� .Definition 4.13 (Funktion occurs)Die Funktion occurs � Reg � �� Reg ist definiert durch:

occurs � � � � � � � � � � � ��occurs � � � � � � � � �occurs � � � � � � � � � �

occurs � � � � � � � � � � � occurs � � � � � � � � � �occurs � � � � � � � � � � � � �� occurs � � � � � � � � � �

occurs � � � � �� occurs � � � � � � �

�� falls � � �

mit � � Reg, � � � und�� . �

Mit den anschließenden Regeln werden aus den Komponenten des XML-Schemas die regulä-ren Heckenausdrücke ermittelt. In diesen wird die in Abschnitt 4.1 beschriebene Notation ver-wendet. Die Relationen verknüpfen einen Ausdruck des XML-Schemas auf der linken Seite miteinem Ausdruck aus der Heckengrammatik auf der rechten Seite. Dabei wird ein Attribut ei-nes Elements aus dem XML-Schema auf der linken Seite der Relation durch die Angabe von �selektiert. Dadurch müssen nicht alle möglichen Attributkombinationen aufgeführt werden.

Definition 4.14 (Formalisierung mittels Ausdrucksrelation)Die Ausdrucksrelation � � ist durch folgende Regeln definiert:

integer � � integer(INT)

string � � string(STR)

� � � �(IDENT)

� � � � � � � � ��

<all>� � � ��

� � � </all> � � � � � � �� (ALL)

� � � � � � � � ��

<sequence��>� � � ��

� � � </sequence>� minOccurs � �

� � maxOccurs � � � � occurs � � � � ��

(SEQ)

� � � � � � � � ��

<choice��>� � � ��

� � � </choice>� minOccurs � �

� � maxOccurs � � � � occurs � � � � � ��

(CHOICE)

� � �

<group��/>

� ref � �� minOccurs � �� maxOccurs � � � � occurs ��

� �(GROUP REF)

� � �

<element��/>

� ref � �� minOccurs � �� maxOccurs � � � � occurs ��

� �(ELEM REF)

� � � � � � � �<attribute

��/>

� name � � � type � � � � @ � � � �(ATTR)

<complexType��>� � </complexType> ��

<complexType��>� � </complexType> � � �

(COMPL)

<element��>� � </element> ��

<element��>� � </element> � � �

(GLOB ELEM)

<element��>� � </element> ��

<element��>� � </element>

� minOccurs � �� maxOccurs � � � � occurs ��

� �(LOC ELEM)

mit � � �� , � � � � � , @ � �� und � �� und �� Reg. �

In den Regeln INT und STR werden die Datentypen aus dem XML-Schema auf Terminalzei-chen der resultierenden Heckengrammatik abgebildet. Mittels IDENT werden die Bezeichneraus der Sprachbeschreibung als Terminal- oder Nichtterminalsymbole übernommen. Durch dieDefinitionen der Regeln ALL, SEQ und CHOICE werden die Inhaltsmodelle, so wie sie in derSprachbeschreibung formuliert sind, in Heckenausdrücke überführt.

Für Referenzen auf Gruppendefinitionen oder Elementdeklarationen wird durch die RegelnGROUP REF und ELEM REF in der Heckengrammatik das entsprechende Nichtterminalsymbolverwendet. Dies ist immer möglich, da es für jede Gruppendefinition und Elementdeklaration inder Heckengrammatik ein korrespondierendes Nichtterminalsymbol gibt. Mit der Operation oc-curs werden ebenfalls die Zusatzbedingungen bezüglich der Häufigkeit des Auftretens reflektiert.

Durch ATTR wird die Attributdeklaration in einen Heckenausdruck transformiert. Attributtypenwerden in der Heckengrammatik analog zu Elementtypen behandelt. Sie unterscheiden sich le-diglich durch spezielle Terminalzeichen (mit führendem @) und einem einfacheren Inhaltstypen.Durch die Definitionen der Regeln COMPL, GLOB ELEM und LOC ELEM wird auf die im rest-lichen Abschnitt definierte Produktionenrelation �� zur Formalisierung zurückgegriffen, die fürdie Definition eines komplexen Typs oder einer lokalen Elementdeklaration eine Produktion derresultierenden Heckengrammatik erzeugt. Als Ergebnis der Regel wird dann das Nichtterminal-symbol dieser erzeugten Produktion zurückgegeben, das bei lokalen Elementdeklarationen mitder Hilfsoperation occurs gemäß den Bedingungen der Attribute minOccurs und maxOccursangepasst wird.

Anmerkung: Für die Formalisierung eines XML-Schemas wird in dieser Arbeit angenommen,dass alle Bezeichner bereits in einer eindeutigen Form vorliegen. In [W3C01a] wird eine solcheProzedur während der Normalisierung einer Sprachbeschreibung definiert, auf die hier aber nichtnäher eingegangen wird. Dort wird jeder Bezeichner durch den vollständigen Bezeichnerpfadvom Wurzelelement bis zur Definition oder Deklaration in der Sprachbeschreibung (mit demTrennsymbol /) eindeutig qualifiziert. Da eindeutige Bezeichner in Beispielen die Komplexitätunnötig erhöhen, werden im Folgenden die Bezeichner meist eindeutig gewählt, und in diesenFällen die einfachere Ausgangsform beibehalten.

Die zweite Relation die nötig ist, um ein XML-Schema zu formalisieren, benötigt für komplexeTypen, die Zeichenketten im Inhalt zulassen, die folgende Definition der Hilfsfunktion mixed.Sie erzeugt den benötigten Heckenausdruck für den betroffenen Inhaltstyp.

Definition 4.15 (Funktion mixed)Die Funktion mixed � Reg �� Reg ist definiert durch:

mixed � � � � �� true � � � string � � � � string �� string � � � � string �mixed � � � � � �� true � � � � � � �� string �

mixed � � � false � � �

mit � � � � � �� Reg. �

Bei regulären Ausdrücken, die aus einer Konkatenation bestehen, kann Text zwischen sämtlichenTeilausdrücken auftreten, allerdings nur auf der obersten Ebene. Für reguläre Vereinigungen wirdder Text als zusätzliche Alternative zugelassen. Damit kann die Relation, die mit Produktionsre-geln formalisiert wird, angegeben werden.

Definition 4.16 (Formalisierung mittels Produktionenrelation)Die Produktionenrelation �� ist durch folgende Regeln definiert:

� � ��

<element��/>

� name � � � type � � �� (ELEM1)

� � ��

<element��>� � </element>

� name � �� (ELEM2)

� � � ��

<group��>� � </group>

� name � ��

� �(GROUP)

� � � ��

��

<complexType��>� � � � </complexType>

� name � � � mixed � ��

� �� mixed � �� (COMPL)

� � � � � � � ��

<complexType��><simpleContent>

<extension base=" � "> � � </extension></simpleContent></complexType>� name �

��

(SIMPL)

� �� mit � , � � und � � �

...� �� mit �� , � � und � �

<schema��>

� � � �� </schema> �� mit � � � �

(SCHEMA)mit � �� ,

�� ,

�� ,

�� und �

��

��

�� Reg. �

Durch die Regeln ELEM1 und ELEM2 werden für Elementdeklarationen, die innerhalb von kom-plexen Typen lokal oder auf obersten Ebene global auftreten können, Produktionen erzeugt. Da-bei muss zwischen einer Deklaration mit Typreferenz und einer Deklaration mit anonymen Ty-pen unterschieden werden. Für Gruppen- und Elementdefinitionen werden mit GROUP, COMPL

und SIMPL ebenfalls eigene Produktionen generiert. Mit der letzten Regel SCHEMA wird ausden einzelnen Produktionen, die durch die Transformationen der einzelnen Komponenten derSprachbeschreibung gewonnen wurden, eine Heckengrammatik aufgebaut.

Anhand eines Beispiels wird die Formalisierung eines XML-Schemas verdeutlicht.

Beispiel 4.3Dieses Beispiel zeigt die Formalisierung des komplexen Typs t_items aus dem XML-SchemaSIF (Abschnitt 2.1) als Produktion einer regulären Heckengrammatik durch die obigen Relatio-

nen und Regeln. Zur Vereinfachung der Darstellung soll gelten:� �� <element name="article" type="integer"

minOccurs="0" maxOccurs="unbounded"/>� �� <element name="description" type="string" minOccurs="0"/>

Abbildung 4.1 zeigt nun den vollständigen Transformationsbaum, der bei der Generierung derProduktion entsteht. Es wird deutlich, dass neben der Produktion für t_items noch Produktionen

IDENT

t_items � � t_items

IDENT

article � � � � � � � � � INT

integer � � integer�� article � article integer ��

� �� article � � � � article �

IDENT

description � � �� STR

string � � string�� description � description string��

� �� description � � � � description �<sequence>��

</sequence>

� � article �� description � �<complexType name="t_items"><sequence>��

</sequence></complexType>

�� t_items � article �� description � �

Abbildung 4.1: Formalisierung einer Schemakomponente

für die Elementtypen article und description entstehen. Insgesamt ergibt sich die Grammatik� � � � � � � � � shopRequest

�shopResponse � � � � mit:

� � � integer � t_request � , � � shopRequest � shopResponse � shoppingCart � account � add �

remove � get � request � items � article � description � ,� � � t_shopRequest � t_cartRequest � t_shopResponse � t_cartResponse �

t_items � shopRequest � shopResponse � t_shopRequest/shoppingCart �t_shopResponse/shoppingCart � account � add � remove � get � request �items � article � description � und

� � � t_shopRequest � t_shopRequest/shoppingCart �t_cartRequest � � account � � add

�remove

�get � � �

t_shopResponse � t_shopResponse/shoppingCart �t_cartResponse � � account � request � � items

� �� t_items � � article � � � description

� �� shopRequest � shopRequest

�t_shopRequest� �

t_shopRequest/shoppingCart � shoppingCart�t_cartRequest � �

account � account�integer � �

4.4. TYPINFERENZ FÜR XML-KONSTRUKTOREN 89

add � add�integer� �

remove � remove�integer � �

get � get� � � �

shopResponse � shopResponse�t_shopResponse � �

t_shopResponse/shoppingCart � shoppingCart�t_cartResponse� �

request � request�integer� �

items � items�t_items � �

article � article�integer� �

description � description�string � � .4

�

XML-Schema bietet sehr weitreichende Möglichkeiten, um die Dokumente einer Auszeichnungs-sprache zu beschreiben. Aufgrund dieses beträchtlichen Umfangs konzentriert sich diese Ar-beit auf den grundlegenden Kern. Nicht betrachtet werden in dieser Arbeit Inhaltsmodelle vomTyp any, Einschränkungen einfacher Typen („simple type restriction“), Attributgruppen, Ele-menttypen mit nil-Werten (Attribut nillable), Verhinderung von Typsubstitution (Attributblock), Erzwingen einer Ableitung durch abstrakte komplexe Typen (Attribut type) und ab-strakte Elementdeklarationen („substitution group“), Verhinderung von Ableitungen (Attributfinal) sowie alle weiteren Nebenbedingungen (Elemente unique, key, keyref).

4.4 Typinferenz für XML-Konstruktoren

In diesem Abschnitt wird die Typinferenz definiert, die notwendig ist, um für einen XML-Kon-struktor den zugehörigen Typen zu ermitteln. Wie bereits oben beschrieben, wird bei der Typana-lyse eines XOBE-Programms der Typ sämtlicher XML-Konstruktoren inferiert. Da alle Variablenvor der Verwendung deklariert sein müssen, gestaltet sich die Typinferenz als nicht besondersschwierig. Die formale Beschreibung besteht zunächst aus einem Typisierungsurteil.

Definition 4.17 (Typisierungsurteil für XML-Konstruktor)Gegeben sei eine Menge von Variablendeklarationen � , dann wird das folgende Typisierungsur-teil definiert:

� ��

ist ein wohlgeformter XML-Konstruktor vom Typ � in �

Dabei sei � � Reg. �

Mit den anschließenden Typisierungsregeln kann der Typ eines XML-Konstruktors berechnetwerden. Die Definition verwendet die Operation lexType, die den von der lexikalischen Analyseidentifizierten Basisdatentypen liefert.

4Der Elementtyp shoppingCart ist durch zwei unterschiedlich lokale Deklarationen definiert, die durch ein-deutige Bezeichner unterschieden sind.

Definition 4.18 (Typinferenz XML-Konstruktor)Der Typ eines XML-Konstruktors sei definiert durch folgende Inferenzregeln:

� � � � � lexType � � � � (VAL)

� � � � � � � � � ��

� � �= � � � � � � � � (ATTR)

� �� ...

� ��

� �� (ATTRS)

� � � � �� (VAR)

� �� lexType � � � � (DATA)

� � ��

� ��

� ��

� � < � � � >� � </ �

> � � � �� (ELEM)

� ��

�� < � � � /> � � � � � (EMPTY)

� ��

...� �

� � � � � ��

� � � �� (CONC)

mit � � � � ,�� , � � � � � �� Reg und der Ausdrucksrelation � � . �

Mit den Regeln VAL, ATTR und ATTRS wird ermittelt, wie sich der Typ eines Attributwertes,eines Attributs und einer Attributliste zusammensetzt. Die Typen von Variablen, die bereits durchdie Deklaration der Variablen bekannt sind, werden innerhalb eines XML-Konstruktors durch dieRegel VAR eingesetzt. Dabei wird nicht zwischen Variablen der Programmiersprache Java undVariablen von XML-Objekt-Klassen unterschieden.

Im Inhalt eines Elements können neben Elementen auch Zeichendaten auftreten, deren Typ durchdie Regel DATA mit der Operation lexType bestimmt wird. Die Regel ELEM ermittelt den Typen

4.5. TYPINFERENZ FÜR XPATH-AUSDRÜCKE 91

für ein XML-Element mit nicht leerem Inhalt, während mit EMPTY dies – ganz analog – für dieabkürzende Schreibweise der leeren Elemente geschieht. Die letzte Regel CONC inferiert denzusammengesetzten Typ für die Konkatenation von Elementen oder Zeichendaten, wie sie imInhalt von Elementen auftreten kann.

Mit dem folgenden Beispiel wird die Arbeitsweise der Typinferenz illustriert.

Beispiel 4.4In der Methode addArticle des Beispiels aus Abschnitt 3.3 wird ein XML-Objekt mittelseiner return-Anweisung zurückgegeben. Der Typ der Variable accountNr wurde zuvor alsint deklariert.

1 re turn < shopResponse >2 < s h o p p i n g C a r t >3 < accoun t >{ t h i s . a ccoun tNr } </ accoun t >4 < r e q u e s t > p r o c e s s e d < / r e q u e s t >5 </ s h o p p i n g C a r t >6 </ shopResponse > ;

Für diesen XML-Konstruktor kann nun anhand der definierten Regeln der aktuelle Typ inferiertwerden. In der Abbildung 4.2 wird die Berechnung für die inneren beiden Elemente dargestellt.

VAR��

{this.accountNr} � integer��

<account>{this.accountNr}</account> � account integer� DATA

��processed � string

��<request>processed</request> � request string�

�� <account>{this.accountNr}</account><request>processed</request>

� account integer � � request string�

Abbildung 4.2: Berechnung der Typinferenz

Für den gesamten XML-Konstruktor ergibt sich dann folgender Typ:

shopResponse�shoppingCart

�account

�integer � � request �string � � �

�

4.5 Typinferenz für XPath-Ausdrücke

Dieser Abschnitt formalisiert die Typinferenz für XPath-Ausdrücke in XOBE-Programmen. DieTypanalyse benötigt für die Überprüfung der Typkorrektheit von XOBE-Programmen die Ty-pen der XPath-Ausdrücke, die anhand von Regeln inferiert werden können. Zur Verfügung dafürsteht analog zur Typinferenz der XML-Konstruktoren eine Umgebung mit den Typen der Va-riablen, da alle Variablen im Programm vor der Verwendung deklariert sein müssen. Mit einemTypisierungsurteil wird die Typinferenz von XPath-Ausdrücken formal beschrieben.


Definition 4.19 (Typisierungsurteil für XPath-Ausdrücke)Gegeben sei eine Menge von Variablendeklarationen � , dann ist das folgende Typisierungsurteildefiniert:

� � � � � � ist ein wohlgeformter XPath-Ausdruck vom Typ � in �

Dabei sei � � Reg. �

Anmerkung: Für die Typen der XPath-Ausdrücke gilt die Besonderheit, dass es sich um Ty-pen der Form � � � � � � � � �� mit

� � �� und � � � Reg handelt. Die Ursache dafür liegtin der Definition von XPath deren Ausdrücke stets eine Liste von XML-Knoten (eigentlich ei-ne Knotenmenge) zurückgeben. Im Weiteren wird die reguläre Vereinigung von Elementtypen�� innerhalb des Kleene-Stern-Operators auch mit XPath-Typ bezeichnet.5

Um die Typinferenz für XPath-Ausdrücke zu definieren werden einige Hilfsfunktionen benö-tigt. Die erste Hilfsfunktion nodeTest, die angegeben wird, ermittelt den XPath-Typen für einenKnotentest. Anschließend folgt mit self , child, attribute, descendant, parent, ancestor, follow-ingSibling und precedingSibling für jede Achse in XPath eine weitere Hilfsfunktion.

Definition 4.20 (Funktion nodeTest)Die Funktion nodeTest � � Reg � Reg liefert für einen Elementnamen

�� die Typen aus

dem XPath-Typ � � Reg, die den Elementnamen�

haben. Die Definition ist rekursiv:

nodeTest � � � � � �

nodeTest � � � � � � � �� falls

� � ��

sonst

nodeTest � � � � � � � nodeTest � � � � � nodeTest � � � �

mit�� und �

� � � Reg. �

Die Funktion nodeTest selektiert aus einem XML-Typen genau die Elementtypen, die den ange-gebenen Elementnamen aufweisen.

Mit der Funktion self wird der XPath-Typ für die Selbst-Achse ermittelt.

Definition 4.21 (Funktion self )Die Funktion self � Reg � Reg liefert den XPath-Typ eines regulären Ausdrucks � � Reg undwird durch die zweistellige Hilfsfunktion self definiert:

self � � � � self � � � � � �5Um XPath-Typen möglichst kompakt darzustellen, werden Wiederholungen wie �� implizit aufgelöst zu � .


Die Hilfsfunktion self � Reg �� Reg ist rekursiv definiert durch:

self � � � ��

self � � � ��

self � � � ��

self ��

falls � �� ,self � � � �� mit � � � �� sonst

self � � � � � � �� falls

�� @�

,�

sonst

self � � � � � �� self � � � �� self � � � �� self � � � � � �� self � � � �� self � � � �� self � � � � �� self � � � ��

mit � � � , � �� ,�� @

�� , � � � � Reg und �� . �

Die Hilfsfunktion self ermittelt für den angegebenen regulären Ausdruck, die im Ausdruck ent-haltenen Elementtypen. Diese werden in Form einer regulären Vereinigung kombiniert, wie es fürXPath-Typen notwendig ist. Dafür wird in einer Menge �� von Nichtterminalsymbolen notiert,welche Nichtterminalsymbole bereits bearbeitet wurden. Bei noch nicht behandelten Nichttermi-nalsymbolen erfolgt eine rekursive Anwendung der Funktion auf die Definition der Produktions-regel, während bei einem schon bekannten Nichtterminalsymbol der Rekursionszweig beendetwird. Auf diese Art und Weise ist es möglich, Endlosschleifen zu vermeiden. Attributtypen blei-ben genauso wie Basisdatentypen, reguläre Konkatenation und Kleene-Stern unberücksichtigt.

Die Funktion child berechnet die XPath-Typen zur Kind-Achse.

Definition 4.22 (Funktion child)Die Funktion child � Reg � Reg liefert die XPath-Typen der Kinderknoten eines XPath-Typs� � Reg und ist rekursiv definiert:

child � � � � �

child � � � � � � � self � � �child � � � � � � child � � � � child � � �

mit�� und �

� � � Reg. �

Die Funktion child ist für XPath-Typen rekursiv definiert und berechnet mit Hilfe der Funktionself die Elementtypen der Kinderknoten des übergebenen XPath-Typen.

Um die XPath-Typen der Attribut-Achse zu ermitteln, wird die Funktion attribute definiert.

Definition 4.23 (Funktion attribute)Die Funktion attribute � Reg � Reg liefert die XPath-Typen der Attribute eines XPath-Typs


� � Reg und ist rekursiv definiert:

attribute � � � � �

attribute � � � � � � � attribute � � � � � �attribute � � � � � � attribute � � � � attribute � � �

mit�� und �

� � � Reg. Die Hilfsfunktion attribute � Reg �� Reg ist bis auf folgendeAusnahme analog zur Hilfsfunktion self � Reg �� Reg definiert:

attribute � � � � � � �� falls

� � @�

,�

sonst

mit�� @

�� , � � Reg und �� . �

Die Attributtypen eines regulären Ausdrucks werden mit der zweistelligen Hilfsfunktion attri-bute extrahiert. Darauf aufbauend können die Attribute eines XML-Typen durch die Funktionattribute rekursiv ermittelt werden.

Mit der Funktion descendant werden die Typen gemäß der Nachfahr-Achse berechnet.

Definition 4.24 (Funktion descendant)Die Funktion descendant � Reg � Reg liefert XPath-Typen der Nachfahren eines regulärenAusdrucks � � Reg und ist rekursiv definiert:

descendant � � � � �

descendant � � � � � � � descendantOrSelf � � � � � �descendant � � � � � � descendant � � � � descendant � � �

für alle�� und �

� � � Reg. Die Hilfsfunktion descendantOrSelf � Reg �� Reg ist bisauf nachstehende Ausnahme analog zur Hilfsfunktion self � Reg �� Reg definiert:

descendantOrSelf � � � � � � ��

descendantOrSelf � � � �� falls�� @

�,

descendantOrSelf � � � �� sonst

mit�� @

�� , � � Reg und �� . �

Ähnlich zur Definition der Funktion attribute wird die Funktion descendant konstruiert. DerUnterschied liegt darin, dass für die Achse der Nachfahren nun auch die Inhalte der Elementtypenrekursiv betrachtet werden.

Für die Eltern-Achse wird die Funktion parent festgelegt.

Definition 4.25 (Funktion parent)Die Funktion parent � Reg � Reg liefert XPath-Typen der Elternknoten eines regulären Aus-


drucks � � Reg und ist durch eine vierstellige Hilfsfunktion parent definiert:

parent ��

parent �� mit � � � � � ��

und � � � � � � � � self � � � mit � � � ��

Die Hilfsfunktion parent � Reg � � � � � � Reg � Reg � Reg ist rekursiv definiert wie folgt:

parent ��

parent ��

parent ��

parent �� falls � ��

sonst

parent ��

parent �� falls � � � � � �parent �� sonst

parent �� parent �� parent �� parent �� parent �� parent ��

parent �� parent �� mit � � � , � �� ,

�� , � � � � � � � � Reg und � � � � . �

Die Funktion parent arbeitet mit Unterstützung der Hilfsfunktion parent, deren Aufruf mit vierParametern erfolgt. Der Parameter � ist dabei der Elementtyp, von dem die Elementtypen derEltern gesucht werden. Die Menge � � besteht aus den Nichtterminalsymbolen, die � als Subtypim XPath-Typ der Selbst-Achse einschließt. Der Parameter � akkumuliert den aktuellen Elterntypund � steht für den gerade betrachteten regulären Heckenausdruck.

Die Idee der Berechnung ist, dass für jedes Nichtterminalsymbol in der Heckengrammatik über-prüft wird, ob dessen Produktion den übergebenen Elementtyp als Subtyp enthält. Wird dann inder Betrachtung des regulären Ausdrucks ein solches Nichtterminalsymbol gefunden, wird derakkumulierte Elterntyp zurückgegeben. Nichtterminalsymbole werden demnach nicht rekursivbehandelt. Stattdessen wird getestet, ob ein Nichtterminalsymbol in Menge � � ist, die voraberstellt wurde.

Für die Vorfahr-Achse wird die Funktion ancestor angegeben.

Definition 4.26 (Funktion ancestor)Die Funktion ancestor � Reg � Reg liefert XPath-Typen der Vorfahrknoten eines regulärenAusdrucks � � Reg und ist durch eine vierstellige Hilfsfunktion ancestor definiert:

ancestor ��

ancestor �� mit � � � � � ��

und � � � � � � � � self � � � mit � � � ��


Die Hilfsfunktion ancestor � Reg �� Reg � Reg � Reg ist bis auf folgende Ausnahmeanalog zur Hilfsfunktion parent definiert:

ancestor ��

ancestor �� falls � � � � � �ancestor �� sonst

mit�� ,

�� Reg und � � � � . �

Die Definition der Funktion ancestor entspricht der Idee, die bei der Realisierung der Funktionparent verfolgt wurde. Der Unterschied liegt darin, dass in der vierstelligen Hilfsfunktion ance-stor nicht nur der aktuelle Elterntyp akkumuliert wird, sondern der Typ sämtlicher Vorfahren.

Auch für die Berechnung des Typs der Nachfolgende-Geschwister-Achse wird eine Funktionfestgelegt.

Definition 4.27 (Funktion followingSibling)Die Funktion followingSibling � Reg � Reg liefert XPath-Typen der nachfolgenden Geschwi-sterknoten eines regulären Ausdrucks � � Reg und ist durch eine vierstellige Hilfsfunktion fol-lowingSibling definiert:

followingSibling ��

followingSibling �� mit � � � � � ��

und � � � � � � � � self � � � mit � � � ��

Die Hilfsfunktion followingSibling � Reg � � � � � � Reg � Reg � Reg ist rekursiv definiert wiefolgt:





falls � �� sonst


followingSibling �� falls � � � � � �followingSibling �� sonst

followingSibling �� followingSibling �� followingSibling ��

followingSibling �� followingSibling �� self � � � � � � �followingSibling ��

followingSibling �� followingSibling �� self � � � � � �mit � � � , � �� ,

�� ,

�� Reg und � � � � . �


Die Grundidee der vierstelligen Hilfsfunktion followingSibling, mit der die Funktion following-Sibling definiert ist, folgt ebenfalls wieder der Hilfsfunktion parent. Diesmal werden aber dieTypen der folgenden Geschwisterknoten in dem Parameter

�akkumuliert.

Es folgt ein Beispiel, das die Funktion followingSibling auf einen regulären Ausdruck anwendet.

Beispiel 4.5Dieses Beispiel ermittelt den Typen der folgenden Geschwisterknoten für den regulären Aus-druck � � title

�string � gemäß der durch die Sprachbeschreibung AOML (Beispiel 2.2)

induzierten Heckengrammatik. Für die Menge � � ergibt sich � � � � title � . Nun wird die vier-stellige Hilfsfunktion followingSibling für jedes Nichtterminalsymbol berechnet, beginnend mitaoml:

followingSibling �� aoml � antiquary � offer � �� followingSibling �� antiquary � offer �� followingSibling �� self � offer � � antiquary ��followingSibling �� offer �

� �

Analoge Resultate ergeben sich für die Nichtterminalsymbole antiquary, name, address, email,offer, author, condition, artist, price und fields. Für die Nichtterminalsymbole book und recordwerden dagegen relevante Typen gefunden:

followingSibling �� book � title � � author� �� fields � �

� followingSibling �� title � � author� �� fields �

� followingSibling �� self � � author� �� fields � � title �

�followingSibling �� self � fields � � author

� ��followingSibling �� fields �

� self � � author� �� fields �

followingSibling �� record � title � artist � fields � � � self � artist � fields �Der Typ title kann dagegen nicht nach � stehen, was sich in diesem Aufruf zeigt:

followingSibling �� title �string � � � followingSibling �� string ��

Insgesamt erhält man das Resultat:

followingSibling �� self � author � � self � artist � � self � fields �

�

Die Definition der Funktion precedingSibling für die Vorherige-Geschwister-Achse erfolgt ana-log zur vorherigen Funktion followingSibling.


Definition 4.28 (Funktion precedingSibling)Die Funktion precedingSibling � Reg � Reg liefert XPath-Typen der zuvor stehenden Geschwi-sterelemente eines regulären Ausdrucks � � Reg und ist analog zu followingSibling definiert.

�

Mit diesen Hilfsfunktionen kann mit den anschließenden Regeln festgelegt werden, welche Ty-pen für einen XPath-Ausdruck abzuleiten sind.

Definition 4.29 (Typinferenz XPath-Ausdrücke)Der Typ eines XPath-Ausdrucks sei definiert durch folgende Inferenzregeln:

� � � � � �� self � � � �

(VAR)

� ��

� �� /child � child � � � �

(CHILD)

� � � � � � �

� � � � /descendant � descendant � � � �(DESC)

� � � � � � �

� � � � /parent � parent � � � �(PAR)

� � � � � � �

� � � � /ancestor � ancestor � � � �(ANC)

� � � � � � �

� � � � /following_sibling � followingSibling � � � �(FOLL SIB)

� � � � /ancestor-or-self � � �

� � � � /following � descendant � followingSibling � � � � �(FOLL)

� � � � � � �

� � � � /preceding_sibling � precedingSibling � � � �(PREC SIB)

� �� /ancestor-or-self � � �

� � � � /preceding � descendant � precedingSibling � � � � �(PREC)

� �� /descendant � � � � � � �

�� /self � � � �

� �� /descendant-or-self � � � � � � � � �

(DESCOS)

� � � � /ancestor � � � � � � �� /self � � � �

� �� /ancestor-or-self � � � � � � � � �

(ANCOS)

� ��

� �� /attribute � attribute � � � �

(ATTR)

� � ��

�� /

� � � � �

� �� /

� � :: � � nodeTest � � � � �(TEST)

mit�� , � � � � � � � � Reg und der Ausdrucksrelation � � . �


Für eine Variable in einem XPath-Ausdruck wird durch die Regel VAR der deklarierte Typ un-ter Anwendung der Hilfsfunktion self zu einem XPath-Typ umgeformt. Mit den Regeln CHILD,ATTR, DESC, PAR, ANC, FOLL SIB, FOLL, PREC SIB, PREC, DESCOS und ANCOS berech-nen sich die XPath-Typen der Knoten, die durch die jeweiligen Achsen selektiert werden. Dabeikommen die Funktionen child, attribute, descendant, parent, ancestor, followingSibling und pre-cedingSibling zur Anwendung. Der Knotentest in XPath schränkt den Typen der Knoten einerAchse ein, was die Funktion nodeTest, die in Regel TEST angewendet wird, ausdrückt.

Die Arbeitsweise der Typinferenz illustrieren die nachstehenden Beispiele. Das erste einfacheBeispiel beschränkt sich auf Anwendung der Regeln aus Definition 4.29, die auf den eingeführtenHilfsfunktionen nodeTest, self und child basieren.

Beispiel 4.6In diesem Beispiel sei die Variable b vom Typ book und gesucht wird der Typ des XPath-Ausdrucks b/child::author aus Beispiel 2.5 (Abschnitt 2.2). Die Abbildung 4.3 zeigt wie

VAR

b � self � book � �b/child � child � book title � � author � � � fields � � �

b/child::author � nodeTestauthor � � title string � author string � article string� condition string� price string� � � �

Abbildung 4.3: Typinferenz eines Ausdrucks mit Kind-Achse

unter Anwendung der Regeln VAR, CHILD und TEST aus Definition 4.29 der Typ des Ausdrucksinferiert wird. Nach Auswertung der Funktion nodeTest in der letzten Zeile der Abbildung ergibtsich abschließend:

b/child::author � � author �string � � �

�

Das folgende Beispiel illustriert ebenfalls die Arbeitsweise der Typinferenz.

Beispiel 4.7Die Variable t sei für dieses Beispiel vom Typ title. Inferiert werden soll der Typ des XPath-Ausdrucks t/parent::book. In der Abbildung 4.4 ist der Ableitungsbaum für den Ausdruck

VAR

t � self � title � �t/parent � parent � title string� � �

t/parent::book � nodeTestbook � book title � � author � � � fields � record title � artist � fields � � �Abbildung 4.4: Typinferenz eines Ausdrucks mit Eltern-Achse

dargestellt. Anwendung finden die Regel VAR, PAR und TEST aus Definition 4.29. Bei der Aus-wertung der Funktion parent in Regel PAR ergibt sich für die Menge der bezüglich dieser Achserelevanten Nichtterminalsymbole � � � � title � . Dies bedeutet, dass all die Elementtypen, in


deren Inhaltsmodellen das Nichtterminalsymbol title auftritt, mögliche Elementtypen der Eltern-knoten sind. Die Auswertung der Funktion nodeTest in der letzten Zeile der Ableitung resultiertschließlich in der folgenden Typzuordnung:

t/parent::book � � book � title � � author� �� fields � � �

�

4.6 Algorithmus zur Typüberprüfung

Nachdem die formalen Grundlagen eingeführt sind und die Typinferenz für XML-Konstruktorenund XPath-Ausdrücke feststeht, folgt in diesem Abschnitt die formale Definition des Algorith-mus zur Überprüfung der Subtyp-Beziehung für XML-Typen.

Das Vorgehen des Algorithmus fundiert auf der algorithmischen Idee von Antimirov [Ant94]zur Überprüfung von Ungleichungen von regulären Ausdrücken. Antimirov zeigt, dass für je-de ungültige reguläre Ungleichung mindestens eine reduzierte Ungleichung existiert, die trivialinkonsistent ist. Dabei ist eine reguläre Ungleichung genau dann trivial inkonsistent, wenn dasleere Wort Element der Sprache, repräsentiert durch den Ausdruck der linken Seite, ist, aber nichtElement der Sprache der rechten Seite. Diese Eigenschaft lässt sich auf einfache Art überprüfen.Ebenfalls ist es nicht schwer, die reduzierten Ungleichungen zu berechnen. Da es sich aber imFalle von XML-Typen nicht um reguläre Ausdrücke handelt, sondern um reguläre Heckenaus-drücke, die auf einer Heckengrammatik basieren, bedarf es einer Erweiterung von AntimirovsAlgorithmus auf Heckengrammatiken.

Die Darstellung des Subtyp-Algorithmus beginnt mit den Definitionen von partiellen Ableitun-gen für reguläre Heckenausdrücke und regulären Ungleichungen. Anschließend erfolgt die Defi-nition des Algorithmus selbst mit der Anwendung auf ein kleines Beispiel. Der Abschnitt endetmit Anmerkungen zur Komplexität.

Im Algorithmus werden reduzierte Ungleichungen berechnet, die aus reduzierten regulären Aus-drücken bestehen. Diese entstehen durch die sogenannte partielle Ableitung regulärer Ausdrücke.Eine partielle Ableitung reduziert einen regulären Ausdruck um das führende Terminalsymbol.Für die Definition der partiellen Ableitung ist eine erweiterte Konkatenation für reguläre Aus-drücke nötig, die Mengen von Tupeln als ersten Parameter zulässt. Sie ist wie folgt definiert.

Definition 4.30 (Erweiterte Konkatenation auf Mengen von Tupeln)Die Erweiterung der Konkatenation auf Mengen von Tupeln �� Reg � Reg � � Reg � � � Reg �

4.6. ALGORITHMUS ZUR TYPÜBERPRÜFUNG 101

Reg � sei wie folgt definiert:� � � � � ��

� � � � � � � � � � � ��

� � � � � � � � � � � � � � � � � � �mit

�� Reg � Reg, � � � � Reg �� und � � Reg �� . �

Damit kann die partielle Ableitung mit folgender Definition formal spezifiziert werden.

Definition 4.31 (Partielle Ableitung eines regulären Ausdrucks)Die partielle Ableitung hinsichtlich des Terminalsymbols � �� wird berechnet durch die Funk-tion der � � Reg � � � Reg � Reg � . Sie ist rekursiv definiert durch:

der � � � � � der � � �� der � �� der � � � � mit � � � ��

der � � � � �� falls � � � und � � � ,

� � sonst

der � � � � � � � �� falls

� � � und � �� ,

� � sonst

der � � � � � � � der � � � � der � � � �der � � � � � � �

�der � � � � � � falls � isNullable? � � �der � � � � � � der � � � � falls isNullable? � � �

der � � � � � � der � � � � � � �

mit � � � , � �� ,�� und �

� � � Reg. �

Um einen Eindruck zu bekommen, was die Operation der angewendet auf einen regulären Aus-druck leistet, wird nun ein kurzes Beispiel betrachtet.

Beispiel 4.8Dieses Beispiel bezieht sich auf die Heckengrammatik aus Beispiel 4.3. Es wird der reguläreAusdruck �� account

�integer � � request � t_request �

betrachtet. Für diesen wird die partielle Ableitung hinsichtlich des Terminalsymbols accountberechnet. Es ergibt sich die Ergebnismenge

deraccount � � � � � � integer � request � t_request � � � .


Die Menge besteht in diesem Fall nur aus einem Tupel. Die erste Komponente des Tupels istder reguläre Ausdruck, der den Inhalt des reduzierten Terminalsymbols beschreibt. In diesemFall also den Inhalt des reduzierten account-Elements. Der reguläre Ausdruck der zweitenKomponente ist der um das Element account reduzierte Ausdruck � . �

Das Beispiel zeigt nicht, dass für einen regulären Ausdruck im Allgemeinen eine Menge regu-lärer Ausdrücke als partielle Ableitung entstehen kann. Dies ist bei Ausdrücken mit regulärerVereinigung oder einer Konkatenation mit einem führenden Ausdruck der Fall, dessen Sprachedie leere Hecke enthält. Jedes Element der partiellen Ableitung ist ein Paar, dessen Komponen-ten mit den zwei Dimensionen einer regulären Hecke korrespondieren. Die erste Komponentesteht für die Vater-Kind-Dimension, während die zweite Komponente der Geschwister-Dimen-sion entspricht.

Aufbauend auf der partiellen Ableitung für reguläre Ausdrücke wird von Antimirov die partielleAbleitung für reguläre Ungleichungen eingeführt. Für den Fall der Heckengrammatiken wird die-se Definition schwierig, weil durch die partielle Ableitung der regulären Ausdrücke Paare entste-hen. Ausgenutzt werden kann aber eine mengentheoretische Beobachtung von Hosoya, Vouillonund Pierce [HVP00], die hier als Satz formuliert wird. Ein Beweis findet sich in Anhang B.

Satz 4.2 (Teilmengenbeziehung des Karthesischen Produkts)Gegeben seien die Mengen

�, � , � � , . . . ,

�

� und� � , . . . ,

� � , dann gilt:� � � � � � � � �

� � ��

� � � � � � � � � � � � � � � � � � � ��

mit � � � � � �� und� � � � � � �� .

Dabei bezeichnet � die Potenzmenge einer Menge. �

Der Satz ermöglicht die Umformung der Teilmengenbeziehung auf der linken Seite der Äquiva-lenz, die für Karthesische Produkte gilt, in Teilmengenbeziehungen auf der rechten Seite, die sichauf einfache Mengen beziehen. Das nachstehende Beispiel illustriert die mögliche Anwendungder Satzes.

Beispiel 4.9Die gegebenen Teilmengenbeziehung

� � �� true � � � � � � false � � � �wird mit Hilfe von Satz 4.2 zu

� � � � � �� true � � ��

� � � � false � � �� umgeformt. �


Da der Subtyp-Algorithmus, der im Folgenden definiert wird, nur mit Teilmengenbeziehungenauf einfacher Mengenebene nicht aber mit Teilmengenbeziehungen auf Karthesischen Produktenumgehen kann, ist diese Umformung essentiell.

Um Satz 4.2 bei der Definition der partiellen Ableitung regulärer Ungleichungen anzuwenden, istzunächst daran zu erinnern, dass reguläre Ausdrücke Mengen von Hecken beschreiben. Erfolgtnun eine Reduktion von �

� � einer regulären Ungleichung � � � mittels der partiellen Ableitungfür reguläre Ausdrücke hinsichtlich eines führenden Terminalsymbols � , so gilt weiterhin dieUngleichung

� � � � � � � � � � �� mit der � � � � � � � � ��

für alle � � � � � �� der � � � � . Diese Teilmengenbeziehung ist nun nach Satz 4.2 äquivalent zu

� � � � � � � � � � � � � � � � � � � � �� mit � � � � � �� und

� � � � � � �� und

der � � � � � � � � �� .In der folgenden Definition der partiellen Ableitung regulärer Ungleichungen werden die entstan-denen Disjunktionen von Ungleichungen der obigen Konjunktion in einer Menge zusammenge-fasst. Ebenfalls werden wieder die Operationen auf regulären Ausdrücken anstatt der Mengen-operatoren verwendet. Somit wird die Mengenvereinigung durch die reguläre Vereinigung

�

und die Teilmengenrelation � durch das Symbol der regulären Ungleichung � ersetzt.

Definition 4.32 (Partielle Ableitung regulärer Ungleichungen)Die partielle Ableitung einer regulären Ungleichung � � � mit � � � � Reg hinsichtlich einesTerminalsymbols � �� ist definiert durch:

part � � ��

��

� � � � � � � � der � � � � �der � � � � � � � � �� mit

�� und

� � � � � �� mit

� � � � � �� Reg. �

Die partielle Ableitung einer regulären Ungleichung ist damit eine Menge, deren Elemente auszweistelligen Disjunktionen von regulären Ungleichungen bestehen. Das folgende Beispiel ver-anschaulicht diese Definition.

Beispiel 4.10In diesem Beispiel gelte nach der Heckengrammatik aus Beispiel 4.3

� � description � � account �integer� � description � �

� � � description �string � � account �integer� � � � description


für die reguläre Ungleichung � � � , für die die partielle Ableitung hinsichtlich descriptionberechnet werden soll. Die dafür notwendigen partiellen Ableitungen der linken und rechtenSeiten sind folgende:

derdescription � � � � � � string � � account �integer � � description � � � �derdescription � � � � � � string � account �integer � � � � � � string � ��

Dies ergibt für die partielle Ableitung der Ungleichung die Menge

partdescription � �� string � string �string �

� account �integer � � description � � ��

� string � string �� account �integer � � description � � � ��

� string � string �� account �integer � � description � � � account

�integer � � � � �

� string � � �� account �integer � � description � � � � account �integer � � � � � ��

mit vier Disjunktionen. �

Nach der Definition der partiellen Ableitung für reguläre Ungleichungen ist es nun möglich, dieRegeln für den Subtyp-Algorithmus anzugeben.

Der Algorithmus testet, ob es sich bei der zu überprüfenden Ungleichung um eine trivial inkonsi-stente Ungleichung handelt. Ist dies nicht der Fall, kann nicht direkt entschieden werden, ob dieUngleichung korrekt ist. Stattdessen werden von der zu überprüfenden regulären Ungleichungsämtliche ableitbaren partiellen Ableitungen berechnet. Dafür werden zunächst die führendenTerminalsymbole der linken Seite der Ungleichung durch die Funktion term ermittelt. Um die-se Terminalsymbole erfolgt die Verkürzung der regulären Ungleichung mit der Operation part.Auf die erzeugten Ungleichungen in den Disjunktionen der partiellen Ableitungen kann der Al-gorithmus rekursiv angewendet werden. Ist eine dieser Disjunktionen nicht korrekt, ist die zuüberprüfende Ungleichung falsch. In allen anderen Fällen wird die gegebene reguläre Unglei-chung als korrekt erkannt.

Der Subtyp-Algorithmus ist definiert durch zwei Subtyp-Urteile � � � � � � � � und � � � � �� mit der Menge � von regulären Ungleichungen der Form � � � . Beide Urteile werdeninterpretiert als: „Der Algorithmus überprüft �� und alle Ungleichungen � � � in � sind nichttrivial inkonsistent. Als Resultat wird die Menge � � mit sämtlichen Ungleichungen der partiellenAbleitungen von �� zurückgeliefert.“

Definition 4.33 (Subtyp-Urteile für reguläre Ungleichung)Gegeben sei eine Menge regulärer Ungleichungen � , dann werden die folgenden beiden Subtyp-


Urteile unterschieden:

� � � � � � � � �� ist eine gültige Ungleichung in � .� � � � � � � � � �� ist eine gültige Ungleichung in � .

Dabei seien ��

� � �und � � die resultierende Menge von regulären Ungleichungen. �

In jedem Schritt des Algorithmus entstehen neu partielle Ableitungen, deren Ungleichungen zurMenge � hinzugefügt werden. Es entsteht eine neue, erweiterte Menge � � .

Da die Nichtterminalsymbole in der Heckengrammatik rekursiv definiert sein können, kann esvorkommen, dass durch die rekursive Berechnung sämtlicher partieller Ableitungen bereits be-rechnete Ungleichungen zu einem späteren Zeitpunkt erneut auftreten. Damit für diese Fälle dieTerminierung des Algorithmus sichergestellt ist, werden sämtliche bereits berechneten Unglei-chungen in der Menge � gespeichert. Andererseits darf aber nicht sofort nach dem Hinzufügeneiner neuen Ungleichung zu � dieser rekursive Zweig erfolgreich abgebrochen werden, weil diesdazu führen würde, dass nicht sämtliche ableitbaren partiellen Ableitungen berechnet werden.Aus diesem Grund wird nach dem Hinzufügen einer Ungleichung zu � vom ersten Subtyp-Urteil� in das zweite Urteil � � umgeschaltet. Ein Zurückschalten erfolgt erst nach der Berechnungvon neuen regulären Ungleichungen. Auf diesem Weg ist die Erzeugung sämtlicher partiellerAbleitungen sichergestellt. Die Menge � ist zu Beginn des Subtyp-Algorithmus leer.

Definition 4.34 (Subtyp-Algorithmus)Der Subtyp-Algorithmus ist durch folgende Regeln definiert:

� � � � �� (HYP)

��

� � ��

� � �� (ASSUM)

� inc � � � � � �für alle � � � � �� mit

� � � part � � �� und � � term � � � gilt� � � � � � � � � � � � � � � � � � � � � � � � �

mit � � � � � � � � � � � � � � part � � � � � �� (REC)

�

In der Regel HYP wird getestet, ob die zu überprüfende Ungleichung bereits in der Menge derbereits berechneten Ungleichungen enthalten ist. Dies bedeutet, dass in diesem Rekursionszweigkeine neuen Ungleichungen erzeugt werden können. Ist dies der Fall beendet der Algorithmusan dieser Stelle die Berechnung erfolgreich. Die Regel ASSUM dient zum Umschalten zwischen


den beiden Subtyp-Urteilen � und � � . Ist die zu überprüfende Ungleichung noch nicht in derMenge � wird sie hinzugefügt und zum Urteil � � übergegangen.

Regel REC ist nur anwendbar, falls es sich nicht um eine trivial inkonsistente Ungleichung han-delt, was mit dem Prädikat inc überprüft wird. Es wird die partielle Ableitung der Ungleichungmit der Operation part berechnet, deren Ungleichungen rekursiv zu überprüfen sind. Ist eine An-wendung der Regel nicht möglich, bricht der Algorithmus für diese inkorrekte Ungleichung ab.Listing 4.1 zeigt mit der Methode prove zum besseren Verständnis den Algorithmus nochmals

1 boolean prove � ( r � s ) {2 i f ( i n c ( r � s ) )3 re turn f a l s e ;4 e l s i f ( ( r � s ) � � ) / / HYP

5 re turn true ;6 e l s e {7 boolean ok : = t rue ;8 S e t pd : =

�;

9 S e t ns : = te rm ( r ) ;10 foreach ( x � ns )11 pd : = pd p a r t x ( r � s ) ;12 � : = � { r � s } ; / / ASSUM

13 foreach ( (� � � �

� ) � ( � � � � � ) � pd ) / / REC

14 ok : = ok && ( prove � (� � � �

� ) | | p rove � ( � � � � � ) ) ;15 re turn ok ;16 } / / e l s e17 } / / p rove

Listing 4.1: Subtyp-Algorithmus in Pseudocode

in Pseudocode.

Das folgende Beispiel zeigt die Anwendung des Algorithmus.

Beispiel 4.11Betrachtet werden in diesem Beispiel erneut die beiden regulären Ausdrücke

� � description � � account �integer� � description � � und

� � � description �string � � account �integer� � � � description

aus Beispiel 4.10. Wieder wird die reguläre Ungleichung � � � betrachtet, die mit dem Sub-typ-Algorithmus auf ihre Richtigkeit hin überprüft werden soll. Zu Beginn der Berechnung ist� � � � und der Algorithmus ermittelt die führenden Terminalsymbole der rechten Seite mitdem Ergebnis term � � � � � description � . Für das Element dieser Menge wurde bereits in


Beispiel 4.10 die partielle Ableitung gebildet. Seien im Weiteren noch

� � � � account �integer � � description � � und

� � � account�integer � � �

so ergeben sich für die weitere Berechnung des Algorithmus die Teilergebnisse, die Abbil-dung 4.6 zeigt. Ersichtlich ist, dass einige Ungleichungen, die während der Berechnung auf-treten, scheitern. Andere werden als korrekt erkannt und in die Menge � aufgenommen.

Offen bleibt in der Abbildung noch die Überprüfung der Ungleichung � � � � � � � . Da die Mengeder führenden Terminalsymbole von � � nur aus account besteht, ergibt sich mit der partiellenAbleitung

partaccount � � � � � � � �� integer � integer � � � � � �� integer � � � ��

der weitere Verlauf des Algorithmus, wie er in Abbildung 4.7 dargestellt ist. Der Algorithmusakzeptiert in diesem Zweig die Ungleichung � � � � � mit der Menge aller berechneten Unglei-chungen �� . In Abbildung 4.5 ist dargestellt, wie sich die Menge � während der Ausführungverändert. Die zu Beginn leere Menge füllt sich allmählich mit neuen regulären Ungleichungen,

� � � � �� string � string

�string �

�� string � string �� integer � integer �

Abbildung 4.5: Entwicklung der Menge �

bis der Algorithmus keine neuen Ungleichungen mehr erzeugt.

Schließlich terminiert der Algorithmus mit dem Resultat, dass es sich bei � � � um eine gültigeUngleichung handelt. Denn der Algorithmus konnte für keine Disjunktion beide Ungleichungenals inkonsistent ermitteln. �

Komplexität

Die Komplexität der Subtyp-Überprüfung ist, wie in [Sei90] gezeigt, EXPTIME-vollständig undist damit im schlimmsten Fall exponentiell. Trotzdem ist der Algorithmus im Vergleich zum klas-sischen Verfahren auf der Basis von Baumautomaten (siehe Abschnitt 4.1) eine Verbesserung.

108K

APIT

EL

4.E

INT

YPSY

STE

MFÜ

RX

OB

E

REC��

��

��

��

��

��

string

�

string

�

string

� ��

��

string

�

string

�

string

� ��

�

��

��

��

HYP��

��

��

��

��

string

�

string

� ��

��

string

�

string

� ��

�

��

...��

��

HYP��

string

�

string

� ��

�

��

��

��

��

...��

string

� ��

string

� �

��

string

� � � (siehe Abbildung 4.7)

��

��

� � ��

Abbildung 4.6: Berechnung für Ungleichung � � �

HYP��

��

��

��

��

integer

�

integer

� ��

��

integer

�

integer

� ��

��

...��

��

��

...��

integer

� ��

integer

� �

��

integer

� � � HYP��

��

��

Abbildung 4.7: Berechnung für Ungleichung � � � !#"

4.7. KORREKTHEIT DES ALGORITHMUS 109

Der klassische Algorithmus, der nach dem Komplement eines Automaten die Vereinigung be-rechnet, erzeugt immer einen minimalen deterministischen Automaten mit allen Zuständen, wasexponentiell lange dauern kann. Diese Determinisierung ist aber nicht immer notwendig, wieAntimirov in [Ant94] zeigt. Es gibt Ungleichungen wie � � � mit � � � book � � record � � � book

� �book � und � � � book

�record � � � book � � book

�record � �� in denen das Verfahren dieser Arbeit po-

lynomiell arbeitet, weil nur � � � � Ungleichungen erzeugt werden, während der klassische Al-gorithmus mit � � Zuständen exponentiellen Aufwand [Per90] benötigt. Dies liegt daran, dass derSubtyp-Algorithmus dieser Arbeit die rechte Seite einer Ungleichung nur so weit determinisiert,wie es für die Überprüfung der Ungleichung notwendig ist. Auf eine vollständige Determinisie-rung kann dadurch in manchen Fällen verzichtet werden.

4.7 Korrektheit des Algorithmus

Das im letzten Abschnitt dargestellte Beispiel macht plausibel, dass der Algorithmus die Subtyp-Beziehung zweier regulärer Heckenausdrücke überprüft; damit stellt sich die Frage, ob der Al-gorithmus korrekt und vollständig arbeitet sowie in allen Fällen terminiert. In diesem Abschnittwird deshalb diese Fragestellung näher untersucht und abschließend positiv beantwortet.

4.7.1 Korrektheit

Um die Korrektheit des Algorithmus in diesem Abschnitt zu zeigen, werden zunächst einigeDefinitionen eingeführt, die im Beweis Verwendung finden. Zusätzlich wird zwischen Basisda-tentypen und Elementnamen nicht mehr unterschieden. Stattdessen werden Basisdatentypen nunwie Elementtypen mit leerem Inhalt behandelt. Es gilt also für alle � � � : � � � � � .Zunächst wird für jede Hecke eine Menge von Heckenpräfixen definiert.

Definition 4.35 (Menge aller Heckenpräfixe)Die Menge aller Heckenpräfixe Prefix einer Heckensprache � sei definiert durch:

Prefix � � � � � prefix � � � � � �� Für die Menge der Heckenpräfixe einer Hecke prefix � � � � � � � gilt:

prefix � �� prefix � � � � � � � � � � � � � � � prefix � � � �prefix � �� prefix � � � ��

Die Größe eines Heckenpräfixes sei rekursiv definiert durch:� � � � �

� � � � � � � � � � ��


mit�� und � � � �� . �

Es folgt eine Erweiterung der Heckensprache auf Tupel von regulären Ausdrücken.

Definition 4.36 (Erweiterte Heckensprache)Die Erweiterung der Heckensprache auf Tupel von regulären Ausdrücken sei definiert durch:

� � � � � � � � � � � � � � � � � �mit � � � � Reg. �

Desweiteren wird das Leere-Hecken-Prädikat auf Tupel von regulären Ausdrücken erweitert.

Definition 4.37 (Erweitertes Leere-Hecke-Prädikat)Die Erweiterung des Leere-Hecke-Prädikats isNullable? auf Tupel ist rekursiv definiert durch:

isNullable? � � � � � � � � isNullable? � � � � isNullable? � � �mit � � � � Reg. �

Die triviale Inkonsistenz, die in Definition 4.10 für reguläre Ungleichungen definiert ist, wirdnun auf Konjunktionen und Disjunktionen von regulären Ungleichungen erweitert.

Definition 4.38 (Erweiterte Inkonsistenz)Die Erweiterung der Inkonsistenz inc auf Konjunktionen von Disjunktionen sei rekursiv definiertdurch:

inc � � � �� inc � � � � �� inc � � � �inc � � � � � � � � inc � � � � � inc � � � �

Dabei seien� � � ��

� � Disjunktionen und�

� und�

� entweder Konjunktionen oder reguläre Un-gleichungen. �

Weiterhin wird die partielle Ableitung eines regulären Ausdrucks von Terminalsymbolen aufganze Heckenpräfixe erweitert.

Definition 4.39 (Erweiterte partielle Ableitung eines regulären Ausdrucks)Die Erweiterung der partiellen Ableitung eines regulären Ausdrucks hinsichtlich eines Hecken-präfixes ist rekursiv definiert durch:

der � � � � � � � � der � � � � � der � � � � mit � � � � � � der � � � �mit

�� , � � � �� und � � �

�� Reg. �

Eine analoge Erweiterung wird für die partielle Ableitung regulärer Ungleichungen vorgenom-men.


Definition 4.40 (Erweiterte partielle Ableitung einer regulären Ungleichung)Die Erweiterung der partiellen Ableitung einer regulären Ungleichung hinsichtlich eines Hecken-präfixes ist rekursiv definiert durch:

part � � � � � �� part � � � � � �part � � � � � � � � � part � � ��

mit�� , � � � �� und � � �

�� Reg. �

Damit besteht die Möglichkeit, eine Menge aller partiellen Ableitungen regulärer Ungleichungenzu definieren.

Definition 4.41 (Menge aller partiellen Ableitungen)Die Menge aller partiellen Ableitungen einer regulären Ungleichung ist dann definiert durch:

PAR � ��

part � � � � � �

mit � � � � Reg. �

Die Menge aller partiellen Ableitungen steht in einem engen Zusammenhang zum Subtyp-Algo-rithmus dieser Arbeit (Definition 4.34), denn dieses Verfahren berechnet genau diese Menge. Esberuht auf der Beobachtung, dass, falls �� eine gültige Ungleichung ist, alle partiellen Ablei-tungen PAR � � � � � nicht trivial inkonsistent, also gültig, sind. Ist dagegen � � � nicht gültig, soenthält die Menge PAR � �� mindestens eine Konjunktion, die trivial inkonsistent ist.

Schließlich wird die Konkatenation von Hecken noch erweitert auf die Konkatenation einesHeckenpräfixes mit einem Tupel von Hecken.

Definition 4.42 (Erweiterte Konkatenation)Die Erweiterung der Konkatenation von Hecken auf die Konkatenation eines Heckenpräfixes miteinem Tupel von Hecken sei definiert durch:

� � � � � � � � � � � � � � � � � � � � �

� � � � � ��

mit�� und � � � � � � � �� . �

Nach der Angabe der für die Korrektheitsbeweise nötigen Definitionen, kann ein erster Hilfssatzformuliert werden, der ebenfalls notwendig wird. Dieser besagt, dass die Hecken der Sprache ei-nes durch partielle Ableitung hinsichtlich eines Terminalsymbols reduzierten regulären Hecken-ausdrucks identisch sind mit den Hecken der Sprache des ursprünglichen regulären Ausdrucks,die um das führende Terminalsymbol verkürzt wurden.

Hilfssatz 4.1Sei � � � � eine reguläre Sprache mit � � Reg dann gilt:

� � � � � � � � � � � � �� und�� term � � � � � �

� � � der � � � ��


Beweis:Vollständige Induktion über Länge des regulären Ausdrucks � :

� Induktionsanfang:

– Angenommen es gilt � � � , dann folgt:

� � � � � � � � � � � � �� term � � � � � � � �

� � � der � ��

– Angenommen es gilt � � � , dann folgt:

� � � � � � � � � � � � �� term � ��

� � � der � � � ��

– Angenommen es gilt � � �, dann folgt:

� � � � � � � � � � � � �� term � � � � � � � �

� � � � � � � � � � � � � � � � � � ��

� � � der � � � ��

� Induktionsschluss:

– Angenommen es gilt � � � � , dann folgt:

� � � � � � � � � � � � �� term ��

� � � � � � � � � � � � � �� term ��

� � � � � � � � � � � � � � �� term ��

I. V.� �� der � � � �

� � � � � � � � � ��

� �� der � � � � � � �

� � � � � � � � � � � � ��

� �� der � � � � �

� � � � � � � � � � � � ��


– Angenommen es gilt � � � � � � � , dann folgt:

� � � � � � � � � � � � �� term ��

� � � � � � � � � � � � � �� term ��

� term ��

� term ��

� term �� I. V.� �

� � � der � � � � ��

� � � der � � � � ��

� �� der � � � � �� der � � � � �

� � � � � � � � � � � � ��

� �� der � � � � � � �

� � � � � � � � � � � � ��

– Angenommen es gilt � � � � � � � und � isNullable? �� , dann folgt:

� � � � � � � � � � � � �� term ��

� � � � � � � � � � � � � � �� term ��

I. V.� �� der � � � � �

� � � � � � � � � � � � � ��

� � � der � � � � � � � ��

� �� der � � � � � � � �

� � � � � � � � � � � � ��

– Angenommen es gilt � � � � � � � und isNullable? �� , dann folgt:

� � � � � � � � � � � � �� term ��

� � � � � � � � � � � � � � �� term ��

� term ��

� term ��

� term �� I. V.� �

� � � der � � � � ��

�� der � � � � �

� � � � � � � � � � � � ��

� �� der � � � � � � � � � der � � � � �

� � � � � � � � � � � � ��

� �� der � � � � � � � �

� � � � � � � � � � � � ��

�


Eine Erweiterung des letzten Hilfssatzes auf ganze Heckenpräfixe, lässt sich ebenfalls angeben.

Hilfssatz 4.2Sei � � � � eine reguläre Sprache mit � � Reg dann gilt:

� � � � � � � � �� und � � Prefix � � � � � � � � �� der ��

� � � � � � ��

Beweis:Vollständige Induktion über die Größe des Präfixes � :

� Induktionsanfang: Angenommen es gilt� � � � � , dann folgt:

� � � � � � � � �� Prefix � � � � � � �� und

�� term � � � �

Hilfss. 4.1� �� der � � � �

� � � � � � � � � � � � ��

� �� der ��

� � � � � � ��

� Induktionsschluss: Angenommen es gilt� � �� , dann folgt:

� � � � � � � � �� Prefix � � � � � � ��

� � � � � � � �� und

�� term � � � �

Hilfss. 4.1� �� der � � � �

� � � � � ��

� � � ��

I. V. u. I. V. u. Def. der� �� der ��

� � � � � ��

� �� der ��

� � � � � � ��

�

Um den Hilfssatz zu beweisen, wird eine vollständige Induktion über die Größe der Heckenprä-fixe angewendet und auf Hilfssatz 4.1 zurückgegriffen.

Nach diesem Hilfssatz folgt ein weiterer Hilfssatz, der auf dem vorherigen basiert. Dieser besagt,dass es zu jeder Hecke einer Sprache, die durch einen regulären Ausdruck beschrieben wird,mindestens eine partielle Ableitung des regulären Ausdrucks hinsichtlich dieser Hecke gibt, diedie leere Hecke repräsentiert.


Hilfssatz 4.3Sei � � � � eine reguläre Sprache mit � � Reg, dann gilt:

� �� der � � � � mit isNullable? � � �Indirekter Beweis:Angenommen es gilt � � � der � � � � mit isNullable? � � � , dann folgt:

Def. � � �� der ��

� � � � � � ��

Hilfss. 4.2 � �� und � � Prefix � � � � � � �

�

Der Beweis wird indirekt geführt und wendet Hilfssatz 4.2 an.

Die Korrektheit des Subtyp-Algorithmus liegt dann vor, falls für jedes positive Resultat des Al-gorithmus die Eingabe eine gültige Ungleichung ist. Mit Satz 4.3 lässt sich diese Bedingungformulieren.

Satz 4.3 (Korrektheit)Liefert der Subtyp-Algorithmus � � � � � , dann ist � � � eine gültige Ungleichung, also:

� � � PAR � �� mit inc � � � � � � �

Indirekter Beweis:Angenommen es gilt �� , dann folgt:

Def. �� mit � ��

Hilfss. 4.3� � � � der � � � � mit isNullable? � � � und � � � der � � � � mit isNullable? � � �Def. der� � � � PAR � �� mit inc � � �

�

Die Korrektheit des Subtyp-Algorithmus wird indirekt bewiesen, wobei zur Unterstützung Hilfs-satz 4.3 herangezogen wird.

4.7.2 Vollständigkeit

Damit der Subtyp-Algorithmus als vollständig gilt, muss dieser für jede reguläre Ungleichungein positives Ergebnis ermitteln. Formal wird diese Eigenschaft durch Satz 4.4 beschrieben.


Satz 4.4 (Vollständigkeit)Gilt die Ungleichung �� , dann liefert der Subtyp-Algorithmus � � � � � , also:

� � � � � � � PAR � � � � � mit inc � � �Indirekter Beweis:Angenommen es gilt � � � PAR � �� mit inc � � � , dann gilt:

Def. PAR� � � � Prefix � � � � � � mit�� part � � �� mit inc � � �

Def. der und Hilfss. 4.3� � ��

Def. ��

Der Beweis der Vollständigkeit des Subtyp-Algorithmus wird erneut indirekt geführt und beruhtebenfalls im Kern auf Hilfssatz 4.3.

4.7.3 Terminierung

Die Terminierung des Subtyp-Algorithmus wird in diesem Abschnitt untersucht. Dafür wird dieNerode-Kongruenz � herangezogen, da für reguläre Baumsprachen nur endlich viele Klassenexistieren [RS97].

Definition 4.43 (Nerode-Kongruenz)Zwei Heckenpräfixe � � � � Prefix � � � � � � sind kongruent, falls gilt:

�� der ��

� � � � � gilt � � � �� und � � � ��

Zwei Heckenpräfixe � und � sind genau dann kongruent, falls sowohl die Konkatenation von� mit einer Fortsetzung � als auch die Konkatenation von � mit � in der betrachteten Spracheenthalten sind.

Damit der Subtyp-Algorithmus terminiert, muss sichergestellt sein, dass es endlich viele parti-elle Ableitungen für eine reguläre Ungleichung gibt. Da die partielle Ableitung einer regulärenUngleichung mittels der partiellen Ableitungen der regulären Ausdrücke definiert ist, genügt eszu zeigen, dass nur endlich viele

� � � � � � � mit � � Prefix � � � � � � existieren. Die Menge� � � � � � �

selbst muss endlich sein, weil � fest und � endlich ist. Mit dem folgenden Satz wird gezeigt, dassdie Anzahl der Mengen

� � � � � � � für � � Prefix � � � � � � endlich ist.

Satz 4.5Sei � � � � eine reguläre Sprache mit � � Reg und � � � � Prefix � � � � � � , dann gilt:

� � � � � � � � � � ��

4.8. ERWEITERUNGEN UND VEREINFACHUNGEN 117

Beweis:

" � " Hinrichtung: Indirekter Beweis

Angenommen es gilt �� , dann folgt:Def. � � � � �

� � � der �� mit � � � �� und � � � �

�� Hilfss. 4.2� � � �

� �� der �� und � �

� �� der � � � �

� � � �� Def. �� der � � � � �� der � � � �

" � " Rückrichtung: Direkter Beweis

Angenommen es gilt der � � � � � der � � � � , dann folgt:Def. � � � � der � � � �� der � � � �

Hilfss. 4.2� � � � �� der ��

� � � � � gilt � � � �� und � � � �� Def. � ��

�

Der Beweis, der in die eine Richtung indirekt und in die andere direkt erfolgt, macht sich erneutden Hilfssatz 4.2 zu Nutze.

Abschließend kann anhand der Nachweise für die Korrektheit, Vollständigkeit und Terminierungdes Subtyp-Algorithmus festgestellt werden, dass der Algorithmus wie erwartet arbeitet.

4.8 Erweiterungen und Vereinfachungen

Dieser Abschnitt beschreibt zunächst die Erweiterung des Subtyp-Algorithmus auf die weiter-führenden Konzepte von XML-Schema. Im Anschluss folgt eine Diskussion zu möglichen Ver-einfachungen des Algorithmus für die bestehenden Definitionen von DTD und XML-Schemaunter Berücksichtigung der Auswirkungen auf das Laufzeitverhalten.

4.8.1 Substitutionsgruppen, Typerweiterung und Typeinschränkung

Wie im Abschnitt 2.1 angesprochen wurde, erweitert XML-Schema die Ausdruckskraft von DTDunter anderem durch die Mechanismen Substitutionsgruppen, Typerweiterung und Typeinschrän-kung. Dadurch wird das Typsystem in XML durch die sogenannte Bezeichnertypisierung („na-med typing“) ergänzt. In der Bezeichnertypisierung gibt es die Möglichkeiten Bezeichner mit

Typdefinitionen zu verknüpfen und zwischen diesen Bezeichnern Beziehungen, wie zum Bei-spiel eine Vererbungshierarchie, zu deklarieren. In XML-Schema ist dies mit den komplexenTypen durch Substitutionsgruppen, Typerweiterung und Typeinschränkung möglich. Neben derBezeichnertypisierung existiert in XML die Strukturtypisierung („structural typing“). In dieserwird anhand der Struktur von XML-Fragmenten und Inhaltsmodellen eine Beziehung hergestellt.

In Substitutionsgruppen werden Elementnamen gleicher Elementtypen zu einer Menge zusam-mengefasst. Für ein Dokument ist dann zulässig, dass die Instanz eines Elementtyps aus der Sub-stitutionsgruppe an einer Position im Dokument auftritt, an dem ein anderer Elementtyp aus derSubstitutionsgruppe erwartet wird. Zur Formalisierung von Substitutionsgruppen wird im Typ-system von XOBE die reflexive und transitive Substitutionsgruppenrelation SubGr eingeführt.Für das zweite Konzept in XML-Schema, der Erweiterung und Einschränkung komplexer Ty-pen, gilt ähnliches. Durch diese dürfen Instanzen der erweiterten oder eingeschränkten Typen anStellen im Dokument eingesetzt werden, an denen die nicht erweiterten oder uneingeschränktenTypen erwartet werden. Für die formale Behandlung im Subtyp-Algorithmus von XOBE wirdzusätzlich die Bezeichnertyprelation Inh definiert.

Im Folgenden wird die Abkürzung BZT für die modifizierten Definitionen verwendet, die durchdie Konzepte der Bezeichnertypisierung entstehen. Es ergeben sich für die Formalisierung einesXML-Schemas folgende zusätzliche Regeln.

Definition 4.44 (Produktionsrelation (BZT))Die Produktionsrelation (BZT) ergänzt die Produktionsrelation �� aus Definition 4.16 um fol-gende Regeln:

� � ��

� � � � �<element

��/>

� name � � � type � � �� substitutionGroup � �

�� und � � � � � SubGr �(SUB1)

� � ��

� � � � �<element

��>� � </element>

� name � � � substitutionGroup � �� und � � � � � SubGr �

(SUB2)

� � � � � � � � ��

��

<complexType��><complexContent>

<extension base=" � ">� � � �

</extension></complexContent></complexType>� name � � � mixed � �

��

� �� mixed � ��

mit � � ��

und �� Inh �

(EXT)

� � � � � � � � ��

��

<complexType��><complexContent>

<restriction base=" � ">� � � �

</restriction></complexContent></complexType>� name � � � mixed � �

��

� �� mixed � ��

mit � � ��

und �� Inh �

(REST)mit � �� ,

�� ,

�� und �

��

��

�� Reg. �

Die Regel SUB1 und SUB2 erzeugen für Elementdeklarationen, die Substitutionsgruppen zu-geordnet sind, Produktionen und erweitern die Substitutionsgruppenrelation SubGr. Mit den Re-geln EXT und REST werden die Produktionen für Definitionen komplexer Typen mit Erweiterungbeziehungsweise Einschränkung erstellt. Die notwendige Ausdehnung der Bezeichnersubtypre-lation Inh wird ebenfalls vorgenommen.

Nachdem die erweiterte Sprachbeschreibung ergänzend zur Heckengrammatik mit eine Bezeich-nersubtyprelation formalisiert wird, muss eine Regel für die Typinferenz eines XML-Konstruk-tors ergänzt werden.

Definition 4.45 (Typinferenz eines XML-Konstruktors (BZT))Die Typinferenz eines XML-Konstruktors (BZT) ergänzt Definition 4.18 um folgende Regel:

� � ��

� ��

� ��

� � < � � � >� � </ �

>� type � � � �

(ELEM INH)

mit � �� ,�� , ��

�� und der Ausdrucksrelation � � . �

Die Regel ELEM INH bezieht sich auf Elemente, die durch das Attribut type ihren aktuellenTyp annotieren. Für diese Elemente wird der angegebene Typ � als Typ des Konstruktors zu-rückgegeben und gleichzeitig mit dem Subtyp-Algorithmus verifiziert, ob der inferierte Typ desElements

� � �� zum annotierten Typ passt.

Weiterhin ist die Anpassung des Algorithmus zur Berechnung der Subtyp-Beziehung notwen-dig. Die Idee bei der Integration der Bezeichnersubtyprelation in den Algorithmus ist, dass dieregulären Ungleichungen nicht nur mittels führender Terminalsymbole, sondern, falls möglich,auch durch führende Nichtterminalsymbole reduziert werden. Bei diesem Vorgehen ist die Be-rücksichtigung der Vorgaben durch die Bezeichnersubtyprelation möglich.

Notwendig ist die Neudefinition der im Abschnitt 4.2 eingeführten Funktion term. Anstatt bei


einem Nichtterminalsymbol die Produktionsdefinition zu analysieren, beendet die neue Variantediesen Rekursionszweig.

Definition 4.46 (Führende Terminalsymbole (BZT))Die führenden Terminalsymbole (BZT) eines regulären Ausdrucks � � Reg liefert die modifizierteFunktion term � Reg � � � � aus Definition 4.11. Die Änderung ist definiert für Nichtterminal-symbole:

term �� mit � �� . �

Zusätzlich wird eine Funktion � � � definiert, die analog zur Funktion term die Menge der Nicht-terminalsymbole aus einem regulären Ausdruck ermittelt.

Definition 4.47 (Führende Nichtterminalsymbole)Die führenden Nichtterminalsymbole eines regulären Ausdrucks � � Reg liefert die Funktionnon � Reg � � � � � und sei analog zur Funktion term aus Definition 4.11 mit folgenden Ände-rungen für Nichtterminalsymbole und Basisdatentypen definiert:

non � � � � � �non ��

mit � � � und � �� . �

Die in Abschnitt 4.6 eingeführte Funktion der muss ebenfalls abgewandelt werden. Die Funktionliegt nun in zwei Varianten vor, wobei die eine für Terminalzeichen und die andere für Nicht-terminalsymbole definiert ist. Die Funktion der für Terminalsymbole berücksichtigt dabei dieAngaben der Substitutionsgruppenrelation SubGr.

Definition 4.48 (Partielle Ableitung hinsichtlich eines Terminalsymbols (BZT))Die partielle Ableitung hinsichtlich des Terminalsymbols � �� wird berechnet durch die Funk-tion der � � Reg � � �Reg � Reg � . Sie ist definiert wie die Funktion der aus Definition 4.31 mitfolgender Änderung für Elementtypen:

der � � � � � � � �� falls

� � � � SubGr und � �� ,

� � sonst

mit�� und � � Reg. �

Bei der Festlegung der Funktion der für Nichtterminalsymbole wird entsprechend die Bezeich-nersubtyprelation einbezogen. Zusätzlich kann ein Basisdatentyp oder ein Elementname nichtum ein Nichtterminalsymbol reduziert werden, weshalb in diesen Fällen eine leere Menge dasErgebnis bildet.

Definition 4.49 (Partielle Ableitung hinsichtlich eines Nichtterminalsymbols)Die partielle Ableitung hinsichtlich des Nichtterminalsymbols � � � wird berechnet durch dieFunktion der � � Reg � � �Reg � Reg � . Sie ist definiert wie die Funktion der aus Definition 4.31


mit folgender Änderung für Basisdatentypen, Nichtterminalsymbole und Elementnamen:

der � � � � � �

der � �� falls � � � oder � � � � Inh,

der � � � � mit � � � �� sonst

der � � � � � � � � �

für alle � � � , � �� ,�� und � � Reg. �

Da eine Reduktion einer regulären Ungleichung mit einem Nichtterminalsymbol nicht immererfolgreich sein muss, ist es sinnvoll in diesen Fällen ein führendes Nichtterminalsymbol durchdessen Produktionsdefinition zu ersetzen, um anschließend die Reduktion erneut zu versuchen.Dazu wird eine Funktion sub spezifiziert.

Definition 4.50 (Substitution führender Nichtterminalsymbole)Die Substitution eines führenden Nichtterminalsymbols � � � durch die Produktionsdefinitionvon � wird berechnet durch die Funktion sub � � Reg � Reg und ist rekursiv definiert durch:

sub � � � � � �

sub � � �� sub � � � � � �sub � ��

� � mit � � � �� falls � � �� sonst

sub � � � � � � � � � � � �sub � � � � � � � sub � � � � � sub � � � �sub � � � � � � �

�sub � � � � � � falls � isNullable? � � �sub � � � � � sub � � � � falls isNullable? � � �

sub � � � � � � sub � � � � �

mit � � � , � �� ,�� und �

� � � Reg. �

Mit diesen Angaben ist es nun möglich, den Subtyp-Algorithmus aus Abschnitt 4.6 entsprechendumzuschreiben.


Definition 4.51 (Subtyp-Algorithmus (BZT))Der Subtyp-Algorithmus (BZT) ersetzt die Regel REC aus Definition 4.34 durch folgende Regel:

� inc � � � � � �für alle � � � � �� mit

� � � part � � �� und � � term � � � gilt� � � � � � � � � � � � � � � � � � � � � � � � �

mit � � � � � � � � � � � � � � part � � �� für alle � � � � � �� mit

� � � part � � �� und � � non � � � gilt��

mit � � � � � � � � � � � � � � part � � � � � � �� sub � � � � � � � �� mit � � � ��

� � � � �� (REC)

�

Wie Regel REC zeigt, extrahiert der Algorithmus für eine reguläre Ungleichung zunächst dieführenden Terminalzeichen, als auch die führenden Nichtterminalsymbole. Für die führendenTerminalzeichen wird die Ungleichung, wie in Definition 4.34, reduziert. Analoges erfolgt fürdie Nichtterminalzeichen, wobei für den Fall, dass diese Reduktion zu keinem Ergebnis führt,versucht wird, durch die Substitution des führenden Nichtterminalsymbols zum Erfolg zu gelan-gen.

4.8.2 Vereinfachungen

Sowohl in der Spezifikation von XML [W3C98c], als auch in der Spezifikation von XML-Sche-ma [W3C01c] werden für die Definition von XML-Typen Einschränkungen festgelegt. Dies führtdazu, dass die Heckengrammatiken, die durch die Formalisierung von DTDs und XML-Sche-mata entstehen, bestimmte Eigenschaften aufweisen, die zu wesentlichen Vereinfachungen desSubtyp-Algorithmus führen. Verbunden damit ist eine Verbesserung des Laufzeitverhalten umGrößenordnungen.

Elementtypen in Inhaltsmodellen

In XML-Schema gilt für die Deklaration von Elementtypen, dass Typen mit dem selben Element-namen innerhalb eines Inhaltsmodells gleich zu sein haben. Damit müssen sowohl die Inhalts-modelle, als auch die Attribute der Elementtypen identisch sein. In DTDs gilt diese Bedingungohnehin, da für jeden Elementnamen nur ein Elementtyp definiert werden kann. Das folgendeBeispiel zeigt eine Produktion, die die genannte Anforderung verletzt:

Beispiel 4.12Sei in dem XML-Schema der AOML (Anhang A) die Definition des komplexen Typs t_bookwie folgt ersetzt:

<complexType name=" t_book "><sequence >

< e l e m e n t name=" t i t l e " t y p e =" i n t e g e r " / >< e l e m e n t name=" t i t l e " t y p e =" s t r i n g " / >

</ sequence ></ complexType >

Die Instanzen des komplexen Typs t_book müssen nun nach dieser Definition aus zwei Ele-menten bestehen, die beide den Elementnamen title tragen, aber unterschiedlichen Inhalt be-sitzen. Der Inhalt des ersten Elements ist von Typ integer, während das zweite Element eineZeichenkette beinhaltet. Damit sind die Typen dieser beiden Elemente verschieden, was der ge-schilderten Bedingung widerspricht. �

Für die durch die Sprachbeschreibung induzierte Heckengrammatik kann die Bedingung formalformuliert werden.

Definition 4.52Für alle Produktionen � � � � � einer Heckengrammatik mit Inhaltsmodellen, die für gleicheElementnamen nur identische Elementtypen zulassen, gilt:

�

� � �

� für � � � � � � � � der � � � � und � � � � � � � � der � � � �mit � �� , � �� und �

��

� ��

� � � � � � � � Reg. �

Die Definition zeigt für die partiellen Ableitungen eines regulären Ausdrucks, dass ausschließlichTupel entstehen, die sich in den ersten Komponenten (

�

� und�

� ) nicht unterscheiden. Damit sindreguläre Ungleichungen wie beispielsweise

book�title � price �� book

�title � �

�book

�title � � � book � title � price � � book � title � price ��

nicht mehr zugelassen. Durch diese Eigenschaft lässt sich die Definition der partiellen Ableitun-gen erheblich einfacher angeben.

Definition 4.53 (Partielle Ableitung regulärer Ungleichungen (Simp1))Die partielle Ableitung einer regulären Ungleichung � � � mit � � � � Reg hinsichtlich einesTerminalsymbols � �� ist definiert durch:

part � � ��

� ��

� � � � � �� der � � � � � der � � � � � � � � � � � �� mit

� � ��

� � � � � � � � Reg. �

Für die partielle Ableitung einer regulären Ungleichung entstehen durch die Einschränkung nurnoch zwei Disjunktionen, von denen eine Ungleichung ( � � � ) stets trivial inkonsistent ist. Die

beiden anderen Ungleichungen beziehen sich auf das Inhaltsmodell des reduzierten Terminalzei-

chens (� � � � � ) und auf die nachfolgenden Elementtypen ( � � � ��

��

� �� ).Im schlechtesten Fall ist der Algorithmus aus Abschnitt 4.6 exponentiell, wofür es zwei Ursachengibt. Die Anzahl der regulären Ungleichungen kann sich zum einen durch die Tupelmenge derpartiellen Ableitungen der regulären Ausdrücke exponentiell vergrößern und zum zweiten durchdie Anwendung von Satz 4.2 erweitern. Durch die Einschränkung einer Sprachbeschreibung aufInhaltsmodelle, für die nur gleiche Elementtypen mit gleichem Elementnamen zulässig sind,ergibt sich bezüglich des Aufwands eine Verbesserung. Die Anwendung von Satz 4.2 ist nunnicht mehr erforderlich.6 Trotzdem bleibt der Aufwand exponentiell und entspricht nun genaudem Aufwand von Antimitovs Algorithmus, der PSPACE-vollständig ist [Ant94].

Einseindeutigkeit

Die Einseindeutigkeit („one-unambiguous“) [BKW98] ist eine weitere Einschränkung an dieInhaltsmodelle, die sowohl für eine DTD („deterministic content models“) (Referenz E in derSpezifikation [W3C98c]) als auch für ein XML-Schema („unique particle attribution“) (§3.8.6 in[W3C01c]) gefordert wird. Es wird von einem einseindeutigen Inhaltsmodell gesprochen, fallses möglich ist unter Berücksichtigung der Konkatenations-, Vereinigungs- und Kleene-Stern-Operatoren einen Pfad durch das Inhaltsmodell so zu bestimmen, dass jedes Element im Inhalteines Dokuments mit einem Elementtyp im Inhaltsmodell korrespondiert. Kann ein Element imInhalt mit mehr als einem Elementtypen im Inhaltsmodell korrespondieren, ist die Eigenschaftverletzt. Das folgende Beispiel zeigt ein nicht einseindeutiges Inhaltsmodell.

Beispiel 4.13Dieses Beispiel bezieht sich auf die DTD der AOML (Beispiel 2.2) und zeigt ein nicht einsein-deutiges Inhaltsmodell.

<!ELEMENT book ( ( t i t l e , a u t h o r ) | ( t i t l e , e d i t o r ) ) >

Bei der Verarbeitung des Inhalts eines book-Elements wäre für das erste title-Element unklarmit welchem Elementtyp title im Inhaltsmodell dieses korrespondiert. Nur mit einer Voraus-schau auf das dem title-Element folgende Element wäre eine eindeutige Zuordnung möglich.

�

Bei vielen nicht einseindeutigen Inhaltsmodellen ist eine Umformung in einen äquivalenten ein-seindeutigen Ausdruck möglich. Aber nicht immer kann ein solcher Ausdruck gefunden wer-den, was in [BKW98] festgestellt wurde. Beispielsweise ist für das Inhaltsmodell ((title|author)*;title;(title|author)), das die Einseindeutigkeit verletzt, keine äquiva-lente Umwandlung in einen einseindeutigen Ausdruck möglich.

6Eine weitere Verbesserung des Algorithmus ist in diesem Fall dadurch möglich, dass der &-Operator für Attri-bute oder Inhaltsmodelle nicht durch sämtliche Permutationen sondern eigenständig repräsentiert wird.


Die Formalisierung dieser Eigenschaft für Heckengrammatiken ist mit Hilfe der partiellen Ab-leitungen möglich.

Definition 4.54Für alle Produktionen � � � � � einer Heckengrammatik mit einseindeutigen Inhaltsmodellengilt: �

der � � � � � � �mit � �� , � �� und � � Reg. �

Die Charakterisierung für einseindeutige Inhaltsmodelle führt zu einelementigen partiellen Ab-leitungen der regulären Ausdrücke. Damit kann für die partiellen Ableitungen der regulären Un-gleichungen eine weiter vereinfachte Definition angegeben werden.

Definition 4.55 (Partielle Ableitung regulärer Ungleichungen (Simp2))Die partielle Ableitung einer regulären Ungleichung � � � mit � � � � Reg hinsichtlich einesTerminalsymbols � �� ist definiert durch:

part � � �� der � � � � � � � � � � � �� der � � � � � � � � � � � � � � �

mit� � ��

� � � � � � � � Reg. �

Die partielle Ableitung einer regulären Ungleichung vereinfacht sich in der Form, dass nun inder Ungleichung für nachfolgende Elementtypen ( � � � � � ) des reduzierten Terminalzeichenskeine reguläre Vereinigung über sämtliche Tupel aus der � � � � gebildet werden muss. Die Mengeder � � � � enthält nämlich nur ein Element.

Mit der Beschränkung der Inhaltsmodelle einer Sprachbeschreibung auf einseindeutige Inhalts-modelle verbessert sich der Aufwand des Subtyp-Algorithmus wesentlich. Da die partiellen Ab-leitungen der regulären Ausdrücke nun nur noch aus einem Tupel bestehen, entstehen in jedemReduktionsschritt exakt zwei neue Ungleichungen. Der Aufwand wird damit linear zur Anzahlder Terminalsymbole in beiden regulären Ausdrücken. Dies ist eine Verbesserung um Größen-ordnungen.

Es hat sich gezeigt, dass die Einschränkungen der Inhaltsmodelle zu wesentlichen Effizienzstei-gerungen des Subtyp-Algorithmus führen. Da sowohl von DTDs als auch von XML-Schema diegenannten Beschränkungen gefordert werden, können XOBE-Programme mit diesen Sprachbe-schreibungen davon profitieren. Es wäre aber auch denkbar, die Forderung der Einseindeutigkeitfür Inhaltsmodelle aufzugeben. Damit wäre der Aufwand des Subtyp-Algorithmus zwar nichtmehr linear, was aber für die relativ kleinen Inhaltsmodelle realistischer Sprachbeschreibungen,die auch angewendet werden, vertretbar wäre.

Kapitel 5

Übersetzung von XOBE-Programmen

Um aus einem Programm ein ausführbares Programm zu erhalten, ist eine Programmübersetzungnotwendig. Ein XOBE-Programm ist ein Java-Programm, das, wie in Kapitel 3 eingeführt, imWesentlichen um XML-Objekte und XPath-Ausdrücke zur Selektion von Daten aus XML-Ob-jekten ergänzt wurde. Bedingt durch diese Erweiterungen ist eine Verarbeitung mit einem Java-Übersetzer weder syntaktisch möglich, noch kann damit die Typkorrektheit, wie sie in Kapitel 4vorgestellt wurde, überprüft werden.

Es ist eine eigene Übersetzung der XOBE-Programme notwendig, für die im Rahmen dieser Ar-beit eine prototypische Implementierung vorgenommen wurde. Diese besteht aus einem Präpro-zessor, der das XOBE-Programm in ein reines Java-Programm übersetzt, nachdem die Typkor-rektheit festgestellt wurde. Das erzeugte reine Java-Programm verwendet zur internen Repräsen-tation der XML-Objekte das in Abschnitt 2.3 präsentierte DOM.

Im Folgenden wird zunächst die Architektur des Übersetzungsprozesses dargestellt, der aus ei-nem XOBE-Programm ein reines Java-Programm erzeugt. Der nachfolgende Abschnitt defi-niert die Transformation der XML-Objekte im Einzelnen. Daraufhin wird in einem Abschnittdie Transformation der XPath-Ausdrücke mit zusätzlichen Algorithmen, die für die Umsetzungnotwendig sind, vorgestellt. Abschließend werden Erfahrungen und Leistungsdaten diskutiert,sowie auf Erweiterungsmöglichkeiten der Implementierung eingegangen.

5.1 Architektur des Präprozessors

Für die Übersetzung der XOBE-Programme wurde eine Implementierung als Präprozessor ge-wählt. Diese Umsetzung geschieht nicht aus zwingender Notwendigkeit, sondern stellt eine De-signentscheidung dar. Denkbar wäre ebenfalls eine Integration der XOBE-Spracherweiterung ineinen Standard-Java-Übersetzer, eine Möglichkeit die im letzten Abschnitt dieses Kapitels kurzdiskutiert wird. In diesem Abschnitt wird die Architektur des Prototyps vorgestellt, die in Abbil-

128 KAPITEL 5. ÜBERSETZUNG VON XOBE-PROGRAMMEN

dung 5.1 schematisch dargestellt ist. Wie zu sehen ist, gliedert sich der XOBE-Präprozessor in

Java compiler

Java transformation

Type checking

Schema parserProgram parser

Java with DOM

XOBE preprocessor

XOBE program XML schema

Abbildung 5.1: Architektur des XOBE-Präprozessors

drei aufeinander folgende Phasen:

1. Der lexikalischen und syntaktischen Analyse,

2. der Typanalyse und

3. der Transformation in reinen Java-Quelltext.

In der lexikalischen und syntaktischen Analyse wird das XOBE-Programm eingelesen und ineine interne Repräsentation überführt. Ein XOBE-Programm besteht neben den Standard-Java-Sprachkonstrukten aus der leicht modifizierten XML-Syntax der XML-Konstruktoren, aus derXPath-Syntax und aus der XML-Schema- bzw. DTD-Syntax der importierten Sprachbeschrei-bungen. Die XML-Syntax ist leicht verändert, weil die XML-Konstruktoren Variablen enthal-ten können, was in der standardisierten XML-Syntax nicht vorgesehen ist. Es kommen damitin der ersten Phase fünf unterschiedliche Syntaxregeln zum Einsatz. Die Standard-Java-, dieXML- und die XPath-Regeln werden zu einem XOBE-Programmparser zusammengefasst. DieRegeln aus XML-Schema und der DTD-Syntax finden Eingang in den XOBE-Schemaparser. Inder vorliegenden prototypischen Implementierung wird mit Hilfe des Compiler-Compilers Ja-vaCC [Web02] der XOBE-Programmparser generiert. Für den XOBE-Schemaparser wird einer-seits der XML-Parser Xerces [Apa01] eingesetzt, um die XML-Schema-Syntax zu analysieren,andererseits wird der DTD-Parser von Wuttka [Wut] verwendet, der die Sprachbeschreibungenin DTD-Syntax einliest. Die Festlegung der internen Repräsentation für eingelesene XOBE-Pro-gramme geschieht mit Unterstützung des Java-Tree-Builders (JTB) [TWP00], der aus Syntaxre-geln eine abstrakte Syntax generiert.

5.1. ARCHITEKTUR DES PRÄPROZESSORS 129

In der Phase der Typanalyse überprüft der Präprozessor, ob es sich bei dem eingelesenen Quell-text um ein wohlgetyptes Programm handelt. Ein XOBE-Programm ist wohlgetypt, falls alleXML-Objekte und XPath-Ausdrücke gültig bezüglich der deklarierten Sprachbeschreibung sind.Vorab aber muss die Typanalyse untersuchen, ob die importierten Sprachbeschreibungen selbstkorrekt sind. Danach erfolgt die Typüberprüfung der Java-Anweisungen, die XML-Objekte oderXPath-Ausdrücke enthalten, wie beispielsweise Zuweisungen und Methodenaufrufe, gemäß derBeschreibung von Kapitel 4. Wie dort beschrieben ist, findet zunächst eine Typinferenz für XML-Konstruktoren, XML-Objekt-Variablen und XPath-Ausdrücke statt. Anschließend werden mitdem Subtyp-Algorithmus die durch XOBE erweiterten Anweisungen verifiziert. Das Typsystemeiner Auszeichnungssprache, die eine DTD beschreibt, ist sehr strikt und lässt sich vollständigdurch reguläre Heckengrammatiken, wie sie in Abschnitt 4.2 beschrieben wurden, formalisieren.Damit kann der Subtyp-Algorithmus aus Abschnitt 4.6 zur Typüberprüfung verwenden werden.In XML-Schema wird dieses strikte Typsystem durch Typerweiterungen und Typeinschränkun-gen (siehe Abschnitt 2.1.2) aufgeweicht. Trotzdem können mit Hilfe der Erweiterung des Suptyp-Algorithmus aus Abschnitt 4.8 auch diese Anweisungen überprüft werden.

In der letzten Phase des Präprozessors wird die Transformation des XOBE-Programms in reinenJava-Quelltext durchgeführt. Für die Implementierung der XOBE-Konstrukte in reinem Java-Quelltext sind mehrere verschiedene Alternativen denkbar, die mit unterschiedlichen XML-Ob-jekt-Repräsentationen arbeiten. Die vorliegende Realisation [Kra02] verwendet die Standardre-präsentation des DOM, das in Abschnitt 2.3 vorgestellt wurde. Auf weitere Implementierungs-möglichkeiten geht die Diskussion im letzten Abschnitt dieses Kapitels kurz ein. Die Trans-formation ersetzt die XML-Konstruktoren und XPath-Ausdrücke des XOBE-Programms durchpassende DOM-Anweisungen. Sie erfolgt auf der internen Repräsentation des Quelltextes. Eswerden die Teilbäume, die die XOBE-Konstrukte repräsentieren, durch solche neu erzeugtenTeilbäume ersetzt, die für den passenden DOM-Quelltext stehen. Das Transformationsresultat,der reine Java-Quelltext, kann nach der Ausgabe mit einem Standard-Java-Übersetzer verarbei-tet werden, womit im Anschluss an die Transformation des Präprozessors die Umwandlung in einlauffähiges Programm erfolgen kann. Obwohl das DOM als ungetypte XML-Implementierung diestatische Gültigkeit der Elemente selbst nicht sicherstellt, sind die transformierten XML-Objektedes XOBE-Programms gültig. Dies gilt, weil die Typanalyse des Präprozessors diese Eigenschaftfür den resultierenden Java-Quelltext garantiert.

Die Notation, die in den folgenden Abschnitten verwendet wird, dient zur einfachen Darstellungvon Transformationen. Eine Transformationsvorschrift wird dabei durch eine Regel der Form� �� beschrieben. Dabei entspricht � einem Ausdruck der Quellsprache, aus dem der Aus-

druck � in der Zielsprache generiert wird. Die Parameter-Annotation � der Vorschrift steht fürWerte, die für die Transformation notwendig sind, und bei Anwendung mit übergeben werden.Die resultierende Annotation � wird dagegen erst durch die Transformation selbst gesetzt undkann deshalb erst nach der Anwendung der Transformation verwendet werden.

Anmerkung: Vergleichbar sind die Annotation � mit den vererbten („inherited“) Attributen unddie Annotation � mit den synthetisierten („synthesized“) Attributen, wie sie von den attributiertenGrammatiken [ASU86] her bekannt sind.

5.2 Implementierung für XML-Objekt-Konstruktoren

Für die in Abschnitt 3.2.4 eingeführten Sprachkonstrukte wird in diesem Abschnitt das Vorge-hen zur Umsetzung in reinen Java-Quelltext definiert und an kurzen Beispielen illustriert. DieImplementierung erfolgt dabei mit Hilfe der Operationen aus dem DOM, das im Abschnitt 2.3vorgestellt und formal definiert wurde.

Bei der Umsetzung der XML-Objekt-Konstruktoren und der XPath-Ausdrücke im folgenden Ab-schnitt wird davon ausgegangen, dass das XOBE-Programm bereits in abstrakter Syntax vorliegt.Damit sind sowohl lexikalische als auch syntaktische Fehler ausgeschlossen. Weiterhin ist dieÜberprüfung der Typkorrektheit bereits erfolgreich abgeschlossen. Die für diese Aufgabe not-wendigen Schritte wurden in Kapitel 4 definiert und diskutiert.

Bei XML-Objekt-Konstruktoren handelt es sich um Ausdrücke, die im XOBE-Programm inner-halb unterschiedlichster Anweisungen auftreten, wie z. B. in Methodenaufrufen, Initialisierun-gen, Fallunterscheidungen oder Schleifenbedingungen. Die Umwandlung dieser Konstruktorenerzeugt, wie zu sehen sein wird, in der Regel eine Reihe von Java-Anweisungen. Mehrere gene-rierte Anweisungen können aber häufig nicht in die ursprüngliche Anweisung eingesetzt werden.Aus diesem Grund ist eine sogenannte bedeutungsgleiche Umsetzung notwendig. Beispielsweisemuss bei einem Auftreten eines XML-Objekt-Konstruktors als Parameter eines Methodenaufrufsin der transformierten Implementierung zunächst das DOM-Objekt erzeugt werden, bevor mitdiesem dann als Parameter die Methode aufgerufen werden kann. Diese Untersuchung bedeu-tungsgleicher Umsetzungen wird in dieser Arbeit nicht weiter vertieft, da sie für XML-Objekt-Konstruktoren und XPath-Ausdrücke stets ohne Schwierigkeit erreicht werden kann.

Um teilweise konstruierte DOM-Objekte weiter zu verarbeiten, werden unbenutzte, temporäreVariablen benötigt. In dieser Darstellung wird davon ausgegangen, dass für die Transformationdiese in unbegrenzter Menge zur Verfügung stehen. Die prototypische Implementierung stelltdies sicher. Zusätzlich ist für die Umsetzung eine Unterscheidung von XML-Objekt-Variablenund Java-Variablen notwendig, da eine unterschiedliche Verarbeitung erfolgt. Für die Vorschrif-ten der Transformation wird diese Einteilung als gegeben angenommen. Im Prototypen kanndiese Information von der vorangehenden Typüberprüfung übernommen werden.

Eine Implementierung von XOBE mittels DOM benötigt weiterhin zur Repräsentation von XML-Objekten stets ein Objekt der DOM-Klasse Document. In der folgenden Darstellung wird des-halb angenommen, dass eine solche Instanz stets mit der Deklaration der XML-Objekt-Variablenzur Verfügung steht. Ebenfalls werden für die Deklaration von XML-Objekt-Variablen geeigneteDOM-Anweisungen erzeugt, die hier nicht wiedergegeben sind. Für Variablen von Elementklas-sen werden Variablen der DOM-Klasse Element erzeugt und für Elementlisten Variablen der imnächsten Abschnitt eingeführten Schnittstelle XobeNodeList. Die Operationen +, item undgetLength der Elementlisten, werden auf die entsprechenden Methoden (addFirst, add,addAll, item und getLength) abgebildet. Eine leere Liste (<>) wird durch Anwendung desKonstruktors einer XobeNodeList-Implementierung erzeugt.

5.2. IMPLEMENTIERUNG FÜR XML-OBJEKT-KONSTRUKTOREN 131

Die Transformation von XML-Objekt-Konstruktoren ist definiert durch nachfolgende Transfor-mationsvorschriften.

Definition 5.1 (Transformation eines leeren Elements)Die Transformation für ein leeres Element mit dem Elementnamen � , der Attributliste � undder Java-Variablen für ein Dokument

�ist definiert durch:

� �< �� /> � � �n � Element n =

�.createElement(" � ");� �

� � � n

Dabei referenziert die Variable n einen Elementknoten. �

Das leere Element wird in eine Java-Anweisung transformiert, die einen Elementknoten mit-tels der entsprechenden DOM-Methode erzeugt. Danach erfolgt rekursiv die Transformation derAttributliste unter Übergabe des erzeugten Knotens als Parameter-Annotation. Der erzeugte Ele-mentknoten wird als resultierende Annotation zurückgegeben.

Definition 5.2 (Transformation eines nicht leeren Elements)Die Transformation für ein nicht leeres Element mit dem Elementnamen � , der Attributliste � ,der Inhaltsliste � und der Java-Variablen für ein Dokument


� �< �� > � </ � > � � �n �

Element n =�.createElement(" � ");� �

� � � n� �� n� � � � � � �� n.addChild( � � );...n.addChild( �� );

Dabei verweisen die Variablen n, � � , . . . �� auf Elementknoten. �

Aus einem nicht leeren Element werden mehrere Anweisung generiert. Zunächst wird für dasElement ein Elementknoten erzeugt. Weiter werden die Transformationen für die Attributlisteund die Inhaltsliste rekursiv aufgerufen. Die durch die Transformation der Inhaltsliste erzeugtenKnoten werden abschließend als Kinder zum Elementknoten hinzugefügt. Der erzeugte Element-knoten wird als resultierende Annotation zurückgegeben.

Definition 5.3 (Transformation einer Inhaltsliste)Die Transformation für eine Inhaltsliste � � . . . � � mit der Java-Variablen für ein Dokument

�ist

definiert durch: � ��

� � � � ��

Dabei referenzieren die Variable � � , . . . �� Elementknoten. �

Für eine Inhaltsliste erfolgt eine rekursive Anwendung der Transformation auf die Elemente derListe. Die resultierenden Annotationen werden als Resultat zurückgeliefert.


Definition 5.4 (Transformation einer Attributliste)Die Transformation für eine Attributliste � � . . . � � mit der Java-Variablen für einen Elementkno-ten � ist definiert durch: � �

� � ��

�

Für eine Attributliste erfolgt ebenfalls eine rekursive Anwendung der Transformation auf dieElemente der Liste, die Attribute.

Definition 5.5 (Transformation eines Attributs)Die Transformation für ein Attribut mit dem Attributnamen � , dem Attributwert � und der Java-Variablen für einen Elementknoten � ist definiert durch:

� � � = � � � � � � .setAttribute(" � ", � � � � � );�

Für ein Attribut erfolgt das Setzen des Wertes für den angegebenen Attributnamen mittels derentsprechenden Methode aus dem DOM.

Definition 5.6 (Transformation eines Attributwertes)Die Transformation für einen konstanten Attributwert mit den Zeichendaten � ist definiert durch:

� �" � " � � �

" � "

�

Für einen konstanten Attributwert wird eine konstante Java-Zeichenkette gleichen Inhalts gene-riert.

Definition 5.7 (Transformation von Zeichendaten)Die Transformation für Zeichendaten im Inhalt eines XML-Objekt-Konstruktors � mit der Java-Variablen für ein Dokument


� � � � � �n �Text n =

�.createTextNode(" � ");

Dabei verweist die Variable n auf einen Elementknoten. �

Für Zeichendaten im Inhalt eines Elements wird ein Textknoten erzeugt und als resultierendeAnnotation zurückgeliefert.

Definition 5.8 (Transformation einer XML-Objekt-Variablen)Die Transformation für eine Variable

�als Bezeichner für eine XML-Objekt-Variable mit der

Java-Variablen für ein Dokument�

ist definiert durch:� �{�} � � ��

�

5.2. IMPLEMENTIERUNG FÜR XML-OBJEKT-KONSTRUKTOREN 133

Für eine XML-Objekt-Variable in einem XML-Objekt-Konstruktor werden keine weiteren Java-Anweisungen erzeugt. Es wird lediglich die Variable selbst als Resultat zurückgegeben.

Definition 5.9 (Transformation einer Java-Variablen)Die Transformation für eine Variable

�als Bezeichner für eine Java-Variable im Inhalt eines

XML-Objekt-Konstruktors mit der Java-Variablen für ein Dokument�

ist definiert durch:

� �{�} � � �n �

Text n =�.createTextNode("" +

�);


Für eine Java-Variable im Inhalt von XML-Objekt-Konstruktoren wird ein Textknoten erzeugt,der den Wert der Variablen als Zeichenkette beinhaltet. Der erzeugte Knoten wird als Resultatzurückgeliefert. Als letzte Transformation wird die Vorschrift für Kommentar in XML angege-ben.

Definition 5.10 (Transformation von Kommentar)Die Transformation von Kommentar mit dem Kommentartext � ist definiert durch:

� �<!- � -> � � �n �

Comment n =�.createComment(" � ");


In einen Kommentarknoten, erzeugt durch die entsprechende DOM-Methode, wird der XML-Kommentar transformiert. Als resultierende Annotation wird der erzeugte Kommentarknotenzurückgegeben.

Die folgenden Beispiele, die die Sprachbeschreibung aus Abschnitt 2.1.2 verwenden, veran-schaulichen die formale Transformation durch die Umwandlung von XML-Objekt-Konstruktorenin reinen Java-Quelltext. Das erste Beispiel zeigt die Konvertierung eines einfachen Elements.

Beispiel 5.1Eine XOBE-Anweisung der Art

1 a u t h o r a = < a u t h o r >Thomas Mann </ a u t h o r > ;

wird durch die Transformation in folgende Java-Anweisungen umgewandelt:

1 Element a = d . c r e a t e E l e m e n t ( " a u t h o r " ) ;2 Text t 1 = d . c r e a t e T e x t N o d e ( " Thomas Mann" ) ;3 a . a d d C h i l d ( t 1 ) ;

Dabei werden für das Element ein Elementknoten (1) und für den Inhalt, bestehend aus Zeichen-daten, ein Textknoten (2) erzeugt. Der Textknoten wird anschließend als Kind des Elementkno-tens eingefügt (3). �

Im nächsten Beispiel hat ein Element ein Attribut und der Inhalt wird über eine Java-Variablefestgelegt.

Beispiel 5.2Aus den Anweisungen

1 f l o a t n = 8 . 0 0 ;2 p r i c e p = {n } 

in XOBE-Syntax wird durch die Transformation die Anweisungsfolge

1 f l o a t n = 8 . 0 0 ;2 Element p = d . c r e a t e E l e m e n t ( " p r i c e " ) ;3 p . s e t A t t r i b u t e ( " c u r r e n c y " , "EUR" ) ;4 Text t 2 = d . c r e a t e T e x t N o d e ( " " + n ) ;5 p . a d d C h i l d ( t 2 ) ;

in Java erzeugt. Der Wert der Java-Variable n wird hier als Zeichenkette in die DOM-Repräsen-tation eingefügt (4). Das Setzen des Attributwertes (3) erfolgt über die entsprechende Methodeaus dem DOM. �

Das letzte Beispiel zur Transformation von XML-Objekt-Konstruktoren beschäftigt sich mit ei-nem komplexeren Element. Es beinhaltet verschachtelte Elemente und mehrere XML-Objekt-Variablen.

Beispiel 5.3Die XOBE-Anweisung



transformiert zum Java-Quelltext:

1 Element b = d . c r e a t e E l e m e n t ( " book " ) ;2 b . s e t A t t r i b u t e ( " c a t a l o g " , " V a r i a " ) ;3

4 Element t 3 = d . c r e a t e E l e m e n t ( " t i t l e " ) ;5 Text t 4 = d . c r e a t e T e x t N o d e ( " L o t t e i n Weimar " ) ;6 t 3 . a d d C h i l d ( t 4 ) ;7

8 Element t 5 = d . c r e a t e E l e m e n t ( " c o n d i t i o n " ) ;9 Text t 6 = d . c r e a t e T e x t N o d e ( " Einband f i n g e r f l e c k i g , Rücken

v e r b l a ß t " ) ;10 t 5 . a d d C h i l d ( t 6 ) ;

5.3. IMPLEMENTIERUNG DER XPATH-AUSDRÜCKE 135

11

12 b . a d d C h i l d ( t 3 ) ;13 b . a d d C h i l d ( a ) ;14 b . a d d C h i l d ( t 5 ) ;15 b . a d d C h i l d ( p ) ;

Sowohl das äußere Element als auch die Elemente im Inhalt werden als Elementknoten (1,4,8)erzeugt. Die Inhalte der inneren Elemente werden als Textknoten kreiert (5,9) und in die entspre-chenden Elementknoten eingefügt. Am Ende wird der Inhalt des äußeren Elements, der aus deninneren Elementen und XML-Objekt-Variablen besteht, durch Kinderknoten zu dem Element-knoten, der das äußere Element repräsentiert, hinzugefügt (12-15). �

5.3 Implementierung der XPath-Ausdrücke

In diesem Abschnitt wird für die in Abschnitt 3.2.6 eingeführten Sprachkonstrukte die Überset-zung in reinen Java-Quelltext spezifiziert und an kurzen Beispielen erläutert. Die Implementie-rung erfolgt dabei ebenfalls mit den Operationen des DOM aus Abschnitt 2.3.

Die Semantik eines XPath-Ausdrucks ist dahingehend festgelegt, dass durch diesen eine Listevon Knoten selektiert wird. Dies führt in der Implementierung zu einer neuen Klasse für dieRepräsentation dieser Liste. Naheliegend ist, dafür die durch die DOM-Schnittstelle NodeListeingeführte Liste zu verwenden. Leider ist für diese aber keine Methode zum Hinzufügen vonElementen definiert, weshalb diese Schnittstelle für die hier bestehenden Anforderungen nichtausreicht. Aus diesem Grund wird für die Implementierung der XOBE-Programme die Schnitt-stelle NodeList unter dem Namen XobeNodeList erweitert und um die benötigte Methodenergänzt.

1 p u b l i c i n t e r f a c e XobeNodeList ex tends NodeLis t {2

3 p u b l i c boolean add ( Node node ) ;4 p u b l i c boolean a d d F i r s t ( Node node ) ;5 p u b l i c boolean addAl l ( NodeLis t nodes ) ;6

7 p u b l i c I t e r a t o r i t e r a t o r ( ) ;8

9 p u b l i c XobeNodeList g e t C h i l d N o d e s ( S t r i n g t e s t ) ;10 p u b l i c XobeNodeList ge tDescendan tNodes ( S t r i n g t e s t ) ;11 p u b l i c XobeNodeList g e t P a r e n t N o d e s ( S t r i n g t e s t ) ;12 p u b l i c XobeNodeList g e t A n c e s t o r N o d e s ( S t r i n g t e s t ) ;13 p u b l i c XobeNodeList g e t F o l l o w i n g S i b l i n g N o d e s ( S t r i n g

t e s t ) ;14 p u b l i c XobeNodeList g e t P r e c e d i n g S i b l i n g N o d e s ( S t r i n g


t e s t ) ;15 p u b l i c XobeNodeList g e t F o l l o w i n g N o d e s ( S t r i n g t e s t ) ;16 p u b l i c XobeNodeList g e t P r e c e d i n g N o d e s ( S t r i n g t e s t ) ;17 p u b l i c XobeNodeList g e t A t t r i b u t e N o d e s ( S t r i n g t e s t ) ;18 p u b l i c XobeNodeList g e t S e l f N o d e s ( S t r i n g t e s t ) ;19 p u b l i c XobeNodeList g e t A n c e s t o r O r S e l f N o d e s ( S t r i n g t e s t )

;20 p u b l i c XobeNodeList g e t D e s c e n d a n t O r S e l f N o d e s ( S t r i n g

t e s t ) ;21

22 } / / XobeNodeL i s t

Die Knotenliste XobeNodeList ist eine Erweiterung der DOM-Schnittstelle NodeList. Eswerden zusätzlich Methoden zum Hinzufügen von Elementen deklariert (3-5). Mit der Methodeiterator (7) ist es möglich, die Elemente einer Liste der Reihe nach durch eine Instanz derKlasse Iterator aus der Java-Standardbibliothek [Sun01a] zu bearbeiten. Die restlichen Me-thoden (9-20) dienen zur Selektion von Knoten bzgl. einer der in XPath definierten Achse. Siewerden für die Implementierung der XPath-Ausdrücke verwendet, wie sie durch die Transfor-mation, die in diesem Abschnitt beschrieben wird, entsteht.

Weiterhin wird davon ausgegangen, dass eine Implementierung der Schnittstelle XobeNode-List zur Verfügung steht. Da sich die Operationen bis auf die Methoden zur Knotenselektion,auf die in diesem Abschnitt noch eingegangen wird, nicht von den Methoden der SchnittstelleList aus der Java-Bibliothek unterscheiden, wird hier von einer Angabe abgesehen.

Die Transformation von XPath-Ausdrücken wird durch folgende Vorschriften definiert.

Definition 5.11 (Transformation eines XPath-Ausdrucks)Die Transformation eines XPath-Ausdrucks mit der XML-Objekt-Variablen � und den Lokali-sierungsschritten � � mit � � � � �� ist definiert durch:

� �� / � � /.../ � � � � t �

XobeNodeList t = new XobeNodeListImpl( � );� �� t

...� �� t

Dabei referenziert die Variable t eine Knotenliste. �

Ein XPath-Ausdruck im XOBE-Programm wird in mehrere Anweisungen reines Java transfor-miert. Das Ergebnis eines XPath-Ausdrucks besteht aus einer Liste von XML-Objekten. Diesewerden in einer Knotenliste t gespeichert, die zunächst aus dem aktuellen Knoten � besteht. Aufdiese initiale Knotenliste werden anschließend die durch den XPath-Ausdruck angegebenen Lo-kalisierungsschritte bzgl. der Achsen und Knotentests durchgeführt. Die Anweisungen für dieseLokalisierungsschritte werden durch die Anwendung der entsprechenden Transformationen er-zeugt. Die Knotenliste t wird abschließend als Resultatsannotation als Ergebnis zurückgeliefert.


Definition 5.12 (Transformation eines Schritts)Die Transformation eines Lokalisierungsschritts mit dem Achsenbezeichner � , dem Knotentest� , den Prädikaten � � mit � � � � �� und der Knotenliste � ist definiert durch:

� �� :: � [ � � ]...[ � � ] � �

��

� . � �� :: � � �

�;� �

[ � � ] � ��

...� �[ � � ] � �

�

�

Für einen Lokalisierungsschritt wird zunächst die Transformation für den Achsenbezeichner undden Knotentest durchgeführt. Diese operiert auf der mittels der Parameterannotation übergebenenKnotenliste � . Zum Schluss erfolgt die Transformation der Prädikate, die die Knotenliste weitereinschränken.

Definition 5.13 (Transformation eines Knotentests)Die Transformation eines Knotentests bzgl. der folgenden Achsen für den Elementnamen undder Knotenlistenvariablen � ist definiert durch:

� Selbst-Achse („self axis“)

� �self:: � �

�� = � .getSelfNodes(" ")

� Kind-Achse („child axis“)

� �child:: � �

�� = � .getChildNodes(" ")

� Nachfahr-Achse („descendant axis“)

� �descendant:: � �

�� = � .getDescendantNodes(" ")

� Nachfahr-oder-Selbst-Achse („descendant-or-self axis“)

� �descendant-or-self:: � �

�� = � .getDescendantOrSelfNodes(" ")

� Nachfolgende-Geschwister-Achse („following sibling axis“)

� �following_sibling:: � �

�� = � .getFollowingSiblingNodes(" ")

� Nachfolger-Achse („following axis“)

� �following:: � �

�� = � .getFollowingNodes(" ")

� Attribut-Achse („attribute axis“)� �attribute:: � �

�� = � .getAttributeNodes(" ")

� Eltern-Achse („parent axis“)� �parent:: � �

�� = � .getParentNodes(" ")

� Vorfahr-Achse („ancestor axis“)� �ancestor:: � �

�� = � .getAncestorNodes(" ")

� Vorfahr-oder-Selbst-Achse („ancestor-or-self axis“)� �ancestor-or-self:: � �

�� = � .getAncestorOrSelfNodes(" ")

� Vorherige-Geschwister-Achse („preceding sibling axis“)� �preceding_sibling:: � �

�� = � .getPrecedingSiblingNodes(" ")

� Vorgänger-Achse („preceding axis“)� �preceding:: � �

�� = � .getPrecedingNodes(" ")

�

Die Implementierung eines Knotentests bzgl. einer Achse erfolgt durch einen einfachen Metho-denaufruf für die Achse und den Knotentest. Für jede Achse existiert dafür eine eigene Methode,die die entsprechenden Knoten extrahiert. Dabei wird von der Methode die der Achse zugeord-nete Dokumentordnung berücksichtigt (siehe dazu Abschnitt 2.2). Der nachfolgende Knotentesterfolgt durch den Aufruf der Methode nodeTest innerhalb der Achsenmethode und schränktdie Knotenliste der Achse auf die im XPath-Ausdruck angegebenen Elemente ein.

Wie in der Transformation eines Knotentests bzgl. einer Achse ersichtlich ist, wird für jede Achseeine eigene Methode aufgerufen. Diese Methoden selektieren die jeweiligen Knoten der ange-gebenen Achse. In diesem Abschnitt wird beispielhaft die Implementierung der Methode get-ChildNodes für die Kind-Achse vorgestellt. Da sich die Routinen für die anderen Achsen aufähnliche Weise umsetzen lassen, wird an dieser Stelle auf deren Angabe verzichtet. Eine voll-ständige Aufführung findet sich im Anhang D.

1 p u b l i c XobeNodeList g e t C h i l d N o d e s ( S t r i n g t e s t ) {2 i n t i ;3 XobeNodeList r e s u l t ;4

5 r e s u l t = new XobeNodeLis t Impl ( ) ;6 f o r ( i = 0 ; i < t h i s . g e t L e n g t h ( ) ; i = i + 1 )7 r e s u l t . addAl l ( g e t C h i l d N o d e s ( t e s t , t h i s . i t em ( i ) ) ) ;8 re turn r e s u l t ;9 } / / g e t C h i l d N o d e s

10 p r i v a t e s t a t i c XobeNodeList g e t C h i l d N o d e s ( S t r i n g t e s t ,Node node ) {

11 i n t i ;12 NodeLis t c h i l d r e n ;13 XobeNodeList r e s u l t ;14

15 r e s u l t = new XobeNodeLis t Impl ( ) ;16 c h i l d r e n = node . g e t C h i l d N o d e s ( ) ;17 f o r ( i = 0 ; i < c h i l d r e n . g e t L e n g t h ( ) ; i = i + 1 )18 i f ( n o d e T e s t ( t e s t , c h i l d r e n . i t em ( i ) ) )19 r e s u l t . add ( c h i l d r e n . i t em ( i ) ) ;20 re turn r e s u l t ;21 } / / g e t C h i l d N o d e s

Die einstellige Methode getChildNodes (1-9) berechnet für die aufgerufene Knotenliste dieKinder der einzelnen Knoten in der Liste. Dies geschieht durch den Aufruf der zweistelligenMethode getChildNodes (7). Die Resultate der einzelnen Aufrufe werden in der Knotenlisteresult (3) abgelegt und am Ende der Methode zurückgegeben (8). In der zweistelligen Me-thode getChildNodes (10-21) werden die Kinder für den als Parameter übergebenen Knotennode dem Knotentest nodeTest (18) unterzogen. Nur die Knoten, die diesen bestehen, werdenin die Ergebnisknotenliste result (13) aufgenommen (19). Die Kinder eines Knotens erhält dieRoutine durch die DOM-Methode getChildNodes (16).

Die aufgerufene Methode nodeTest überprüft, ob es sich bei einem Knoten um eine bestimmteKnotenvariante handelt.

1 p r i v a t e s t a t i c boolean n o d e T e s t ( S t r i n g t e s t , Node i t em ){

2 i f ( t e s t . e q u a l s ( " t e x t ( ) " ) )3 t e s t = " # t e x t " ;4 e l s e i f ( t e s t . e q u a l s ( " comment ( ) " ) )5 t e s t = " #comment " ;6 e l s e i f ( t e s t . e q u a l s ( " node ( ) " ) )7 t e s t = " � " ;8 i f ( t e s t . e q u a l s ( " � " ) | | i t em . getNodeName ( ) . e q u a l s (

t e s t ) )9 re turn true ;

10 e l s e11 re turn f a l s e ;12 } / / n o d e T e s t

Der übergebene Knoten item soll der Variante test entsprechen. Nur dann wird von der Rou-tine true zurückgeliefert (9). Um welche Form es sich bei einem Knoten handelt, kann mittelsder DOM-Methode getNodeName (8) analysiert werden. Der Platzhalter * erfüllt für jeden

Knoten in XPath den Knotentest.

Das folgende Beispiel eines einfachen XPath-Ausdrucks zeigt die Anwendungen der definiertenTransformationsvorschriften.

Beispiel 5.4Das Beispiel selektiert mit Hilfe eines XPath-Ausdrucks aus dem XML-Objekt off, das einoffer-Element repräsentiert, die book-Elemente. Die Liste wird der Variablen ts zugewiesen.

1 xml<book � > t s = o f f / c h i l d : : book ;

Für die Implementierung des XPath-Ausdrucks ergeben sich nach der Ableitung gemäß der de-finierten Transformationsregeln folgende Java-Anweisungen.

1 XobeNodeList t = new XobeNodeLis t Impl ( o f f ) ;2 t = t . g e t C h i l d N o d e s ( " book " ) ;3 XobeNodeList t s = t ;

Mit der Variablen off wird eine temporäre Knotenliste t erzeugt (1). Für diese wird die Me-thode getChildNodes für die Kind-Achse aufgerufen (2), die auch den Knotentest auf denElementnamen book durchführt. Als letztes (3) wird die temporäre Liste t der im Beispiel an-gegebenen Listenvariable ts zugewiesen. �

Die Transformation von Prädikaten ist bis auf zwei Besonderheiten nicht weiter schwierig. DasPrädikat selbst wird als Schleife realisiert, in der der Prädikatausdruck für jedes Element in derKnotenliste ausgewertet wird. Ist der Ausdruck für einen Knoten ungültig, wird dieser aus derListe herausgefiltert.

Der Prädikatausdruck muss nur unwesentlich transformiert werden. Nur an Stellen, wo erneutXPath-Ausdrücke verschachtelt auftreten, muss eine Veränderung vorgenommen werden. Weilder Ausdruck ansonsten unverändert bleibt, wird in dieser Arbeit nur eine Transformationsvor-schrift für die Vergleichsrelation angegeben. Alle weiteren Relationen und Operationen der Aus-drücke lassen sich auf ähnliche Weise ganz analog umsetzen, weshalb auf diese Transformati-onsvorschriften an dieser Stelle verzichtet wird.

Die Parameter, die die Transformation benötigt, werden bis zu den möglichen XPath-Ausdrückeninnerhalb eines Prädikats oder den elementaren XPath-Operationen rekursiv durchgereicht. Nurdort können zusätzliche Java-Anweisungen erzeugt werden, die der eigentlichen Auswertung desAusdrucks vorangestellt werden müssen. Der eigentliche Ausdruck bleibt ansonsten praktischunverändert und wird dann als Resultat zurückgeliefert.

Die erste Besonderheit muss für XPath-Ausdrücke innerhalb von Prädikaten berücksichtigt wer-den, mit denen Bedingungen über die zu selektierenden Knoten formuliert werden können. Dasich solch ein XPath-Ausdruck während der Selektion auf den jeweils aktuellen Knoten bezieht,muss im Vergleich zu allgemeinen XPath-Ausdrücken eine modifizierte Transformation ange-wendet werden. Die zweite Sonderbehandlung erfahren die zwei elementaren XPath-Operatio-nen, die innerhalb von XPath-Ausdrücken auftreten können und sich auf die selektierte Knoten-


liste beziehen.

Die Transformation von Prädikaten ist durch nachfolgende Vorschriften definiert.

Definition 5.14 (Transformation eines Prädikats)Die Transformation eines Prädikats � mit der Knotenliste � ist definiert durch:

� �[ � ] � �

��

int p = 1; int l = � .getLength();Iterator it = � .iterator();while (it.hasNext()){Node n = it.next();� � � � � � p,l,n ��if (!

�) it.remove();

p = p + 1;} // while

�

Die Einschränkung der Knotenliste durch ein Prädikat kann erst nach dem letzten Knotentesterfolgen. Die Implementierung erfolgt über eine Schleife, die über die Knoten in der Knotenliste� iteriert. Innerhalb der Schleife wird für jeden Knoten die Transformation des Prädikatausdrucks� ausgeführt. Das Ergebnis wird dann mit dem booleschen Ausdruck

�ermittelt. Ist das Prädikat

nicht erfüllt, wird der behandelte Knoten aus der Knotenliste mit der Methode remove gelöscht.

Definition 5.15 (Transformation einer Vergleichsrelation)Die Transformation der Vergleichsrelation für die beiden Ausdrücke � und � mit der aktuellenPosition � in der Knotenliste, der letzten Position

�in der Knotenliste und der Java-Variablen für

den aktuellen Knoten � ist definiert durch:

� � � == �� ( �� == ��

� � ��

Die Transformation wird rekursiv auf den linken und rechten Ausdruck der Vergleichsrelationangewendet. Als Resultat der Transformation wird der Vergleich zwischen dem Ergebnis

� � derlinken und dem Ergebnis der rechten Transformation

� � als Java-Ausdruck abgeliefert.

Definition 5.16 (Transformation eines XPath-Ausdrucks innerhalb eines Prädikats)Die Transformation eines XPath-Ausdrucks innerhalb eines Prädikats mit den Lokalisierungs-schritten � � und � � � � �� , der aktuellen Position � in der Knotenliste, der letzten Position

�in der Knotenliste und der Java-Variablen für den aktuellen Knoten � ist definiert durch:

� �� /.../ �� t

�

XobeNodeList t = new XobeNodeListImpl( � );� �� t

...� �� t

Dabei verweist die Variable t auf eine Knotenliste. �

Die Transformation unterscheidet sich von der Transformation der allgemeinen XPath-Aus-drücke dahingehend, dass der aktuelle Knoten � , ein Parameter der Transformation, initial dieKnotenliste t bildet. Die rekursive Transformation der einzelnen Schritte des Ausdrucks unddie Knotenliste t als Resultat der Transformation gleichen der Definition für allgemeine XPath-Ausdrücke.

Definition 5.17 (Transformation elementarer XPath-Operationen)Die Transformation der elementaren XPath-Operationen innerhalb eines Prädikats mit der aktu-ellen Position � in der Knotenliste, der letzten Position

�in der Knotenliste und der Java-Variablen

für den aktuellen Knoten � ist definiert durch:� � �

� � � � � ��

� � � ��

�

Für die elementaren Operationen innerhalb von Prädikaten werden keine zusätzlichen Java-An-weisungen generiert. Es werden lediglich Variablen als Java-Ausdruck als resultierende Annota-tionen zurückgeliefert, für die Operation position die aktuelle Position � und für die Opera-tion last die letzte Position in der Knotenliste

�.

Im restlichen Abschnitt werden zwei XPath-Beispiele vorgestellt und deren durch Transformati-on erzeugte Implementierung beschrieben.

Beispiel 5.5Für dieses Beispiel wird erneut davon ausgegangen, dass die XML-Objekt-Variable off alsoffer-Element deklariert wurde. Es werden sämtliche book-Elemente, die nach dem fünftenBuch im Inhalt des offer-Elements auftreten, selektiert und der Knotenliste ts zugewiesen.

1 xml<book � > t s = o f f / c h i l d : : book [ p o s i t i o n ( ) > 5 ] ;

Die Transformationsvorschriften generieren für diesen XPath-Ausdruck die folgende Implemen-tierung:

1 XobeNodeList t = new XobeNodeLis t Impl ( o f f ) ;2 t = t . g e t C h i l d N o d e s ( " book " ) ;3 i n t pos = 1 ;4 i n t l a s t = t . g e t L e n g t h ( ) ;5 I t e r a t o r i t = t . i t e r a t o r ( ) ;6 whi le ( i t . hasNext ( ) ) {7 Node cnode = i t . n e x t ( ) ;8 i f ( ! ( pos > 5 ) )9 i t . remove ( ) ;

10 pos = pos + 1 ;11 } / / w h i l e12 XobeNodeList t s = t ;

Es wird eine temporäre Knotenliste t mit dem Element off initialisiert (1). Anschließend wer-den die Kinderelemente mit Namen book selektiert (2). Danach erfolgt die Initialisierung einerVariablen pos (3), die die Position des aktuellen Knotens im XPath-Ausdruck angibt, und einerVariablen last (3), die die Position des letzten Elements und damit die Länge der Knotenli-ste vor der Selektion durch das Prädikat angibt. Mit Hilfe einer Schleife (6-11) wird über dieKnoten in der Liste iteriert. Der aktuelle Knoten wird der Variablen cnode zugewiesen. Fürjeden Knoten wird der Prädikatausdruck ausgewertet (8). Ist dieser nicht erfüllt, wird der Knotenaus der Liste entfernt (9). Am Ende (12) wird die temporäre Liste t der im XOBE-Programmdeklarierten Liste ts zugewiesen. �

Das nächste Beispiel verwendet innerhalb des Prädikats erneut einen XPath-Ausdruck.

Beispiel 5.6Dieses Beispiel selektiert aus dem Inhalt eines book-Elements die price-Elementkinder. DieXML-Objekt-Variable b steht also für ein Element mit Elementnamen book. Die Elemente mitNamen price müssen ein Attribut currency haben, das mit dem Wert EUR belegt ist.

1 xml< t i t l e � > t s = b / c h i l d : : p r i c e [ s t r i n g ( a t t r i b u t e : :c u r r e n c y ) = = "EUR" ] ;

Für diesen Ausdruck wird eine ähnliche Implementierung wie im letzten Beispiel erzeugt.

1 XobeNodeList t = new XobeNodeLis t Impl ( b ) ;2 t = t . g e t C h i l d N o d e s ( " p r i c e " ) ;3 i n t pos = 1 ;4 i n t l a s t = t . g e t L e n g t h ( ) ;5 I t e r a t o r i t = t . i t e r a t o r ( ) ;6 whi le ( i t . hasNext ( ) ) {7 Node cnode = i t . n e x t ( ) ;8 XobeNodeList t 1 = new XobeNodeLis t Impl ( cnode ) ;9 t 1 = t 1 . g e t A t t r i b u t e N o d e s ( " c u r r e n c y " ) ;

10 i f ( ! ( s t r i n g ( t 1 ) = = "EUR" ) )11 i t . remove ( ) ;12 pos = pos + 1 ;13 } / / w h i l e14 XobeNodeList t s = t ;

Wie zu sehen ist, unterscheidet sich dieses Beispiel vom vorhergehenden hauptsächlich in derUmsetzung des Prädikatsausdrucks. Da in diesem ein XPath-Ausdruck auftritt werden für diesenzusätzliche Java-Anweisungen generiert (8-9), die der Auswertung des eigentlichen Prädikats-ausdrucks (10) vorangestellt werden müssen. Im Prädikatsausdruck wird der XPath-Ausdruckdurch die temporäre Knotenliste t1 ersetzt. Die im Ausdruck verwendete Methode stringist eine Methode aus der XPath-Bibliothek, von der angenommen wird, dass sie für die XOBE-Implementierung zur Verfügung steht. �


5.4 Erfahrungen und Leistungsdaten

Die wichtigsten Erfahrungen mit der prototypischen Implementierung des XOBE-Präprozessorsgibt dieser Abschnitt wieder. Neben der Präsentation von Leistungsmessungen werden im An-schluss weitere Entwicklungsmöglichkeiten vorgestellt.

5.4.1 Leistungsdaten

Für die Bewertung der Leistung der prototypischen Implementierung sind zwei Aspekte vonInteresse. Zu beachten ist zunächst, wieviel Rechenzeit der Präprozessor für die Übersetzung derXOBE-Programme benötigt und welcher Anteil davon auf den Algorithmus zur Typüberprüfungentfällt. Von Belang sind zum Zweiten die Ausführungszeiten der resultierenden Servlets, dienach der Transformation auf dem DOM basieren. Verglichen werden diese Testprogramme mitStandard-Servlet-Implementierungen, die ohne das DOM realisiert wurden.

Zu rechnen ist bei dieser Gegenüberstellung mit einer leichten Verschlechterung der Ausfüh-rungszeiten für die resultierenden XOBE-Programme, da in der DOM-Implementierung kom-plexere Objekt-Strukturen aufgebaut werden als bei einer Verarbeitung auf der Grundlage vonZeichenketten. Bei einem Vergleich mit reinen Java-Programmen, die ebenfalls eine DOM-Im-plementierung nutzen, wären für die XOBE-Programme allerdings keine Laufzeitverluste zu er-warten, weil es sich bei XOBE um ein statisches Typsystem handelt. Die deklarierten Bedingun-gen der Sprachbeschreibungen dienen lediglich zur Typüberprüfung während der Übersetzungund sind bis auf wenige Ausnahmen, die nur dynamisch überprüfbar sind, nicht zur Laufzeit desProgramms erforderlich. Die Messungen wurden durchgeführt auf einer SUN Blade 1000 mitzwei Ultra Sparc 3 (600 Mhz) Prozessoren und 1 GByte Hauptspeicher unter dem Betriebssy-stem Solaris 8 (SunOS 5.8).

Die folgenden Testprogramme wurden in die Leistungsmessung einbezogen:

Estate ist kurzes Programm, welches Web-Seiten in XHTML für den Web-Server eines Immo-bilienmaklers generiert. Es geht davon aus, dass Immobilienbeschreibungen in Form vonXML-Dateien vorliegen, die einer kleinen, nicht standardisierten Sprachbeschreibung fol-gen. Die Anwendung liest diese Dokumente als Eingabe ein und konvertiert die Daten ineigenständige XHTML-Dokumente zur Präsentation im Web.

MobileArchive ist eine Web-Anwendung auf der Basis von Servlets, die eine Anbindung fürmobile Geräte über die Wireless-Markup-Language (WML) für ein medizinisches Me-dienarchiv realisiert. Sie ermöglicht neben der Navigation durch die Ablagestruktur desArchivs, die einem Verzeichnisbaum des Dateisystems ähnelt, die Suche nach bestimmtenMedienobjekten. Medienobjekte einiger Formate können, soweit es das Wiedergabegerätzulässt, auch angezeigt werden. Detailliertere Ausführungen zu MobileArchive finden sichim nächsten Kapitel.

5.4. ERFAHRUNGEN UND LEISTUNGSDATEN 145

Übungsdatenverwaltung (ÜDV) ist eine Web-Anwendung, die ebenfalls auf Servlets basiert,und die Benutzerschnittstelle für ein akademisches Übungsdatenverwaltungssystem rea-lisiert. Die Anwendung ermöglicht dem Benutzer einerseits Eingaben, zum Beispiel vonKlausurergebnissen, die an das Datenbanksystem im Hintergrund weitergereicht werden,und andererseits auch Einblick in den aktuellen Datenbestand. Eine genauere Beschrei-bung zum Funktionsumfang liefert das folgende Kapitel.

Die Implementierung des ersten Testprogramms besteht aus mehreren, einfachen, iterativen Me-thoden, die eine einfache Traversierung der Eingabe mit gleichzeitiger Berechnung der Ausgabedurchführen. Die zweite Anwendung ermöglicht, wie beschrieben, eine WML-Verbindung zueinem Medienarchiv. Auf das Medienarchiv wird über eine von diesem zur Verfügung gestellteProgrammschnittstelle zugegriffen. Die Anwendung selbst speichert die Position des aktuellenBenutzers (Clients) in der Struktur des Archivs. Die dritte Testanwendung kommuniziert überJDBC mit dem Datenbankmanagementsystem des Herstellers Informix [Inf97b]. Die Eingabedes Benutzers wird in Datenbankanfragen umgewandelt und an die Datenbank weitergeleitet.Etwaige Antworten oder Resultate der Anfragen werden in XHTML eingebettet und an den Be-nutzer zurückgeschickt. In den Programmen Estate und ÜDV wird die Sprachbeschreibung vonXHTML (genauer XHTML-transitional) importiert, während die Anwendung MobileArchivedie Sprachbeschreibung WML verwendet.

Anmerkung: Für die beiden Anwendungen MobileArchive und ÜDV existierten bereits Imple-mentierungen in Standard-Java-Servlet-Technik, die im Rahmen dieser Arbeit für eine Umset-zung mit XOBE verwertet wurden. Bei dieser Umsetzung wurden viele einfache, unentdeckteFehler in den alten Implementierungen gefunden, die trotz sorgfältiger Testläufe der Implemen-tierungen übersehen wurden. Die häufigsten Fehler waren ungültig generierte XML-Fragmente.

Zeilenanzahl Übersetzungszeit (s) Ausführungszeit (s)Anwendung XOBE Schema gesamt Typanalyse Standard XOBE

Estate 158 1231 2.16 0.05 - 0.9MobileArchive 1045 355 4.49 0.16 0.03 0.04ÜDV 195 1196 4.61 0.07 0.01 0.01

Die Tabelle präsentiert die Anzahl der Zeilen der gesamten XOBE-Programme und die Anzahlder Zeilen der deklarierten Sprachbeschreibungen in den ersten beiden Spalten. In der zweitenGruppe von Spalten zeigt die Tabelle die Zeit, die für die Vorübersetzung der XOBE-Programmverbraucht wurde. Sie beinhaltet die Zeit des Einlesens, der Typinferenz, der Anwendung desSubtyp-Algorithmus und der Quelltext-Transformation in reines Java, wie sie in den letzten Ab-schnitten beschrieben wurde. Die Zeit, die der Subtyp-Algorithmus benötigt, wird in der Spal-te „Typanalyse“ dargestellt. Die dritte Spaltengruppe der Tabelle vermittelt einen Eindruck da-von, wie die Leistungsfähigkeit der Servlets von der DOM-basierten Implementierung beeinflusstwird. Die Spalte „Standard“ zeigt zum Vergleich die Zeit, die während der Ausführung der nichtmit XOBE implementierten Servlets vergeht. Die letzte Spalte gibt schließlich die Laufzeit derXOBE-Programme an.


Wie die Tabelle zeigt, arbeitet der Algorithmus zur Typüberprüfung für die vorgestellten An-wendungen mit akzeptabler Geschwindigkeit. Selbst Anwendungen, die relativ große XML-Ty-pen aus der Sprachbeschreibung von XHTML oder WML nutzen, werden in vielversprechen-der Zeit übersetzt. Die Ausführungszeiten der DOM-basierten Servlet-Implementierungen ist,wie erwartet, etwas langsamer als die der Standard-Servlets, liegen aber noch in einem erträgli-chen Rahmen. Der Geschwindigkeitsvorteil der Standard-Servlet-Implementierungen ist mit derfehlenden Garantie für korrekt generierte XML-Dokumente zu erklären. Aus diesem Grund istder dargestellte Vergleich den XOBE-Programmen gegenüber nicht besonders fair. Gerechter isteine Gegenüberstellung der XOBE-Implementierungen mit DOM-basierten Realisierungen, diedynamisch die Gültigkeit überprüfen. Für diesen Vergleich ist mit einem Vorteil für die XOBE-Programme zu rechnen.

5.4.2 Erweiterungen des Prototyps

Zur Erweiterung des aktuellen Prototyps gibt es vielfältige Möglichkeiten. So sind Verbesse-rungen bei der Implementierung der XML-Objekte als auch der XPath-Ausdrücke denkbar. DieIntegration in einen eigenständigen Java-Übersetzer wäre ebenfalls vorstellbar.

Für die Implementierung von XOBE das DOM zu nutzen ist eine naheliegende Vorgehensweise.Trotzdem sind aber auch andere Implementierungen realisierbar. Besonders sinnvoll erscheinteine Umsetzung, die einen weitergehenden Zugriff auf den Inhalt eines Elements ermöglicht, dersich stärker an der Struktur des Inhaltsmodells orientiert. Die Idee hinter diesem strukturorientier-ten Zugriff ist, dass der Benutzer den Inhalt eines Elements über die in der Sprachbeschreibungdefinierte Struktur anspricht. Diese kann, wie in Abschnitt 2.1 beschrieben, aus ineinander ver-schachtelten Konkatenationen, reguläre Vereinigungen usw. bestehen. Im DOM ist ein solcherZugriff nicht vorgesehen, da dort der Inhalt eines Elements zu einer Knotenliste von Kindernverschmolzen wird. Trotzdem ist mit dem DOM, falls die verwendete Sprachbeschreibung demBenutzer bekannt ist, eine gleichwertige Selektion des Elementinhalts möglich, die aber nichtohne zusätzliche, kostspielige Berechnungen auskommt. Dieser zusätzliche algorithmische Auf-wand ist notwendig, weil die Struktur der Inhaltsmodelle nicht in der DOM-Implementierunggespeichert wird. Würde eine XOBE-Implementierung die Struktur des Elementinhalts ebenfallsrepräsentieren, könnten bestimmte Zugriffe auf den Inhalt in konstanter Zeit erfolgen. Dies hätteeine Beschleunigung des Zugriffes um eine Größenordnung zur Folge, da die Selektion einesKindknotens im DOM linear zur Anzahl der Kinder eines Elements ist.

Die Implementierung der Auswertung der XPath-Ausdrücke ließe sich zunächst ganz naiv da-durch verbessern, dass eine Auswertung der Prädikate bereits während der Auswertung derAchsen erfolgt. Diese Optimierung ist allerdings nicht immer möglich, da sich Prädikate auchauf Eigenschaften der resultierenden Knotenliste einer Achse beziehen können. Um eine echteVerbesserung bei der Auswertung von XPath zu erzielen, sollte besser auf die Implementie-rung von [GKP02] zurückgegriffen werden. Dort wird ein Algorithmus angegeben, der sämtli-che XPath-Ausdrücke mit polynomiellem statt exponentiellem Aufwand berechnet. Für einge-

5.4. ERFAHRUNGEN UND LEISTUNGSDATEN 147

schränkte XPath-Anfrage ist sogar eine lineare Auswertung möglich, was eine Verbesserung umGrößenordnungen darstellt.

Interessant wäre auch die Integration von XOBE in einen Java-Übersetzer. Dadurch könnten diezusätzlichen Typinformationen eines XOBE-Programms für weitergehende Programmoptimie-rungen eingesetzt werden. Beispielsweise wäre die Repräsentation konstanter XML-Fragmentein optimierter Form möglich. Auch könnten Attribut- und Elementnamen einmalig in den be-treffenden XML-Objektklassen gespeichert werden, statt diese Information redundant in jedemXML-Objekt vorzuhalten.

Kapitel 6

Web-Anwendungen programmiert inXOBE

Um die in den vorherigen Kapiteln erarbeiteten Sprachkonstrukte von XOBE und deren Transfor-mation zu nutzen, wurden im Rahmen dieser Arbeit mehrere prototypische Implementierungenvon Web-Anwendungen vorgenommen. Zwei dieser Anwendungen werden in diesem Kapitelbeschrieben. Damit wird gezeigt, dass XOBE für die Realisierung von Web-Anwendung nutzbarund sinnvoll ist.

Die erste Anwendung implementiert einen Zugang zu einem Medienarchiv für mobile Geräte,die XML in der Form der Wireless-Markup-Language interpretieren können. Als zweite Web-Anwendung wird ein Informationssystems vorgestellt, das den Übungsbetrieb von Lehrveran-staltungen an Universitäten verwaltet. Es ist über eine XHTML-Schnittstelle dem Benutzer zu-gänglich. Die Datenhaltung dieser Anwendung erfolgt in einer relationalen Datenbank. BeideImplementierungen nutzen die Sprachkonstrukte von XOBE intensiv.

Der erste Abschnitt dieses Kapitels stellt den Zugang zu einem Medienarchiv über die Wireless-Markup-Language vor. Im folgenden Abschnitt erfolgt die Darstellung des Informationssystemsfür den Übungsbetriebs einer Universität. Beide Abschnitte sind so gegliedert, dass zunächst dieArbeitsweise der Anwendungen vorgestellt werden und anschließend auf Architektur und Detailsder Implementierung eingegangen wird.

6.1 WML-Anbindung eines Medienarchivs

Dieser Abschnitt beschreibt die Anwendung MobileArchive, einen Zugang zu einem Medien-archiv für mobile Endgeräte, realisiert in der Java-Erweiterung XOBE. Ein Vorgänger der An-wendung auf der Basis von Java-Servlets ist im Rahmen einer Studienarbeit [Kra01] am Institutfür Informationssysteme entstanden. Für die vorliegende Arbeit wurde diese Implementierung

150 KAPITEL 6. WEB-ANWENDUNGEN PROGRAMMIERT IN XOBE

mittels XOBE neu umgesetzt.

Die WML-Anbindung erfolgt für das Medienarchiv der Universität zu Lübeck MONTANA[BL00], das am Institut für Informationssysteme entwickelt wurde. Ein Medienarchiv dient derzentralen Archivierung und Verwaltung von Mediendaten. Ein Laden und Speichern dieser Da-ten wird von entfernten Rechnern im Netzwerk ermöglicht. Die Mediendaten oder -objekte sinddigitale oder digitalisierte Daten der verschiedensten Formate, wie z. B. Bilder, Filme oder Au-diosequenzen, die als Dateien abgelegt werden. Die Dateien im Archiv werden ähnlich einemDateisystem in Verzeichnissen hierarchisch angeordnet. Verzeichnisse werden wie Medienob-jekte als Archivobjekte aufgefasst. Der Zugriff auf die Daten wird über eine Benutzerrechtever-waltung kontrolliert.

Die Benutzerschnittstelle des Medienarchivs ist als Web-Schnittstelle konzipiert. Die Kommuni-kation erfolgt über einen Browser, der die Navigation durch die Verzeichnisstruktur ermöglicht.Medienobjekte können zum Archiv hinzugefügt und aus dem Archiv heruntergeladen werden.Die Schnittstelle ermöglicht die Manipulation von Objekteigenschaften der Medienobjekte, dieSuche nach Mediendaten anhand der Eigenschaften und in bestimmten Fällen eine Präsentationder Mediendaten selbst über den Browser.

Für das Anzeigen von Informationen auf mobilen Endgeräten, wie Handys oder PDAs, ist inXML die Auszeichnungssprache Wireless-Markup-Language (WML) spezifiziert worden. Diedefinierten Elemente erinnern stark an HTML. Beispielsweise werden Elemente zur Textforma-tierung, für Hyperlinks, Bilder und Eingabefelder zur Verfügung gestellt. Der wichtigste Unter-schied ist, dass ein WML-Dokument, das sogenannte „deck“, nicht nur aus einer, sondern ausmehreren anzeigbaren Seiten besteht, den „cards“. WML ist ein Standard des WAP-Forums,das sich ebenfalls mit dem darunter liegenden Protokoll Wireless-Application-Protocol (WAP)beschäftigt. Die Spezifikationen zu WAP und WML finden sich in [Wir00], einführende Be-schreibungen zum Thema können in [KT01] nachgelesen werden.

6.1.1 Arbeitsweise und Benutzerzugang

Die Anwendung verwirklicht den Zugriff auf das Medienarchiv über ein mobiles Endgerät. Eintypischer Sitzungsablauf lässt sich wie folgt beschreiben. Der Anwender, der mit dem Medienar-chiv Kontakt aufnehmen will, wählt in seinem WML-fähigen Gerät die Seite des Medienarchivsan. Die Aufforderung zur Eingabe der Zugangsdaten beantwortet er mit seinem Benutzernamenund dem zugehörigen Kennwort. Der Anwender ist nun im Archiv angemeldet. Ihm stehen vierverschiedene Operationen zur Verfügung:

1. Navigation durch die Verzeichnishierarchie des Medienarchivs, zum gezielten Auffindenvon Medienobjekten,

2. Anzeigen der Eigenschaften von ausgewählten Medienobjekten,

3. Anzeigen von Medienobjekten selbst für einige wenige Formate und

6.1. WML-ANBINDUNG EINES MEDIENARCHIVS 151

Abbildung 6.1: Loginseite

4. eine allgemeine Suchanfrage nach Medienobjekten.

Diese Operationen können beliebig oft wiederholt und dabei wahllos kombiniert werden. Meldetder Benutzer sich zum Schluss vom Medienarchiv ab, ist die Sitzung damit beendet.

Die Umsetzung der Anbindung zum Medienarchiv in WML ist eine durchaus anspruchsvolleAufgabe. Schwierig erscheint vor allem die Darstellung, bei der eine Reduktion auf das nötig-ste erfolgen muss. So ist es in WML nicht sinnvoll, grafische Elemente, wie in HTML üblich,in die Benutzerführung einfließen zu lassen, da die Anzeigen sehr klein sind. Die Menüführungist, soweit möglich, komprimiert und wird mittels Auswahllisten und verzweigenden Hyperlinksrealisiert. Nach der Anmeldung im Archiv mit Benutzernamen und Kennwort, bietet sich demAnwender die Möglichkeit in den Verzeichnissen mit Medienobjekten zu navigieren. Eine Aus-wahlliste präsentiert dabei die Unterverzeichnisse des aktuellen Verzeichnisses, eine weitere gibtdie Namen der Medienobjekte aus. Über den Hyperlink eines Unterverzeichniseintrags ist derInhalt dieses Unterverzeichnisses zu erreichen, der auf einer gesonderten Seite dargestellt wird.

Ein zentraler Aspekt der Anwendung ist die Möglichkeit zur Formulierung von Suchanfragenan das Medienarchiv. Diese Anfragen können sich auf die Eigenschaften der Medienobjektebeziehen, die beim Einstellen der Objekte in das Archiv durch beschreibende Attribute festgelegtwurden. Die Ergebnisse werden in Listen mit maximal zehn Einträgen aufbereitet. Damit wirdeine einigermaßen übersichtliche und sinnvolle Aufteilung des Resultats gewährleistet.

Die Anzeigemöglichkeiten der WML-Browser sind sehr beschränkt, weshalb die meisten Medien-objekte nicht angezeigt werden können. Möglich ist eine Darstellung von Texten der FormateWML und ASCII sowie von Bildern im Format Wireless-BMP (WBMP). Bilder der Formate


Abbildung 6.2: Anzeige der Unterverzeichnisse Abbildung 6.3: Anzeige der Medienobjekte

BMP, GIF, JPEG und TIFF können ebenfalls angezeigt werden, wobei der Inhalt in das For-mat WBMP konvertiert wird, weshalb mit starken Einschränkungen in der Darstellung gerech-net werden muss. Bei allen anderen Medienobjekten werden die Objekteigenschaften statt desInhalts angezeigt. Die Eigenschaften von Medienobjekten werden in tabellarischer Form ange-zeigt. Dazu zählen das Format des Objekts, der Name des Autors und das Datum der Erstellung,um nur einige zu nennen.

6.1.2 Architektur und Implementierungsdetails

Die Architektur der Anwendung gliedert sich in drei mehr oder weniger unabhängige Schichten.Eine Schicht steht für das Datenmodell zur Repräsentation der beteiligten Daten, eine zweitesteuert die Ein- und Ausgabe durch einen Automaten und die Präsentationsschicht erzeugt dieAusgabe in der Auszeichnungssprache WML und überträgt Eingaben in Ereignisse des Automa-ten. In diesem Abschnitt werden die drei Schichten in der Reihenfolge Datenmodell, Automatund Präsentation kurz vorgestellt.

Das Datenmodell der Anwendung ist sehr einfach und in Abbildung 6.8 als Klassendiagrammdargestellt. Die Klasse WMLSession repräsentiert die Sitzung von Anwendern zum Medienarchivüber die WML-Anbindung. Jedes Objekt dieser Klasse besteht aus einem aktuellen Archivobjektder Klasse ArchivObject und einer optionalen Anfrage der Klasse Query.

Die Klasse ArchivObject ist eine abstrakte Klasse von der die Klassen Directory und MediaOb-ject abgeleitet sind. Mit Directory werden Verzeichnisse im Medienarchiv repräsentiert, Medien-


Abbildung 6.4: Eingabe der Anfrage Abbildung 6.5: Anzeige des Suchergebnisses

objekte des Archivs durch Instanzen der Klasse MediaObject. Von der Klasse MediaObject exi-stiert noch eine spezialisierte Klasse DisplayableMedia für die Medienobjekte, die auf einemmobilen Endgerät dargestellt werden können.

Anfragen an das Medienarchiv werden durch Objekte der Klasse Query modelliert. Sie bestehenaus einem Anfragetext query, nach dem im Archiv gesucht wird. Die Ergebnisse einer Anfragewerden mit dem Attribut result ebenfalls im Query-Objekt abgelegt.

Das Ein- und Ausgabeverhalten wird durch den Automaten, der in Abbildung 6.9 dargestellt ist,beschrieben. Wie zu sehen ist, besteht der Automat auf der obersten Ebene aus den vier Zustän-den Login request, Display archiv object, Display query und Good bye message. Der Automatstartet im Zustand Login request, von dem aus in den Zustand Display archiv object verzweigtwird. Von diesem sind sowohl die Zustände Display query als auch Good bye message erreichbar.Der letzte Zustand beendet den Ablauf des Automaten. Sämtliche Ereignisse, die zu Zustands-übergängen führen, werden durch den Anwender ausgelöst, indem dieser Benutzereingaben vor-nimmt.

Die beiden Zustände Display archiv object und Display query gliedern sich in mehrere Unter-zustände. Der Zustand Display archiv object unterscheidet zunächst, ob ein Verzeichnis oderein Medienobjekt dargestellt werden soll. Je nachdem verzweigt der Automat zu den ZuständenDisplay subdirectories und Display media objects oder Display properties und Display content.In den Zustand Display content verzweigt der Automat nur, falls es sich beim ausgewähltenMedienobjekt um ein darstellbares handelt. Im Zustand Display query werden die UnterzuständeEnter search string und Display search result durchlaufen. Beim Übergang zwischen diesen bei-

Abbildung 6.6: Anzeige eines Medienobjekts Abbildung 6.7: Anzeige der Eigenschaften

den Zuständen erfolgt die Suchanfrage an das Medienarchiv. Werden auf die Anfrage hin mehrErgebnisse gefunden, als auf einer Seite darstellbar sind, werden diese auf mehrere Seiten ver-teilt, zwischen denen hin und her geschaltet werden kann. Dabei wechselt der Automat nicht denZustand.

Zum Ende dieses Abschnitts folgt die Implementierung von zwei Methoden. Sie realisieren inder Anwendung einen Teil der Ein- und Ausgabe.

1 p u b l i c p queryRequestAsWML ( ) {2 S t r i n g u r l ;3 p p a r a ;4

5 u r l = encodeURL ( " WMLSession? l i n k = e x e c S e a r c h&s e a r c h Q u e r y=$ ( s e a r c h Q u e r y ) " ) ;

6

7 / / S u c h s t r i n g e i n g e b e n8 p a r a = S u c h s t r i n g : 9 10 11 <a a c c e s s k e y =" 7 " h r e f =" { u r l } ">Suche s t a r t e n < / a

>12 ;13


Abbildung 6.8: Datenmodell der WML-Anbindung

14 re turn p a r a ;15 } / / queryRequestAsWML

Die Methode queryRequestAsWML erzeugt ein WML-Fragment mit dem der Benutzer zurEingabe einer Zeichenkette aufgefordert wird, nach der im Medienarchiv gesucht werden soll.Es ist ersichtlich, dass dafür ein p-Element mit einem Formularfeld (9) im Inhalt der XML-Objekt-Variablen para zugewiesen wird (8-12). Durch einen Hyperlink (11) kann der Anwenderdie Suche aktivieren. Die Referenz (7), die durch dieses Ereignis aktiviert wird, übergibt denaktivierten Link und die eingegebene Zeichenkette.

Das etwas längere Beispiel zeigt die Methode subDirectoriesAsWML.

1 p u b l i c p subDirector iesAsWML ( ) {2 S t r i n g path , name , subDir , p a r e n t D i r ;3 S t r i n g [ ] s u b D i r s ;4 p p a r a ;

Displaymedia objects

Displaycontent

Displaysubdirectories

Displayproperties

Disply archive object (Directory) Display archive object (Object)

dispDir dispCont

backchangDir

Enter searchstring

Display 10results

Display resultsup

down

starten

neueSuche

Display queryGood bye message

Loginrequest

login

logout

logout

changDir search

changDir

contProp

changDircontProp

Abbildung 6.9: Zustandsautomat der WML-Anbindung

5 xml <( o p t i o n ) � > o p t s ;6

7 t r y {8 p a t h = a r c O b j . g e t F u l l P a t h ( ) ;9 name = a r c O b j . getName ( ) ;

10 s u b D i r s = a r c O b j . g e t C h i l d s ( 1 ) ;11 i f ( p a t h . e q u a l s ( " / " + name ) )12 p a r e n t D i r = " / workspace " ;13 e l s e14 p a r e n t D i r = p a t h . s u b s t r i n g ( 0 , p a r e n t D i r . l e n g t h ( ) �

name . l e n g t h ( ) � 1 ) ;15

16 o p t s = < > ;17 f o r ( i n t i = 0 ; i < s u b D i r s . l e n g t h ; i = i + 1 ) {18 subDi r = p a t h + " / " + s u b D i r s [ i ] ;19 o p t s = o p t s + < o p t i o n v a l u e =" { subDi r } " >{ s u b D i r s [ i

]} < / o p t i o n > ;20 } / / f o r21

6.2. ÜBUNGSDATENVERWALTUNG 157

22 ur lChange = encodeURL ( " WMLSession? l i n k = changeDi r&s e a r c h Q u e r y =$ ( d i r e c t o r y ) " ) ;

23 u r l F i l e s = encodeURL ( " WMLSession? l i n k = s h o w F i l e s " ) ;24

25 p a r a =26 27 { a r c O b j . g e t F u l l P a t h ( ) } 28 < s e l e c t name=" d i r e c o r y ">29 < o p t i o n v a l u e =" { p a r e n t D i r } " > . . < / o p t i o n >30 { o p t s }31 </ s e l e c t > 32 <a a c c e s s k e y =" 9 " h r e f =" { ur lChange } ">Verz . wechs . < /

a>33 <a a c c e s s k e y =" 2 " h r e f =" { u r l F i l e s } ">Verz . anz . < / a>34 ;35 } / / t r y36 ca tch ( RemoteExcept ion e ) {37 p a r a = F e h l e r : { e } ;38 } / / c a t c h39

40 re turn p a r a ;41 } / / subDirec tor iesAsWML

In dieser Methode wird ebenfalls ein Element der Klasse p erzeugt und zurückgegeben. Der In-halt besteht u. a. aus einer Liste von option-Elementen, die in einer Schleife (17-20) erzeugtwird. Damit ist es für den Anwender möglich, über eine Auswahlliste in eines der Unterverzeich-nisse zu wechseln.

6.2 Übungsdatenverwaltung

In diesem Abschnitt wird als zweite Anwendung eine Übungsdatenverwaltung (ÜDV) beschrie-ben, die unter Verwendung der Java-Erweiterung XOBE realisiert worden ist. Die Anwendungentstand im Rahmen einer Studienarbeit [Spi02] am Institut für Informationssysteme in reinerJava-Servlet-Technik. Für diese Arbeit wurden Teile dieser Implementierung mittels XOBE neugeschrieben. Eine Übungsdatenverwaltung ist eine Anwendung, die in der universitären Leh-re eingesetzt wird. In vielen Lehrveranstaltungen müssen von den Teilnehmenden sogenannteScheinkriterien erfüllt werden, um am Ende des Semesters einen sogenannten Übungs- oderTeilnahmeschein zu erhalten. Scheinkriterien können dabei in den unterschiedlichsten Formenauftreten, wie z. B. Übungsaufgaben, Vorträgen, Ausarbeitungen oder Klausuren. Die Übungs-datenverwaltung dient zum Verwalten der durch die Scheinkriterien anfallenden Daten. Es wer-den Daten über Veranstaltungen, teilnehmende Studierende, Scheinkriterien und die erzielten


Ergebnisse der Studierenden für Scheinkriterien im System abgespeichert.

Durch die Übungsdatenverwaltung ergeben sich einige Erleichterungen für das Durchführen derLehrveranstaltungen. Arbeitsabläufe, die vorher von Hand bearbeitet werden mussten, werdennun durch die Anwendung automatisch erledigt. Dazu zählt der Aushang der Ergebnislisten,der nach Korrektur einer Klausur vom System generiert wird. Ebenso werden die Übungs- oderTeilnahmescheine, die nach erfolgreicher Teilnahme an die Studierenden ausgehändigt werden,durch die Übungsdatenverwaltung erzeugt.

6.2.1 Arbeitsweise und Benutzerzugang

Die Übungsdatenverwaltung wird über die Adresse der Startseite aufgerufen. Dem Anwenderpräsentiert sich die Aufforderung zur Eingabe von Benutzernamen und Kennwort. Durch den

Abbildung 6.10: Aufforderung zur Anmeldung

Schutz der Daten mittels unterschiedlicher Benutzerrechte, wird der Zugriff auf die Daten imSystem stark eingeschränkt. Nur berechtigte Personen erhalten die Möglichkeit bestimmte Teileder Daten einzufügen, zu verändern oder zu löschen. Im Sekretariat können Veranstaltungen undStudierende eingefügt und korrigiert werden. Der Dozent ist in der Lage die Scheinkriterien fürdie von ihm gehaltenen Lehrveranstaltung zu definieren. Leistungsergebnisse der Studierendenwerden vom korrigierenden Assistenten eingetragen.

Nach dem Anmelden im System kann der Benutzer eine Lehrveranstaltung auswählen, für die erDaten abfragen, eintragen oder ändern möchte. Selbstverständlich gibt es auch die Möglichkeit


Abbildung 6.11: Auswahl der Veranstaltungen

eine neue Veranstaltung, die noch nicht in der Übungsdatenverwaltung eingetragen ist, hinzuzu-fügen. Dazu werden Daten, wie Name der Lehrveranstaltung, Name des anbietenden Dozenten,Semesterangabe und Web-Adresse benötigt.

Hat der Anwender eine Lehrveranstaltung ausgewählt, bieten sich ihm die Möglichkeiten Schein-kriterien für die Veranstaltung zu definieren, teilnehmende Studierende einzutragen, die Leistun-gen der teilnehmenden Studierenden für die Scheinkriterien zu editieren und Listen bzw. Scheinezu erstellen. Weiterhin können Lehrveranstaltungen in kleine Übungen aufgeteilt und gruppiertwerden.

Studierende, die an einer Lehrveranstaltung teilnehmen, aber noch nicht im System bekannt sind,können über eine eigene Seite eingetragen werden. Für Studierende werden die Angaben Name,Matrikelnummer, Geburtsdatum, Emailadresse sowie Studiengang abgelegt. Ist ein Studierenderdem System schon aus einer vorherigen Lehrveranstaltung bekannt, entfällt die erneute Eingabeder Daten; er kann direkt als Teilnehmer der Veranstaltung zugeordnet werden.

Studierende, die einer Lehrveranstaltung zugeordnet sind, also an dieser teilnehmen, kann dasSystem anzeigen. Es besteht die Möglichkeit Teilnehmerlisten und Listen mit Emailadressen zu


Abbildung 6.12: Eintragen eines neuen Studierenden

erstellen. Letztere dient dazu, um alle teilnehmenden Studierenden über einen elektronischenRundbrief erreichen zu können.

Wie erwähnt, können für Lehrveranstaltungen Scheinkriterien definiert werden. Jede Anforde-rung besteht u. a. aus einer Bezeichnung, einer maximal erreichbaren Punktzahl, einer Beste-hensgrenze und einem Abgabedatum.

Für eine ausgewählte Lehrveranstaltung können die durch die teilnehmenden Studierenden er-brachten Leistungen eingesehen und eingetragen werden. In einer Gesamtübersicht werden zu-nächst sämtliche Anforderungen mit den bisherigen Ergebnissen dargestellt. Für das Eintragenneuer Resultate muss ein Scheinkriterium ausgewählt werden. Für dieses lassen sich dann dieErgebnisse mit erzielten Punktzahlen für jeden Studierenden eintragen.

Für jede Vorlesung können eine Reihe von Listen und Scheinen erstellt werden. Es gibt Listenmit allen Teilnehmern der Veranstaltung, leere Listen zum Eintragen von Studierenden, Lei-stungsübersichten für bestimmte Scheinkriterien sowie Ausfalllisten für Klausuren und mündli-che Rücksprachen. Weiterhin ist es möglich eine archivierbare Gesamtübersicht am Semester-ende zu erstellen. Über einen weiteren Punkt können für Studierende, die die Scheinkriterienerfolgreich erfüllt haben, die Übungs- oder Teilnahmescheine erstellt werden. Die Überprüfungder definierten Scheinkriterien vollzieht das System dabei automatisch.


Abbildung 6.13: Anzeigen der teilnehmenden Studierenden

6.2.2 Architektur und Implementierungsdetails

Ähnlich zur WML-Anbindung ist für die Architektur der Übungsdatenverwaltung ebenfalls eineUmsetzung in mehreren Schichten gewählt worden. Die an der Anwendung beteiligten Datenwerden in einem Objektmodell repräsentiert. Das Verhalten der Ein- und Ausgabe wird übereinen Automaten gesteuert während die Ein- und Ausgabe selbst, die durch XHTML erfolgt,durch eine separate Präsentationsschicht definiert wird. Dieser Abschnitt stellt die drei SchichtenObjektmodell, Automat und Präsentation in dieser Reihenfolge kurz vor. Neben den drei schonangesprochenen Schichten wird für die Kommunikation zur Datenbank eine weitere benötigt,worauf in dieser Arbeit aber nicht näher eingegangen wird.

In Abbildung 6.17 ist das Objektmodell der Übungsdatenverwaltung zu sehen. Mit Objektender Klasse ÜDVSession wird die Sitzung eines Benutzers zum Informationssystem realisiert. Siebesteht aus zwei optionalen Objekten der Klassen Veranstaltung und Übung.

Die Objekte der Klasse Veranstaltung repräsentieren die Daten für Lehrveranstaltungen. Sie ste-hen in Beziehung mit Objekten der Klassen Raum, Zeit und Dozent, die entsprechend alle rele-vanten Daten über Räume, Zeiten und Dozenten modellieren. Analoges gilt für Anforderungen,Studierende und Übungsgruppen, die durch Objekte der Klassen Anforderung, Studierender undÜbung repräsentiert werden. Die genauen Daten, die im System gespeichert werden sind derAbbildung 6.17 zu entnehmen und werden hier nicht weiter beschrieben.

Interessanter sind dagegen die Beziehungen, die zwischen den Klassen bestehen. Jede Veran-staltung und jede Übung findet an bestimmten Orten und Zeiten statt. Eine Beziehung zwischenVeranstaltung und Dozent bzw. zwischen Übung und Dozent gibt an, welcher Dozent die Lehr-veranstaltung oder Übung leitet. Für jede Veranstaltung kann eine Menge von Scheinkriterien de-finiert werden, was mit einer Assoziation zwischen den Klassen Veranstaltung und Anforderung

Abbildung 6.14: Scheinkriterien festlegen

ausgedrückt wird. Die Information, welcher Studierende welche Veranstaltung oder Übung be-sucht, wird durch die Beziehung zwischen den Klassen Veranstaltung, Studierender und Übungrepräsentiert. Wichtig ist auch die Assoziation zwischen Studierenden und den Anforderungen,denn dort werden die Daten gespeichert, die angeben, welcher Studierende welches Scheinkrite-rium mit welcher Punktzahl absolviert hat.

Der Automat, den die Abbildung 6.18 darstellt, beschreibt das Ein- und Ausgabeverhalten derÜbungsdatenverwaltung. Er besteht aus den sechs Zuständen Login-Aufforderung, Veranstaltungauswählen, Veranstaltung gewählt, Administration, Veranstaltung anlegen und Auf-Wiedersehen-Meldung. Der Automat wird im Zustand Login-Aufforderung gestartet, von dem aus dieser in denZustand Veranstaltung auswählen übergeht. Dieser zentrale Zustand lässt eine Verzweigung indie Zustände Veranstaltung gewählt, Administration und Veranstaltung anlegen zu. Weiterhin istauch ein Übergang in den Zustand Auf-Wiedersehen-Meldung möglich, der den Ablauf des Auto-maten beendet. Auch bei diesem Automaten werden alle Ereignisse, die zu Zustandsübergängenführen, durch Eingaben des Anwenders ausgelöst.

Um einen Eindruck zu bekommen, wie XOBE in der Anwendung Verwendung findet, werdenim restlichen Abschnitt zwei Methoden aus der Implementierung vorgestellt. Die Methode ver-anstaltungenAsTable stellt eine Liste von Veranstaltungen in einer XHTML-Tabelle dar.

1 p r i v a t e t a b l e v e r a n s t a l t u n g e n A s T a b l e ( L i s t c o u r s e s ) throwsSQLExcept ion {

2 I t e r a t o r i t e r ;3 xml <( f o n t ) ? > s u b T i t l e ;4 xml <( t d ) + > d e s c s ;

Abbildung 6.15: Eintragen der Leistungen

Abbildung 6.16: Erstellen von Listen und Scheinen

5 xml <( t r ) + > rows ;6 V e r a n s t a l t u n g c o u r s e ;7

8 rows = < t r >9 <td >< c e n t e r >Bezeichnung </ c e n t e r > </ td >

10 <td >< c e n t e r > Semester </ c e n t e r > </ td >11 <td >< c e n t e r >Dozent </ c e n t e r > </ td >12 </ t r > ;13

14 i t e r = c o u r s e s . i t e r a t o r ( ) ;15 whi le ( i t e r . hasNext ) {16 c o u r s e = ( V e r a n s t a l t u n g ) i t e r . n e x t ( ) ;

Abbildung 6.17: Datenmodell der Übungsdatenverwaltung

17

18 i f ( c o u r s e . h a s U n t e r t i t e l ( ) )19 s u b T i t l e = < f o n t s i z e =" � 2" >{ c o u r s e . g e t U n t e r t i t e l ( )

} </ f o n t > ;20 e l s e21 s u b T i t l e = < > ;22

23 d e s c s = < td ><a h r e f =" v e r w a l t u n g s s e r v l e t ? l i n k =v e r a n s t a l t u n g _ d e t a i l&v e r a n s t a l t u n g _ I D ={ c o u r s e .ge t ID ( ) } " >{ c o u r s e . g e t T i t e l ( ) } </ a >{ s u b T i t l e } </ td > ;

24 d e s c s = d e s c s + < td >{ c o u r s e . g e t S e m e s t e r ( ) } </ td > ;25 d e s c s = d e s c s + < td >{ c o u r s e . g e t D o z e n t ( ) } </ td > ;26

27 rows = rows + < t r >{ d e s c s } </ t r > ;

Übungausgewählt

Übung anzeigenVeranstaltungausgewählt

Auswahl einerVeranstaltung

Administration/Sonstiges

Leistungbearbeiten

Login-Aufforderung

Teilnehmerbearbeiten

Zeiten und Orteanzeigen

erstellenListen/Scheine Anforderung

bearbeiten

Neue Veranstaltunganlegen

MeldungGood-Bye-

übAnz

andÜb

veranAusw

listSchein

login

logout logout

logout

neueVeran

zurAusw

adminSonst

zurAusw

zZVeran

andVeran zZVeran

leistBearb leistBearb

zZÜbzZVeran

übAusw

teilBearb teilBearb

zZVeran zZÜb

zZVeran

zOBearb zOBearb

zZÜb

Abbildung 6.18: Zustandsautomat der Übungsdatenverwaltung

28 } / / w h i l e29

30 re turn < t a b l e >{ rows } </ t a b l e > ;31 } / / v e r a n s t a l t u n g e n A s T a b l e

Zunächst werden der Variablen rows die Überschriften der drei Spalten der Tabelle zugewiesen(8-12), die die Zeilen der neuen Tabelle zwischenspeichert. Anschließend werden alle Veranstal-tungen der Reihe nach mittels eines Iterators (14-28) durchgegangen. Falls eine Veranstaltungeinen Untertitel besitzt (18), wird dieser in der Variablen subTitle (19,21) abgelegt. Die Ein-träge der Spalten mit Titel der Veranstaltung, Semester und Dozent werden der Variablen descszugewiesen (23-25). Der Titel ist dabei ein Hyperlink, der zu den Details der Veranstaltung führt.Die Methode endet mit der Rückgabe eines table-Elements.

In der zweiten Methode veranstaltungWaehlenAsHTML, die hier beispielhaft präsentiertwird, erfolgt ein Aufruf der Methode veranstaltungenAsTable.

1 p r i v a t e c e n t e r veranstal tungWaehlenAsHTML ( ) {2 L i s t c o u r s e s ;3 c e n t e r t a b ;4

5 t r y {6 c o u r s e s = V e r a n s t a l t u n g . a l l e V e r a n s t a l t u n g e n ( f a l s e ) ;7 t a b = < c e n t e r >{ v e r a n s t a l t u n g e n A s T a b l e ( c o u r s e s ) } </

c e n t e r > ;8 } / / t r y9 ca tch ( SQLExcept ion e ) {

10 t a b = < c e n t e r > F e h l e r : { e} </ c e n t e r > ;11 } / / c a t c h

12

13 re turn14 < c e n t e r >15 < f o n t s i z e =" +2 "> B i t t e V e r a n s t a l t u n g wählen : < / f o n t >16 { t a b }17 18 <form a c t i o n =" v e r w a l t u n g s s e r v l e t " method="POST">19 20 21 </ form >22 <form a c t i o n =" v e r w a l t u n g s s e r v l e t " method="POST">23 24 25 </ form >26 27 <form a c t i o n =" v e r w a l t u n g s s e r v l e t " method="POST">28 29 30 </ form >31 </ c e n t e r > ;32 } / / verans ta l tungWaehlenAsHTML

Sie dient dazu den Teil einer Seite zu erstellen, der sämtliche noch nicht beendete Veranstaltun-gen auflistet. Es entspricht dem Hauptmenü der Anwendung, von dem aus in alle wichtigen Teileverzweigt werden kann. Der Variablen courses werden alle Veranstaltungen zugewiesen (6),die noch nicht beendet sind. Anschließend werden diese in eine XHTML-Tabelle umformatiertund der XML-Objekt-Variablen tab zugewiesen (7). Tritt dabei eine Ausnahme auf, wird dieVariable tab auf deren Fehlermeldung gesetzt (9-11). Anschließend wird die Tabelle mit dreiweiteren Menüpunkten zurückgegeben (13-31). Mit einem Punkt ist es möglich auch beendeteVeranstaltungen einzusehen (18-21), ein weiterer dient zum Anlegen von neuen Veranstaltun-gen (22-25) und der dritte Punkt verzweigt zur Administration der Anwendung (27-30). Dortkönnen u. a. Daten auf externen Datenträgern archiviert werden.

Kapitel 7

Zusammenfassung und Ausblick

In dieser Arbeit wurde die Erweiterung XML-Objekte (XOBE) der objektorientierten Program-miersprache Java vorgestellt, die eine Programmierung mit XML-Strukturen ermöglicht. Durchdie Deklaration der Sprachbeschreibung einer Auszeichnungssprache im XOBE-Programm kön-nen die in der Sprachbeschreibung deklarierten Elementtypen wie in Java eingebaute Klas-sen eingesetzt werden. Mit dieser Bekanntmachung der verwendeten Auszeichnungssprache imQuelltext der Anwendung kann zur Zeit der Programmübersetzung weitestgehend sichergestelltwerden, dass die dynamisch generierten XML-Strukturen gültig sind. Die Ausdruckskraft vonJava wird dadurch nicht beeinträchtigt. Die bisherigen Spracherweiterungen von Java, die fürdie Programmierung von Web-Anwendungen definiert wurden, können diese Eigenschaft nichtgarantieren.

In XOBE können alle durch Deklaration der Auszeichnungssprache bekannt gemachten XML-Typen als Klassen verwendet werden. Damit ist es möglich, durch spezielle Konstruktoren, die inXML-Syntax angegeben werden, XML-Objekte zu erzeugen, die wie ganz normale Java-Objekteim Programm eingesetzt werden können. Ein Zugriff auf den Inhalt von XML-Objekten wurdedurch den Sprachstandard XPath ermöglicht.

Eine Formalisierung des Typsystems in XOBE wurde durch Heckensprachen mit den dazugehö-rigen Heckengrammatiken vorgenommen. Darauf aufbauend wurde ein Algorithmus zur Über-prüfung der Subtyp-Beziehung zweier allgemeiner regulärer Heckenausdrücke vorgestellt unddessen Korrektheit bewiesen. Weiterhin wurde gezeigt, wie eine Erweiterung des Algorithmuserfolgen kann, um die zusätzlichen Möglichkeiten des Typsystems in XML-Schema zu berück-sichtigen. Da allgemeine Heckengrammatiken ausdrucksstärker sind als Sprachbeschreibungenvon Auszeichnungsspachen, vereinfacht sich für XML der Suptyp-Algorithmus in der Ausfüh-rung, wie in Abschnitt 4.8.2 gezeigt, was mit einer erheblichen Effizienzsteigerung verbundenist.

Bei der Transformation von XOBE-Programmen in reines Java werden die XML-Objekte in eineJava-Implementierung übersetzt. In dieser Arbeit wurde für diesen Zweck der Programmier-

168 KAPITEL 7. ZUSAMMENFASSUNG UND AUSBLICK

standard DOM gewählt. Die Selektionen von XML-Objekt-Inhalten durch Ausdrücke in XPathwerden ebenfalls in Programmteile umgesetzt, die auf der DOM-Repräsentation beruhen.

Durch die Realisierung zweier Web-Anwendungen mit Hilfe der vorgestellten Java-ErweiterungXOBE wurde evaluiert, dass der Einsatz in der Programmierung problemlos möglich und sinn-voll ist. Dabei zeigte sich, dass die geringe Effizienzeinbuße, die durch die aufwendigere DOM-Implementierung entsteht, in der Praxis tolerierbar ist.

Die zu Beginn gesteckten Ziele aus Abschnitt 1.2 sind wie folgt erreicht worden:

1. Integration von XML-Strukturen in das objektorientierte Klassenkonzept:

XOBE erweitert die Programmiersprache durch die Integration von XML-Strukturen. Da-bei werden die Sprachbeschreibungen von Auszeichnungssprachen wie Klassendefinitio-nen interpretiert und stehen implizit zur Verfügung. Damit konnte das erste Ziel voll erfülltwerden.

2. Komfortable Zugriffsmöglichkeiten auf Inhalte dieser XML-Strukturen:

Durch die Integration der Sprache für Pfadausdrücke XPath in XOBE ist es möglich aufden Inhalt von XML-Objekte zuzugreifen. Die Selektion erfolgt damit über einen weitverbreiteten und akzeptierten Standard in XML.

3. Weitestgehende Garantie der Gültigkeit der generierten Strukturen bereits zur Zeit der Pro-grammübersetzung:

Durch das auf XML-Objekte zugeschnittene Typsystem in XOBE kann die geforderteweitestgehende Garantie der Gültigkeit für die im XOBE-Programm verarbeiteten XML-Strukturen sichergestellt werden. Damit ist es für eine in Java implementierte Web-An-wendung erstmals möglich, auf einen Großteil der aufwendigen Testläufe zu verzichten.

Die bei der Einordnung der Arbeit (Abschnitt 2.7) dargestellte Situation, dass nach heutigemStand viele Web-Anwendungen mit Techniken implementiert werden, durch die die Korrektheitder erzeugten XML-Fragmente gar nicht oder nur in geringem Maße sichergestellt werden, kannmit der Java-Erweiterung XOBE erheblich verbessert werden. Gerade für die Programmierungvon Web-Anwendungen lässt sich XOBE gut einsetzen.

Auch wenn die zuvor genannten Ziele erreicht wurden, ergibt sich eine Fülle von weiteren Aufga-ben und Erweiterungsmöglichkeiten, die im Folgenden angesprochen werden. Die bereits in denKapiteln zum Typsystem (4.8) und der Implementierung (5.4) diskutierten Vor- und Nachteileoder möglichen Ergänzungen bzw. Änderungen werden hier bis auf eine wesentliche Ausnahmenicht noch einmal aufgeführt.

169

Zukünftige Arbeiten

Erweiterung des Objektmodells um Textknoten

Es kann sinnvoll sein, das XOBE zu Grunde liegende Objektmodell so zu erweitern, so dass(ähnlich dem DOM) Instanzen einer eigenen Textklasse den textuellen Inhalt von Elementenrepräsentieren. Damit wird es möglich, Änderungsoperationen, die sich auf den textuellen Inhaltbeziehen, direkt auf diesen Textknoten durchzuführen. Im aktuellen Objektmodell, in dem keinespeziellen Textobjekte existieren, wird textueller Inhalt durch Zeichenketten dargestellt. Dadurchhaben solche Änderungen stets über den Elternknoten, also den beinhaltenden Elementknoten,zu geschehen.

Manipulation von XML-Objekten

Zur Zeit ist in XOBE noch keine direkte Manipulation von XML-Fragmenten vorgesehen. Bisherkönnen nur Elemente, Attribute und Inhalte aus einem XML-Objekt mittels XPath selektiert undzu neuen XML-Objekten durch Konstruktoren zusammengefügt werden. Eine Erweiterung vonXOBE könnte also durch neue Sprachkonstrukte erfolgen, die die Änderung von Daten im XML-Objekt oder das Löschen von Elementen, Attributen oder Inhalten erlauben. Diese Sprachkon-strukte sollten sinnvollerweise so konstruiert sein, dass weiterhin eine Überprüfung der statischenGültigkeit zum Zeitpunkt der Programmübersetzung möglich ist.

Basisdatentypen in XML-Schema

Eine weitere zukünftige Untersuchungsmöglichkeit existiert mit den Basisdatentypen in XML-Schema, für die zu betrachten ist, in welcher Form sie in XOBE integriert werden können. Deraktuelle Prototyp unterstützt lediglich die beiden Datentypen integer und string, was dieMöglichkeiten von XML-Schema stark vereinfacht. Problematisch wird die Verknüpfung vonBasisdatentypen mit XOBE, weil unterschiedliche Typen sich in ihrer Darstellung als Zeichen-kette stark überschneiden. So kann beispielsweise die Zeichenkette 11 als integer, als po-sitiveInteger, als float oder sogar als string interpretiert werden.

Erweiterung von XPath um strukturorientierte Selektion

Wie in Abschnitt 5.4 bereits angesprochen wurde, erfolgt die Selektion von Elementen, Attribu-ten und Inhalten in XOBE zur Zeit ausschließlich durch XPath. XPath selbst formuliert Zugriffeauf XML-Objekte ohne Kenntnis der Sprachbeschreibung. Da in XOBE aber stets eine Sprach-beschreibung vorliegt, wäre auch eine Selektion denkbar, die sich an der deklarierten Sprachbe-schreibung orientiert. Beispielsweise sollte für ein Inhaltsmodell der Form (book*,record,

170 KAPITEL 7. ZUSAMMENFASSUNG UND AUSBLICK

book*,record,book*) eine direkte Selektion der zweiten book-Liste möglich sein. InXPath ist ein solcher Zugriff nur sehr umständlich ausdrückbar (child::book[preceding-sibling::record and following-sibling::record]).

Andere Implementierung als DOM

Eng verbunden mit strukturorientierten Selektionsmöglichkeiten ist die Frage nach einer effizi-enteren Implementierung der XML-Objekte. Denkbar wäre hier eine ebenfalls an der Strukturder XML-Objekt-Klassen orientierte Repräsentation. Verbindet man diese Darstellung mit derbereits angesprochenen strukturorientierten Selektion, lassen sich bestimmte Selektionsoperatio-nen, wie der Zugriff auf die zweite book-Liste im vorherigen Beispiel mit konstantem Aufwandausführen. Die aktuelle DOM-Implementierung benötigt dafür in der Abhängigkeit zur Knoten-liste linear viele Zugriffe.

Persistenz von XML-Objekten

Zuletzt wäre es sicherlich wünschenswert, XML-Objekte persistent ablegen zu können, wofüreine Verbindung der Programmiersprache XOBE mit einem Datenbanksystem notwendig wäre.Mit weiteren Sprachkonstrukten wäre dann eine Erweiterung zu einer eigenständigen Datenbank-programmiersprache möglich, in der sich vollwertige Datenbankanwendungen implementierenließen. Gerade im Hinblick auf Web-Anwendungen, die mehr und mehr mit Datenbanken ver-bunden werden, erscheint eine solche Zielsetzung zweckmäßig

Anhang A

XML-Schema AOML

Dieser Anhang präsentiert die Auszeichnungssprache des Beispiels 2.2 dieser Arbeit in Formeines XML-Schemas.

1 <schema xmlns=" h t t p : / /www. w3 . o rg / 2 0 0 1 / XMLSchema� i n s t a n c e ">

2 < e l e m e n t name=" aoml ">3 <complexType >4 <sequence >5 < e l e m e n t name=" a n t i q u a r y " t y p e =" t _ a n t i q u a r y " / >6 < e l e m e n t name=" o f f e r " t y p e =" t _ o f f e r " / >7 </ sequence >8 < a t t r i b u t e name=" d a t e " t y p e =" s t r i n g " / >9 </ complexType >

10 </ e lement >11

12 <complexType name=" t _ a n t i q u a r y ">13 < sequence >14 < e l e m e n t name=" name " t y p e =" s t r i n g " / >15 < e l e m e n t name=" a d d r e s s " t y p e =" s t r i n g " / >16 < e l e m e n t name=" e m a i l " t y p e =" s t r i n g " / >17 </ sequence >18 </ complexType >19

20 <complexType name=" t _ o f f e r ">21 < c h o i c e maxOccurs =" unbounded ">22 < e l e m e n t name=" book " t y p e =" t_book " / >23 < e l e m e n t name=" r e c o r d " t y p e =" t _ r e c o r d " / >24 </ cho ice >25 </ complexType >

172 ANHANG A. XML-SCHEMA AOML

26

27 <complexType name=" t_book ">28 < sequence >29 < e l e m e n t name=" t i t l e " t y p e =" s t r i n g " / >30 < e l e m e n t name=" a u t h o r " t y p e =" s t r i n g " minOccurs=" 0 "

/ >31 <group r e f =" f i e l d " / >32 </ sequence >33 < a t t r i b u t e name=" c a t a l o g " t y p e =" s t r i n g " / >34 </ complexType >35

36 <complexType name=" t _ r e c o r d ">37 < sequence >38 < e l e m e n t name=" t i t l e " t y p e =" s t r i n g " / >39 < e l e m e n t name=" a r t i s t " t y p e =" s t r i n g " / >40 <group r e f =" f i e l d " / >41 </ sequence >42 </ complexType >43

44 <group name=" f i e l d ">45 < sequence >46 < e l e m e n t name=" a r t i c l e " t y p e =" i n t e g e r " / >47 < e l e m e n t name=" c o n d i t i o n " t y p e =" s t r i n g " / >48 < e l e m e n t name=" p r i c e " t y p e =" t _ p r i c e " / >49 </ sequence >50 </ group >51

52 <complexType name=" t _ p r i c e ">53 < s i m p l e C o n t e n t >54 < e x t e n s i o n base =" s t r i n g ">55 < a t t r i b u t e name=" c u r r e n c y " t y p e =" s t r i n g " use ="

r e q u i r e d " / >56 </ e x t e n s i o n >57 </ s i m p l e C o n t e n t >58 </ complexType >59 </ schema >

Listing A.1: Schemadefinition AOML

Anhang B

Beweis von Satz 4.2

Um den Satz 4.2 aus Abschnitt 4.6 zu beweisen, was in diesem Anhang geschieht, wird zunächstder folgende Hilfssatz gezeigt. Dabei sei

�die umfassende Menge.

Hilfssatz B.1 (Teilmengenbeziehung des Karthesischen Produkts)Gegeben seien die Mengen

�, � , � und

�, dann gilt:

� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �Beweis:

" � " Hinrichtung: Indirekter Beweis

Angenommen es gilt:

� � � � ��

" � " Rückrichtung: Direkter Beweis mit Fallunterscheidung

1. Fall: Angenommen es gilt:

� � � � � � � � � � � � � � � � � � � � � � � � � � � �

2. Fall: Angenommen es gilt:

� � � � � � � � � � � � � � � � � � � � � � � � � � � �

�

174 ANHANG B. BEWEIS VON SATZ 4.2

Es folgt der Beweis von Satz 4.2.

Satz 4.2 (Teilmengenbeziehung des Karthesischen Produkts)Gegeben seien die Mengen

�, � , � � , . . . ,

�

� und�� , . . . ,

�� , dann gilt:

� � � � � � � � ��

� �

� � � � � � � � � � � � � � � � � � � �� mit � � � � � �� und

� � � � � � �� .

Direkter Beweis:Angenommen es gilt �� , dann folgt:

� � � � � � � � � � � ��

� � � � � � � � � � � � � ��

� � ��

� � � � ��

� ��

� � � � � ��

Anhang C

Formalisierung DTD

In Abschnitt 4.3 wird eine Formalisierung für Sprachbeschreibungen, die als XML-Schema vor-liegen, angegeben. In diesem Anhang wird eine analoge Formalisierung einer DTD als Hecken-grammatik festgelegt. Sie beginnt mit den Regeln für die Ausdrucksrelation.

Definition C.1 (Formalisierung mittels Ausdrucksrelation)Die Ausdrucksrelation � � für DTDs ist durch folgende Regeln definiert:

#PCDATA � � � � � � � (STR1)

CDATA � � � � � � � (STR2)

� � � �(IDENT)

EMPTY � � � (EMPTY)

� � � � � � � �...

� � � � � � ��

� � � � � � � � �� (SEQ)

� � � � � � � �...

� � � � � � ��

� � � � � � � � � � �� (CHOICE)

176 ANHANG C. FORMALISIERUNG DTD

� � � � ��

(KLEENE1)

� � � � ��

(KLEENE2)

� � � � �� (OPT)

� � ��

� � � #REQUIRED� � � @

� � � � (REQ)

� � ��

� � � #IMPLIED� � � @

� � � � � � (IMP)

� � ��

� � � #FIXED� � � � (FIX)

� � � � � � � �...� � � � � � �� (ATTR)

mit�� , � �� , @

�� und �

�� Reg. �

Hinzu kommen die Regeln der Produktionenrelation.

Definition C.2 (Formalisierung mittels Produktionenrelation)Die Produktionenrelation �� einer DTD ist durch folgende Regeln definiert:

� � � � ��

<!ENTITY % �"� � " > �� (ENTITY)

� � ��

��

<!ELEMENT � � � ><!ATTRLIST � � � >

�� (ELEM)

� � � � �� mit � , � � und � � �

...� �� mit �� , � � und � �

<!DOCTYPE � � ��

� �� > �� mit � � � � (DTD)

mit�� ,

�� ,

�� und �

��

��

�� Reg. �

Anhang D

Implementierung der XPath-Achsen

Dieser Anhang zeigt die Implementierung der restlichen Achsen aus Abschnitt 5.3, in der schondie Methode für die Kind-Achse gezeigt wurde. Die von XPath geforderte Ordnung der Knotenist nicht implementiert, auch können Knoten in der Ergebnisliste mehrfach auftreten.

Die Nachfahr-Achse wird durch die Methode getDescendantNodes realisiert.

1 p u b l i c XobeNodeList ge tDescendan tNodes ( S t r i n g t e s t ) {2 XobeNodeList c h i l d r e n , r e s u l t ;3

4 / / a l l e Kinder , K i n d e s k i n d e r usw . des K o n t e x t k n o t e n s5 r e s u l t = new XobeNodeLis t Impl ( ) ;6 c h i l d r e n = g e t C h i l d N o d e s ( t e s t ) ;7 i f ( c h i l d r e n . g e t L e n g t h ( ) = = 0 )8 re turn r e s u l t ;9 e l s e {

10 r e s u l t . addAl l ( c h i l d r e n . ge tDescendan tNodes ( t e s t ) ) ;11 r e s u l t . addAl l ( c h i l d r e n ) ;12 } / / e l s e13 re turn r e s u l t ;14 } / / ge tDescendan tNodes

Die Eltern-Achse wird durch die zwei Methoden getParentNodes und getParentNodeimplementiert.

1 p u b l i c XobeNodeList g e t P a r e n t N o d e s ( S t r i n g t e s t ) {2 i n t i ;3 XobeNodeList r e s u l t ;4

5 / / E l t e r des Kon tex t � Knotens6 r e s u l t = new XobeNodeLis t Impl ( ) ;

178 ANHANG D. IMPLEMENTIERUNG DER XPATH-ACHSEN

7 f o r ( i = 0 ; i < g e t L e n g t h ( ) ; i = i + 1 )8 r e s u l t . addAl l ( g e t P a r e n t N o d e ( t e s t , i t em ( i ) ) ) ;9 re turn r e s u l t ;

10 } / / g e t P a r e n t N o d e s

11 p r i v a t e s t a t i c NodeLis t g e t P a r e n t N o d e ( S t r i n g t e s t , Nodenode ) {

12 Node p a r e n t ;13 XobeNodeList r e s u l t ;14

15 r e s u l t = new XobeNodeLis t Impl ( ) ;16 p a r e n t = node . g e t P a r e n t N o d e ( ) ;17 i f ( p a r e n t ! = n u l l && n o d e T e s t ( t e s t , p a r e n t ) )18 r e s u l t . add ( p a r e n t ) ;19 re turn r e s u l t ;20 } / / ge tParen tNode

Die Vorfahr-Achse wird durch die Methode getAncestorNodes realisiert.

1 p u b l i c XobeNodeList g e t A n c e s t o r N o d e s ( S t r i n g t e s t ) {2 XobeNodeList p a r e n t s , r e s u l t ;3

4 / / a l l e E l t e r n , G r o s s s e l t e r n usw .5 r e s u l t = new XobeNodeLis t Impl ( ) ;6 p a r e n t s = g e t P a r e n t N o d e s ( t e s t ) ;7 i f ( p a r e n t s . g e t L e n g t h ( ) = = 0 )8 re turn r e s u l t ;9 e l s e {

10 r e s u l t . addAl l ( p a r e n t s . g e t A n c e s t o r N o d e s ( t e s t ) ) ;11 r e s u l t . addAl l ( p a r e n t s ) ;12 } / / e l s e13 re turn r e s u l t ;14 } / / g e t A n c e s t o r N o d e s

Die Nachfolgende-Geschwister-Achse wird durch die zwei Methoden getFollowingSib-lingNodes implementiert.

1 p u b l i c XobeNodeList g e t F o l l o w i n g S i b l i n g N o d e s ( S t r i n gt e s t ) {

2 i n t i ;3 XobeNodeList r e s u l t ;4

5 / / a l l e n a c h f o l g e n d e n G e s c h w i s t e r6 r e s u l t = new XobeNodeLis t Impl ( ) ;

179

7 f o r ( i = 0 ; i < g e t L e n g t h ( ) ; i = i + 1 )8 r e s u l t . addAl l ( g e t F o l l o w i n g S i b l i n g N o d e s ( t e s t , i t em ( i )

) ) ;9 re turn r e s u l t ;

10 } / / g e t F o l l o w i n g S i b l i n g N o d e s

11 p u b l i c XobeNodeList g e t F o l l o w i n g S i b l i n g N o d e s ( S t r i n gt e s t , Node node ) {

12 Node s i b l i n g ;13 XobeNodeList r e s u l t ;14

15 r e s u l t = new XobeNodeLis t Impl ( ) ;16 s i b l i n g = node . g e t N e x t S i b l i n g ( ) ;17 i f ( s i b l i n g = = n u l l )18 re turn r e s u l t ;19 e l s e {20 r e s u l t . addAl l ( g e t F o l l o w i n g S i b l i n g N o d e s ( t e s t , s i b l i n g

) ) ;21 i f ( n o d e T e s t ( t e s t , s i b l i n g ) )22 r e s u l t . add ( s i b l i n g ) ;23 } / / e l s e24 re turn r e s u l t ;25 } / / g e t F o l l o w i n g S i b l i n g N o d e s

Die Vorherige-Geschwister-Achse wird durch die zwei Methoden getPrecedingSiblin-gNodes realisiert.

1 p u b l i c XobeNodeList g e t P r e c e d i n g S i b l i n g N o d e s ( S t r i n gt e s t ) {

2 i n t i ;3 XobeNodeList r e s u l t ;4

5 / / a l l e v o r h e r i g e n G e s c h w i s t e r6 r e s u l t = new XobeNodeLis t Impl ( ) ;7 f o r ( i = 0 ; i < g e t L e n g t h ( ) ; i = i + 1 )8 r e s u l t . addAl l ( g e t P r e c e d i n g S i b l i n g N o d e s ( t e s t , i t em ( i )

) ) ;9 re turn r e s u l t ;

10 } / / g e t P r e c e d i n g S i b l i n g N o d e s

11 p u b l i c XobeNodeList g e t P r e c e d i n g S i b l i n g N o d e s ( S t r i n gt e s t , Node node ) {

12 Node s i b l i n g ;13 XobeNodeList r e s u l t ;

14

15 r e s u l t = new XobeNodeLis t Impl ( ) ;16 s i b l i n g = node . g e t P r e v i o u s S i b l i n g ( ) ;17 i f ( s i b l i n g = = n u l l )18 re turn r e s u l t ;19 e l s e {20 r e s u l t . addAl l ( g e t P r e c e d i n g S i b l i n g N o d e s ( t e s t , s i b l i n g

) ) ;21 i f ( n o d e T e s t ( t e s t , s i b l i n g ) )22 r e s u l t . add ( s i b l i n g ) ;23 } / / e l s e24 re turn r e s u l t ;25 } / / g e t P r e c e d i n g S i b l i n g N o d e s

Die Nachfolger-Achse wird durch die Methode getFollowingNodes implementiert.

1 p u b l i c XobeNodeList g e t F o l l o w i n g N o d e s ( S t r i n g t e s t ) {2 / / a l l e F o l l o w i n g S i b l i n g s der A n c e s t o r s und deren

Descendan t s3 re turn g e t A n c e s t o r N o d e s ( " � " ) . g e t F o l l o w i n g S i b l i n g N o d e s

( " � " ) .4 g e t D e s c e n d a n t O r S e l f N o d e s ( t e s t ) ;5 } / / g e t F o l l o w i n g N o d e s

Die Vorgänger-Achse wird durch die Methode getPrecedingNodes realisiert.

1 p u b l i c XobeNodeList g e t P r e c e d i n g N o d e s ( S t r i n g t e s t ) {2 / / a l l e P r e c e d i n g S i b l i n g s der A n c e s t o r s und deren

Descendan t s3 re turn g e t A n c e s t o r N o d e s ( " � " ) . g e t P r e c e d i n g S i b l i n g N o d e s

( " � " ) . g e t D e s c e n d a n t O r S e l f N o d e s ( t e s t ) ;4 } / / g e t P r e c e d i n g N o d e s

Die Attribut-Achse wird durch die Methode getAttributeNodes implementiert.

1 p u b l i c XobeNodeList g e t A t t r i b u t e N o d e s ( S t r i n g t e s t ) {2 i n t i , j ;3 NamedNodeMap a t t r i b u t e s ;4 XobeNodeList r e s u l t ;5

6 / / a l l e A t t r i b u t e7 r e s u l t = new XobeNodeLis t Impl ( ) ;8 f o r ( i = 0 ; i < g e t L e n g t h ( ) ; i = i + 1 ) {9 a t t r i b u t e s = i t em ( i ) . g e t A t t r i b u t e s ( ) ;

181

10 f o r ( j = 0 ; j < a t t r i b u t e s . g e t L e n g t h ( ) ; j = j + 1 ){

11 i f ( n o d e T e s t ( t e s t , a t t r i b u t e s . i t em ( j ) ) )12 r e s u l t . add ( a t t r i b u t e s . i t em ( j ) ) ;13 } / / f o r14 } / / f o r15 re turn r e s u l t ;16 } / / g e t A t t r i b u t e N o d e s

Die Selbst-Achse wird durch die Methode getSelfNodes realisiert.

1 p u b l i c XobeNodeList g e t S e l f N o d e s ( S t r i n g t e s t ) {2 i n t i ;3 XobeNodeList r e s u l t ;4

5 r e s u l t = new XobeNodeLis t Impl ( ) ;6 f o r ( i = 0 ; i < g e t L e n g t h ( ) ; i = i + 1 ) {7 i f ( n o d e T e s t ( t e s t , i t em ( i ) ) )8 r e s u l t . add ( i t em ( i ) ) ;9 } / / f o r

10 re turn r e s u l t ;11 } / / g e t S e l f N o d e s

Die Vorfahr-oder-Selbst-Achse wird durch die Methode getAncestorOrSelfNodes imple-mentiert.

1 p u b l i c XobeNodeList g e t A n c e s t o r O r S e l f N o d e s ( S t r i n g t e s t ){

2 XobeNodeList r e s u l t ;3

4 / / a l l e E l t e r n , G r o s s s e l t e r n usw . und denK o n t e x t k n o t e n

5 r e s u l t = new XobeNodeLis t Impl ( ) ;6 r e s u l t . addAl l ( g e t A n c e s t o r N o d e s ( t e s t ) ) ;7 r e s u l t . addAl l ( g e t S e l f N o d e s ( t e s t ) ) ;8 re turn r e s u l t ;9 } / / g e t A n c e s t o r O r S e l f N o d e s

Die Nachfahr-oder-Selbst-Achse wird durch die Methode getDescendantOrSelfNodesrealisiert.

1 p u b l i c XobeNodeList g e t D e s c e n d a n t O r S e l f N o d e s ( S t r i n gt e s t ) {

2 XobeNodeList r e s u l t ;3


4 / / a l l e Kinder , K i n d e s k i n d e r , usw . des K o n t e x t k n o t e n sund den K o n t e x t k n o t e n

5 r e s u l t = new XobeNodeLis t Impl ( ) ;6 r e s u l t . addAl l ( ge tDescendan tNodes ( t e s t ) ) ;7 r e s u l t . addAl l ( g e t S e l f N o d e s ( t e s t ) ) ;8 re turn r e s u l t ;9 } / / g e t D e s c e n d a n t O r S e l f N o d e s

Literaturverzeichnis

[ABS00] ABITEBOUL, SERGE, PETER BUNEMAN und DAN SUCIU: Data on the Web, FromRelations to Semistructured Data and XML. Morgan Kaufmann Publishers, SanFrancisco, California, 2000.

[AG98] ARNOLD, KEN und JAMES GOSLING: The Java Programming Language. The JavaSeries. Addison Wesley Longman, Inc., 2. Auflage, 1998.

[Ala97] ALAGIC, SUAD: The ODMG Object Model: Does it Make Sense? In: BERMAN,A. MICHAEL (Herausgeber): Proceedings of the ACM SIGPLAN Conference onObject-Oriented Programming Systems, Languages & Application (OOPSLA ’97),Band 32(10) der Reihe SIGPLAN Notices, Seiten 253–284. ACM Press, October1997.

[Ala99] ALAGIC, SUAD: O2 and the ODMG Standard: Do They Match? Theory and Practiceof Object Systems, 5(4):239–247, November 1999.

[AM91] AIKEN, ALEXANDER und BRIAN R. MURPHY: Implementing Regular Tree Expres-sions. In: HUGHES, JOHN (Herausgeber): Proceedings of Functional Programmingand Computer Architecture, Band 523 der Reihe Lecture Notes in Computer Science(LNCS), Seiten 427–447, Berlin Heidelberg New York, 1991. Springer-Verlag.

[Ant94] ANTIMIROV, VALENTIN: Rewriting Regular Inequalities. In: REICHEL (Heraus-geber): Fundamentals of Computation Theory, Band 965 der Reihe Lecture Notesin Computer Science (LNCS), Seiten 116–125, Berlin Heidelberg New York, 1994.Springer-Verlag.

[Apa00] APACHE SOFTWARE FOUNDATION, THE: Apache HTTP Server Version 1.3, ApacheAPI notes. http://httpd.apache.org/docs/misc/API.html, 2000.

[Apa01] APACHE XML PROJECT, THE: Xerces Java Parser. http://xml.apache.org/xerces-j/index.html, 15. November 2001. Version 1.4.4.

[Apa03] APACHE SOFTWARE FOUNDATION, THE: PHP. http://www.php.net/, 2003.

[ASU86] AHO, A.V., R. SETHI und J.D. ULLMAN: Compilers – Principles, Techniques andTools. Addison-Wesley Publishing Company, Inc., 1986.

184 LITERATURVERZEICHNIS

[BKMW01] BRÜGGEMANN-KLEIN, ANNE, MAKOTO MURATA und DERICK WOOD: RegularTree and Regular Hedge Languages over Unranked Alphabets: Version 1. Techni-scher Bericht HKUST-TCSC-2001-05, Hong Kong University of Science & Techno-logy, April 3 2001. Theoretical Computer Science Center.

[BKW98] BRÜGGEMANN-KLEIN, ANNE und DERICK WOOD: One-unambiguous regularlanguages. Information and Computation, Academic Press, 140(2):229–253, 1998.

[BL00] BEHRENS, RALF und VOLKER LINNEMANN: XML-basierte Informationsmodel-lierung am Beispiel eines Medienarchivs für die Lehre. Technischer Bericht A-00-20, Schriftenreihe der Institute für Informatik/Mathematik, Medizinische Uni-versität zu Lübeck, Dezember 2000. available at http://www.ifis.mu-luebeck.de/public, (in German).

[BLMM94] BERNERS-LEE, T., L. MASINTER und M. MCCAHILL: Uniform Resource Loca-tors (URL). Request for Comments: 1738, http://www.w3.org/Addressing/rfc1738.txt, December 1994. Network Working Group.

[BMS01] BRABRAND, CLAUS, ANDERS MOLLER und MICHAEL I. SCHWARTZBACH: Sta-tic Validation of Dynamically Generated HTML. In: Proceedings of Workshop onProgram Analysis for Software Tools and Engineering (PASTE 2001), June 18-19,Snowbird, Utah, USA, Seiten 38–45. ACM, 2001.

[Bor01] BORLAND: XML Application Developer’s Guide, JBuilder. Borland Software Cor-poration, Scotts Valley, CA, 1997,2001. Version 5.

[Bou02] BOURRET, RONALD: XML Data Binding Resources. web document, http://www.rpbourret.com/xml/XMLDataBinding.htm, 28. July 2002.

[Bra98] BRADLEY, NEIL: The XML Companion. Addison Wesley Longman Limited, Edin-burgh Gate, Harlow, Essex CM20 2JE, United Kingdom, 1998.

[BRJ99] BOOCH, GRADY, JAMES RUMBAUGH und IVAR JACOBSON: The Unified ModelingLanguage User Guide. Object Technology Series. Addison Wesley Longman, Inc.,1999.

[Bro96] BROWN, MARK R.: FastCGI Specification. Document Version: 1.0, http://www.fastcgi.com/devkit/doc/fcgi-spec.html, 29. April 1996. Open Market,Inc.

[BS86] BERRY, GERARD und RAVI SETHI: From regular expression to deterministic auto-mata. Theoretical Computer Science, Elsevier Science, 48(1):117–126, 1986.

[Car97] CARDELLI, LUCA: Type Systems. In: TUCKER, ALLEN B. (Herausgeber): The Com-puter Science and Engineering Handbook, Kapitel 103, Seiten 2208–2236. CRCPress, Boca Raton, FL, 1997.

LITERATURVERZEICHNIS 185

[CAR98] COAR, KEN A. L., THE APACHE GROUP und D. R. T. ROBINSON: The WWWCommon Gateway Interface – Version 1.1. Internet-Draft, http://CGI-Spec.Golux.Com/draft-coar-cgi-v11-00.html, 28. May 1998. Internet Enginee-ring Task Force (IETF).

[CDG�

97] COMON, HUBERT, MAX DAUCHET, RÉMI GILLERON, FLORENT JACQUEMARD,DENIS LUGIEZ, SOPHIE TISON und MARC TOMMASI: Tree Automata Techniquesand Applications. http://www.grappa.univ-lille3.fr/tata/, 1997.

[CMS02] CHRISTENSEN, ASKE SIMON, ANDERS MOLLER und MICHALE I. SCHWARTZ-BACH: Static analysis for dynamic XML. In: Informal Proceedings of the Work-shop on Programming Language Technologies for XML (PLAN-X), October 3-8, PLI2002, Pittsburgh, USA, Seiten 32–43, 2002.

[Cow01] COWARD, DANNY: Java Servlet Specification Version 2.3. http://www.jcp.

org/aboutJava/communityprocess/final/jsr053/, 17. September 2001.Sun Microsystems, Inc.

[Die00] DIESTEL, REINHARD: Graphentheorie. Springer-Verlag, Berlin Heidelberg NewYork, 2000.

[ECM99] ECMA STANDARDIZING INFORMATION AND COMMUNICATION SYSTEMS: EC-MAScript Language Specification. Standard ECMA-262 http://www.ecma-

international.org/publications/files/ecma-st/Ecma-262.pdf, De-cember 1999. 3. Edition.

[EHF01] ELLIS, JOHN, LINDA HO und MAYDENE FISHER: JDBC 3.0 Specification.http://java.sun.com/products/jdbc/download.html, October 2001. SunMicrosystems, Inc.

[Exo02] EXOLAB GROUP: Castor. ExoLab Group, http://castor.exolab.org/, 2002.

[FGK02] FLORESCU, DANIELA, ANDREAS GRÜNHAGEN und DONALD KOSSMANN: XL:An XML Programming Language for Web Service Specification and Composition.In: Proceedings of International World Wide Web Conference (WWW 2002), May7-11, Honolulu, Hawaii, USA, Seiten 65–76. ACM, 2002.

[FK00] FIELDS, DUANE K. und MARK A. KOLB: Web Development with Java Server Pa-ges, A practical guide for designing and building dynamic web services. ManningPublications Co., 32 Lafayette Place, Greenwich, CT 06830, 2000.

[Fly98] FLYNN, PETER: Understanding SGML and XML Tools, Practical programs forhandling structured text. Kluwer Academic Publishers, 101 Philip Drive, AssinippiPark, Norwell, Massachusets 02061, USA, 1998.


[Fre67] FREGE, GOTTLOB: Begriffsschrift, a formula language, modeled upon that of arith-metic, for pure thought (1879). In: VAN HEIJENOORT, JAN (Herausgeber): FromFrege to Gödel: A Source Book in Mathematical Logic, 1879-1931, Seiten 1–82,Cambridge, Massachusetts, 1967. Harvard University Press.

[Fre01] FREE SOFTWARE FOUNDATION: The GNU JAXP Project. http://www.gnu.

org/software/classpathx/jaxp/jaxp.html, 2001.

[Gai95] GAITHER, M.: Foundations of WWW-Programming with HTML and CGI. IDG-Books Worldwide Inc., Foster City, California, USA, 1995.

[GHJV95] GAMMA, ERICH, RICHARD HELM, RALPH JOHNSON und JOHN VLISSIDES: De-sign Patterns. Professional Computing Series. Addison-Wesley Publishing Compa-ny, Inc., 1995.

[GJS96] GOSLING, JAMES, BILL JOY und GUY STEELE: The Java Language Specification.The Java series. Addison Wesley Longman, Inc., 2550 Gracia Avenue, MountainView, California 94043-1100 USA, 1996.

[GJSB00] GOSLING, JAMES, BILL JOY, GUY STEELE und GILAD BRACHA: The Java Lan-guage Specification. The Java series. Addison Wesley Longman, Inc., 901 San An-tonio Road, Mountain View, California 94303 USA, 2. Auflage, 2000.

[GKP02] GOTTLOB, GEORG, CHRISTOPH KOCH und REINHARD PICHLER: Efficient Algo-rithms for Processing XPath Queries. In: Proceedings of the 28th VLDB Conference,Hong Kong, China, Seiten 95–106, 2002.

[Gol90] GOLDFARB, CHARLES F.: The SGML Handbook. Oxford University Press, WaltonStreet, Oxford OX2 6OP, 1990.

[GP00] GOLDFARB, CHARLES F. und PAUL PRESCOD: The XML Handbook. Prentice HallPTR, Upper Saddle River, NJ 07458, 2. Auflage, 2000.

[Gun96] GUNDAVARAM, SHISHIR: CGI-Programming on the World Wide Web. O’Reilly &Associates, Inc., 1996.

[Har02] HAROLD, ELLIOTTE RUSTY: Processing XML with Java. Addison-Wesley Publis-hing Company, Inc., 2002. http://cafeconleche.org/books/xmljava/.

[HC98] HUNTER, JASON und WILLIAM CRAWFORD: Java Servlet Programmierung.O’Reilly & Associates, Inc., 101 Morris Street, Sebastopol, CA 95472, 1. Auflage,October 1998.

[Hos00] HOSOYA, HARUO: Regular Expression Types for XML. Doktorarbeit, University ofTokyo, 2000.


[HU79] HOPCROFT, JOHN E. und JEFFREY D. ULLMAN: Introduction to automata, langua-ges and computations. Addison-Wesley Publishing Company, Inc., Reading, MA,1979.

[Hug99] HUGE, ANNE KATHRIN: Formalisierung Objektorientierter Datenbanken auf derGrundlage von ODMG. Doktorarbeit, Universität Bremen, Institute of Safe Systeme,Postfach 330440, 28334 Bremen, Juli 1999. Aachen, Shaker-Verlag, 2000.

[HVP00] HOSOYA, HARUO, JÉRÔME VOUILLON und BENJAMIN C. PIERCE: Regular Ex-pression Types for XML. In: Proceedings of the Fifth ACM SIGPLAN InternationalConference on Functional Programming (ICFP ’00), Montreal, Canada, Band 35(9)der Reihe SIGPLAN Notices, Seiten 11–22. ACM, September 18-21 2000.

[IBM03] IBM ALPHAWORKS: XML Parser for Java. http://alphaworks.ibm.com/

tech/xml4j, 2003.

[Inf97a] INFORMIX PRESS: Informix Web DataBlade Module Users’s Guide. Informix Soft-ware, Inc., 4100 Bohannon Drive, Menlo Park, CA 94025-1032, May 1997. Version3.3.

[Inf97b] INFORMIX SOFTWARE, INC., 4100 Bohannon Drive, Menlo Park, CA 94025: Get-ting Started with INFORMIX – Universal Server, March 1997. Version 9.1.

[Int94] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION: Open System Inter-connection Model. ISO: 1738, http://www.iso.org/, 1994.

[Int03] INTERNET SOFTWARE CONSORTIUM: Internet Domain Survey. http://www.

isc.org/ds/WWW-200301/index.html, January 2003.

[JDO] JDOM PROJECT: JDOM FAQ. http://www.jdom.org/docs/faq.html.

[KL02] KEMPA, MARTIN und VOLKER LINNEMANN: VDOM and P-XML – Towards AValid Programming Of XML-based Applications. Information and Software Techno-logy, Elsevier Science B. V., Seiten 229–236, 2002. Special Issue on Objects, XMLand Databases.

[Kra01] KRAMER, JENS-CHRISTIAN: Konzeption und Implementierung einer WAP-basierten Benutzerschnittstelle für das Medienarchiv MONTANA. Schriftenreihe derInstitute für Informatik/Mathematik B-01-03, Medizinische Universität zu Lübeck,Januar 2001.

[Kra02] KRAMER, JENS-CHRISTIAN: Erzeugung garantiert gültiger Server-Seiten für Do-kumente der Extensible Markup Language XML. Diplomarbeit, Institut für Informa-tionssysteme, Universität zu Lübeck, 2002. (in German).


[Kro95] KROL, ED: Die Welt des Internet. Handbuch & Übersicht. O’Reilly / InternationalThomson Verlag GmbH & Co KG, Königswinter Straße 418, 53 227 Bonn, 1. Auf-lage, 1995. (in German).

[KT01] KRUTWIG, MICHAEL und ROBERT TOLKSDORF: WML und WMLScript, Informa-tionen aufbereiten und präsentieren für WAP-Dienste. dpunkt-Verlag GmbH, 2001.

[LEW96] LOECKX, JACQUES, HANS-DIETER EHRICH und MARKUS WOLF: Specification ofAbstract Data Types. John Wiley & Sons Ltd., Chichester, England, 1996.

[Lin79] LINNEMANN, VOLKER: Sprachelemente zur Generierung und Umformung syntakti-scher Strukturen auf der Basis von ALGOL-68 und deren theoretische Untersuchung.Doktorarbeit, Universität Carolo-Wilhelmina zu Braunschweig, Deutschland, 1979.(in German).

[Lin81] LINNEMANN, VOLKER: Context-free Grammars and Derivation Trees in Algol 68.In: Proceedings International Conference on ALGOL68, Mathematical Centre Tracts134, Seiten 167–182. Math. Centrum Amsterdam, 1981.

[LK02] LINNEMANN, VOLKER und MARTIN KEMPA: Sprachen und Werkzeuge zur Gene-rierung von HTML- und XML-Dokumenten. Informatik Spektrum, Springer-VerlagHeidelberg, 25(5):349–358, 2002. (in German).

[LV96] LAUSEN, GEORG und GOTTFRIED VOSSEN: Objekt-orientierte Datenbanken: Mo-delle ud Sprachen. R. Oldenbourg Verlag GmbH, München, 1996. (in German).

[LZ74] LISKOV, BARBARA und STEPHEN ZILLES: Programming with abstract data types.ACM SIGPLAN Notices, ACM Press, 9(4):50–59, April 1974.

[Mat01] MATSUMOTO, YUKIHIRO: Programming Ruby, The Pragmatic Programmer’s Gui-de. Addison Wesley Longman, Inc., 2001. http://www.rubycentral.com/

book/.

[Mic01] MICROSOFT CORPORATION: .NET Framework Developer’s Guide. web document,http://msdn.microsoft.com/library/default.asp, 2001.

[Mit96] MITCHELL, JOHN C.: Foundations of Programming Languages. MIT Press, Cam-bridge, Massachusetts, 1996.

[Mur01] MURATA, MAKOTO: Extended Path Expressions for XML. In: Proceedings of theSymposium on Principles of Database Systems (PODS), May 21-23, Santa Barbara,California, USA, Seiten 126–137. ACM Press, 2001.

[Net97a] NETSCAPE COMMUNICATIONS CORPORATION: JavaScript 1.1 Language Specifi-cation. http://www.netscape.com/eng/javascript/index.html, 1997.


[Net97b] NETSCAPE COMMUNICATIONS CORPORATION: NSAPI Programmer’s Guide.http://developer.netscape.com/docs/manuals/enterprise/nsapi/,1997.

[Net03] NETCRAFT: Netcraft Web Server Survey. http://www.netcraft.com/Survey,May 2003.

[Neu99] NEUMANN, ADREAS: Parsing and Querying XML Documents in SML. Doktorar-beit, University of Trier, Trier, 1999.

[NNH99] NIELSON, FLEMMING, HANNE RIIS NIELSON und CHRIS L. HANKIN: Principlesof Program Analysis. Springer-Verlag, Berlin Heidelberg New York, 1999.

[Obj02] OBJECT MANAGMENT GROUP: Common Object Request Broker, CORBA, Archi-tecture: Core Specification. http://www.omg.org/technology/documents/

corba_spec_catalog.htm, December 2002. Version 3.

[Ora01] ORACLE CORPORATION: Oracle9i, Application Developer’s Guide – XML, Release1 (9.0.1). Redwood City, CA 94065, USA, June 2001. Shelley Higgins, Part NumberA88894-01.

[Ora02] ORACLE CORPORATION: XML Developer’s Kit for Java. http://otn.oracle.

com/tech/xml/xdkhome.html, 2002.

[Per90] PERRIN, D.: Finite Automata. In: LEEUWEN, J. VAN, A. MEYER, M. NIVAT,M. PATERSON und D. PERRIN (Herausgeber): Handbook of Theoretical Compu-ter Science, Band B, Seiten 1–57. Elsevier Science Publishers, Amsterdam; and MITPress, 1990. Chapter 1.

[PL01] PELEGRI-LLOPART, EDUARDO: JavaServer Pages Specification Version 1.2.http://www.jcp.org/aboutJava/communityprocess/final/jsr053/,17. September 2001. Sun Microsystems, Inc.

[PLC99] PELEGRÍ-LLOPART, EDUARDO und LARRY CABLE: Java Server Pages Specifica-tion, Version 1.1. Java Software, Sun Microsystems, http://java.sun.com/products/jsp/download.html, 30. November 1999.

[Pra65] PRAWITZ, DAG: Natural Deduction: A Proof-Theoretical Study. Almquist andWiksell, Stockholm, 1965.

[RBP�

91] RUMBAUGH, JAMES, MICHAEL BLAHA, WILLIAM PREMERLANI, FREDERICK

EDDY und WILLIAM LORENSEN: Object-oriented Modeling and Design. Prentice-Hall, Inc., 1991.

[RJB99] RUMBAUGH, JAMES, IVAR JACOBSON und GRADY BOOCH: The Unified ModelingLanguage Reference Manual. Object Technology Series. Addison Wesley Longman,Inc., 1999.


[RLHJ97] RAGGETT, DAVE, ARNAUD LE HORS und IAN JACOBS: HTML 4.0 Speci-fication. Recommendation, http://www.w3.org/TR/REC-html40-971218/,18. December 1997. W3Consortium.

[RS97] ROZENBERG, GRZEGORZ und ARTO SALOMAA (Herausgeber): Handbook of For-mal Languages, Band 3. Springer-Verlag, Berlin Heidelberg New York, 1997.

[Sal73] SALOMAA, A.: Formal Languages. Academic Press, 1973.

[SBK�

99] SHAW, PHIL, BRIAN BECKER, JOHANNES KLEIN, MARK HAPNER, GRAY

CLOSSMAN und RICHARD PLEDEREDER: SQLJ: Java and Relational Databases,Tutorial. http://www.sqlj.org/, 11. September 1999.

[Sei90] SEIDL, HELMUT: Deciding equivalence of finite tree automata. SIAM Journal ofComputing, 19(3):424–437, June 1990.

[Spi02] SPIEGLER, TORBEN: Entwicklung und Implementierung eines Datenbankschemaszur Verarbeitung von Übungs- und Vorlesungsdaten. Studienarbeit am Institut fürInformationssysteme der Universität zu Lübeck, Oktober 2002.

[Sun01a] SUN MICROSYSTEMS, INC.: Java 2 Platform, Standard Edition, v 1.3.1, API Speci-fication. http://java.sun.com/j2se/1.3/docs/api/index.html, Decem-ber 2001.

[Sun01b] SUN MICROSYSTEMS, INC: Java API for XML Processing (JAXP). http://

java.sun.com/xml/jaxp/, 2001.

[Sun03] SUN MICROSYSTEMS, INC: The Java Architecture for XML Binding (JAXB). Spe-cification, Version 1.0, http://www.sun.com, 8. January 2003. Editors: JosephFialli, Sekhar Vajjhala.

[Tak75] TAKEUTI, GAISI: Proof Theory, Band 81 der Reihe Studies in Logic and the Foun-dations of Mathematics. North-Holland Pub. Co., Amsterdam, 1975.

[Tan96] TANENBAUM, ANDREW S.: Computer Networks. Prentice-Hall International, Inc.,1996.

[Tol97a] TOLKSDORF, ROBERT: Die Sprache des Web: HTML 4. dpunkt, Verlag für digitaleTechnologie, Ringstraße 19, D – 69115 Heidelberg, 3. Auflage, 1997. (in German).

[Tol97b] TOLKSDORF, ROBERT: Internet, Aufbau und Dienste. Thomson’s Aktuelle Tutorien.International Thomson Publishing GmbH, 1. Auflage, 1997. (in German).

[Tur96] TURAU, VOLKER: Algorithmische Graphentheorie. Addison-Wesley PublishingCompany, Inc., 1996.

[TWP00] TAO, KEVIN, WANJUN WANG und DR. JENS PALSBERG: Java Tree Builder JTB.http://www.cs.purdue.edu/jtb/, 15. May 2000. Version 1.2.2.


[vdV02] VLIST, ERIC VAN DER: XML Schema. O’Reilly & Associates, Inc., 2002.

[W3C96] W3CONSORTIUM: Cascading Style Sheets, level 1. Recommendation, http://www.w3.org/TR/REC-CSS1, 17. December 1996.

[W3C98a] W3CONSORTIUM: Cascading Style Sheets, level 2, CSS2 Specification. Recommen-dation, http://www.w3.org/TR/REC-CSS2, 12. May 1998.

[W3C98b] W3CONSORTIUM: Document Object Model (DOM) Level 1 Specification, Versi-on 1.0. Recommendation, http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/, 1. October 1998.

[W3C98c] W3CONSORTIUM: Extensible Markup Language (XML) 1.0. Recommendation,http://www.w3.org/TR/1998/REC-xml-19980210/, 10. February 1998.

[W3C99a] W3CONSORTIUM: XML Path Language (XPath), Version 1.0. Recommendation,http://www.w3.org/TR/xpath, 16. November 1999.

[W3C99b] W3CONSORTIUM: XSL Transformations (XSLT) Version 1.0. Recommendation,http://www.w3.org/TR/xslt, 16. November 1999.

[W3C00a] W3CONSORTIUM: Document Object Model (DOM) Level 2 Core Specification,Version 1.0. Recommendation, http://www.w3.org/TR/DOM-Level-2-Core/,13. November 2000.

[W3C00b] W3CONSORTIUM: XHTML 1.0: The Extensible HyperText Markup Langua-ge, A Reformulation of HTML 4.0 in XML 1.0. Recommendation, http:

//www.w3.org/TR/2000/REC-xhtml1-20000126/, 26. January 2000.

[W3C01a] W3CONSORTIUM: XML Schema: Formal Description. Working Draft, http://www.w3.org/TR/2001/WD-xmlschema-formal-20010925/, 25. September2001.

[W3C01b] W3CONSORTIUM: XML Schema Part 0: Primer. Recommendation, http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/, 2. May 2001.

[W3C01c] W3CONSORTIUM: XML Schema Part 1: Structures. Recommendation, http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/, 2. May 2001.

[W3C01d] W3CONSORTIUM: XML Schema Part 2: Datatypes. Recommendation, http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/, 2. May 2001.

[W3C02a] W3CONSORTIUM: XML Path Language (XPath) 2.0. Working Draft, http:

//www.w3.org/TR/2002/WD-xpath20-20021115/, 15. November 2002.

[W3C02b] W3CONSORTIUM: XML Pointer Language (XPointer). Working Draft, http://www.w3.org/TR/xptr/, 16. August 2002.


[W3C02c] W3CONSORTIUM: XQuery 1.0: An XML Query Language. Working Draft,http://www.w3.org/TR/2002/WD-xquery-20021115/, 15. November 2002.

[Web02] WEBGAIN: Java Compiler Compiler (JavaCC) – The Java Parser Generator.http://www.webgain.com/products/java_cc/, 2002. Version 2.1.

[Wil99] WILLIAMSON, A. R.: Java Servlets by Example. Manning Publications Co., Green-wich, 1999.

[Wir00] WIRELESS APPLICATION PROTOCOL FORUM: Wireless Application Protocol, Wi-reless Makup Language Specification, Version 1.3. http://www1.wapforum.

org/tech/documents/WAP-191-WML-20000219-a.pdf, 19. February 2000.

[WPP�

83] WIRSING, M., H. PARTSCH, P. PEPPER, W. DOSCH und M. BROY: On Hierarchiesof Abstract Data Types. Acta Informatica, Springer-Verlag Heidelberg, 20:1–33,1983.

[WS92] WALL, L. und R. L. SCHWARTZ: Programming Perl. O’Reilly & Associates, Inc.,Sebastipol, California, 1992.

[Wut] WUTKA CONSULTING, INC.: DTDParser, A Java DTD Parser. A Product of WutkaConsulting, http://www.wutka.com/dtdparser.html.

Index

abstrakte Datentypen, 25Achse, 21Administration, 162Anforderung, 161anonyme Typen, 17Antiquary-Offer-Markup-Language, 15Anweisungsgleichung, 25, 25ArchivObject, 152Attribute, 10Attributklassen

spezielle, 61Attributtyp-Deklaration, 13Attributtypen, 11Auf-Wiedersehen-Meldung, 162Ausdrucksrelation, 84, 175Auszeichnungssprache, 13Axiom, 76

Baumautomaten mit Rangzahl, 75Baumsprachen, 77bedeutungsgleich, 130Bewachtheit, 80, 80Bezeichnertypisierung, 117Bindungsschemata, 53

cards, 150Common Gateway-Interface, 47

deck, 150Dienstprotokolle, 42Directory, 152Display archiv object, 153Display content, 153Display media objects, 153Display properties, 153Display query, 153

Display search result, 153Display subdirectories, 153DisplayableMedia, 153Dokument-Objektmodell, 7, 24, 52Dokumentordnung, 21, 62

umgekehrte, 22, 62Dokumenttyp-Definition, 13, 13Domain-Name-System, 42Dozent, 161

ECMA-Script, 46einfach, 16Einschränkung, 17Einseindeutigkeit, 124Elemente, 10Elementklassen

spezielle, 61Elementlisten, 65Elementnamen, 10Elementtyp-Deklaration, 13Elementtypen, 10

beliebige, 13Elternobjekt, 61Email, 42End-Tag, 10Enter search string, 153erweiterte Konkatenation

auf Mengen von Tupeln, 100erweiterte partielle Ableitung

einer regulären Ungleichung, 111eines regulären Ausdrucks, 110

Erweiterung, 17der Heckensprache, 110der Inkonsistenz, 110der Konkatenation, 111der partiellen Ableitung, 110, 111

194 INDEX

des Leere-Hecke-Prädikats, 110European Computer Manufacturers Associa-

tion, 46Extensible-Markup-Language, 2, 10

Formalisierungeiner Sprachbeschreibung, 83mittels Ausdrucksrelation, 84, 175mittels Produktionenrelation, 86, 176

ftp, 42führende Nichtterminalsymbole, 120, 120führende Terminalsymbole, 82, 82führende Terminalsymbole (BZT), 120, 120Funktion

mixed, 86occurs, 84ancestor, 95attribute, 93child, 93descendant, 94followingSibling, 96nodeTest, 92parent, 94precedingSibling, 98self, 92

Good bye message, 153Größe eines Heckenpräfixes, 109Gruppen

benannte, 17gültig, 14, 25

Hecke, 61, 77, 77Heckenautomaten, 75Heckenpräfixe einer Hecke, 109Heckensprache, 78

erweiterte, 110Hyperlinks, 43Hypertext-Markup-Language, 41Hypertext-Transfer-Protocol, 42

Inferenzregeln, 76Inhalt, 10Inhaltsmodell, 13

Inhaltsmodelledie für gleiche Elementnamen nur iden-

tische Elementtypen zulassen, 123einseindeutige, 125

inkonsistent, 82Inkonsistenz, 82

erweiterte, 110Internet Explorer, 43Internet-Protocol, 42Internet-Protokoll-Adressen, 41

Java Applets, 46Java Architecture for XMLBinding, 53Java Servlets, 48Java-DOM, 52Java-API, 46Java-Script, 46JavaServer-Pages, 3, 49Just-In-Time-Übersetzern, 46

Kinder, 61Kleene-Stern, 13Knotenmenge, 21Knotentest, 21Kommentar, 11Kommentarklasse, 62komplexe Typen, 16Konkatenation

auf Mengen von Tupeln, 100erweiterte, 111

Kontextknoten, 21Korrektheit, 115, 115

Laufzeitumgebung, 46leer, 13Leere-Hecke-Prädikat, 78, 78

erweitertes, 110Liste über XML-Objekte, 65, 65Login request, 153Login-Aufforderung, 162Lokalisierungsschritten, 21

MediaObject, 152, 153Menge

INDEX 195

aller Hecken, 77aller Hecken ohne die leere Hecke, 77aller Heckenpräfixe, 109, 109aller partiellen Ableitungen, 111, 111

MobileArchive, 149

Nerode-Kongruenz, 116Netscape Communicator, 43

Objektmodell, 61einfaches, 52

Objektmodellehöhere, 52

Optional, 13

Parameter-Entities, 13Parameterized-XML, 54partielle Ableitung, 101, 103, 120, 123, 125

eines regulären Ausdrucks, 101für reguläre Ungleichungen, 102hinsichtlich eines Nichtterminalsymbols,

120hinsichtlich eines Terminalsymbols (BZT),

120regulärer Ausdrücke, 100regulärer Ungleichungen, 103regulärer Ungleichungen (Simp1), 123regulärer Ungleichungen (Simp2), 125

Pattern-Matching, 54ping, 42Prädikaten, 21Produktionenrelation, 86, 176Produktionsrelation (BZT), 118, 118Programmiersprachen, 2

query, 153Query, 152, 153

Raum, 161reguläre Ausdruckstypen, 54, 82reguläre Baumausdrücke, 75reguläre Baumautomaten, 75reguläre Heckenausdrücke, 77, 77reguläre Heckengrammatik, 79, 79

reguläre Heckensprachen, 75, 77reguläre Konkatenation, 13reguläre Ungleichung, 82, 82reguläre Vereinigung, 13Request-For-Comments-Dokumente, 42result, 153

Schema-Übersetzer, 53Schemadeklaration, 62, 62Schlüsselattribut, 13Schlüsselreferenzen, 13Server-API, 48Server-Side Includes, 48Shop-Interchange-Format, 18Sitzungen, 49Spezialisierung, 64Sprache eines regulären Heckenausdrucks, 78Start-Tag, 10statische Gültigkeit, 15Strukturtypisierung, 118Studierender, 161, 162Style-Sheets, 39Subelement, 10Substitution, 121

führender Nichtterminalsymbole, 121Substitutionsgruppen, 18Subtyp-Algorithmus, 105

(BZT), 122, 122Subtyp-Urteile, 104

für reguläre Ungleichung, 104

Teilmengenbeziehung des Karthesischen Pro-dukts, 102, 173

telnet, 42Thread, 50Transfer-Control-Protocol, 42Transformation, 129

der elementaren XPath-Operationen in-nerhalb eines Prädikats, 142

der Vergleichsrelation, 141einer Attributliste, 132einer Inhaltsliste, 131einer Java-Variablen, 133

196 INDEX

einer Vergleichsrelation, 141einer XML-Objekt-Variablen, 132eines Attributs, 132eines Attributwertes, 132eines Knotentests, 137, 137eines leeren Elements, 131eines Lokalisierungsschritts, 137eines nicht leeren Elements, 131eines Prädikats, 141, 141eines Schritts, 137eines XPath-Ausdrucks, 136, 136eines XPath-Ausdrucks innerhalb eines

Prädikats, 141, 141elementarer XPath-Operationen, 142für ein Attribut, 132für ein leeres Element, 131für ein nicht leeres Element, 131für eine Attributliste, 132für eine Inhaltsliste, 131für eine Variable, 132, 133für einen konstanten Attributwert, 132für Zeichendaten, 132von Kommentar, 133, 133von Zeichendaten, 132

trivial inkonsistent, 82Typ

eines XML-Konstruktors, 90eines XPath-Ausdrucks, 98

Typanalyse, 129Typinferenz

eines XML-Konstruktors (BZT), 119, 119XML-Konstruktor, 90XPath-Ausdrücke, 98

Typisierungsurteil, 76für XML-Konstruktor, 89für XPath-Ausdrücke, 92

Typsubstitution, 18

Übung, 161, 162ÜDVSession, 161Uniform-Resource-Locator, 43

Validating-DOM, 53

Veranstaltung, 161, 162anlegen, 162auswählen, 162gewählt, 162

vollständig, 115Vollständigkeit, 116

Web-Anwendungen, 41, 45Wireless-Markup-Language, 144WMLSession, 152wohlgeformt, 11, 80, 81Wohlgeformtheit, 81

einer Heckengrammatik, 81eines regulären Ausdrucks, 81

World-Wide Web, 41

XML-Dokument, 11, 11XML-Dokument-Schablonen, 55XML-Objekt, 6XML-Objekt-Konstruktor, 64, 64XML-Objekte, 5, 7, 56, 59, 167XML-Objektklassen, 60XML-Schema-Definition-Language, 16XML-Variablendeklaration, 63, 63XOBE-Programmparser, 128XOBE-Schemaparser, 128XPath, 7XPath-Ausdruck, 20, 20, 66, 66XPath-Typ, 92

Zeichendaten, 10Zeichenkette

beliebige, 13Zeit, 161

Lebenslauf

Persönliche Daten: Sascha Martin Kempageboren am 13.9.1972 in Berlin

Schulausbildung: 1978 – 1981 31. Grundschule in Berlin – Reinickendorf1981 – 1984 Grundschule Evangelische Schule Frohnau1984 – 1991 Gymnasium Evangelische Schule Frohnau

mit Abitur1988 4-monatiger Schulbesuch an der

St. Augustin School in Oxford, England

Hochschulstudium: 10.1991 – 7.1993 Grundstudium der Informatik mitmit Wahlfach Mathematik an derTechnischen Universität Berlin

7.1993 – 2.1997 Hauptstudium der Informatik an derTechnischen Universität Berlin,Schwerpunkte: Programmiersprachenund theoretische Informatik

Praktikum: 7.1994 – 9.1994 Werkstudent bei der Firma Siemensim Bereich öffentliche Kommunikationsnetze

Zivildienst: 3.1997 – 3.1998 Krankenhaus Spandau, Berlin

Forschungund Lehre: 11.1993 – 3.1996 Tutor an der Technischen Universität Berlin

im Institut für Quantitative Methoden,Fachgebiet Statistik und Wirtschaftsmathematik,Betreuung der VeranstaltungMathematik für Wirtschaftswissenschaftler

ab 4.1998 wissenschaftlicher Mitarbeiter amInstitut für Informationssystemeder Universität zu Lübeck