Entwicklung eines XSD (extensibles Schema Definition) Generators

Pondorf, Denis

Entwicklung eines XSD (extensibles Schema Definition) Generators

Zusammenfassung

Inhaltsangabe:Einleitung:
Die Extensible Markup Language (XML) hat sich heute als standardisertes Serialisierungsformat und Transfersyntax auf breiter Front durchgesetzt. Jünger noch ist das XML-Schema, aber ebenso erfolgreich. Dementsprechend wächst die Anzahl an diese neuen Technologien verarbeitenden Applikation stetig. Da typischerweise ein Schema vorab bereits durch äquivalente Instanzen einer Anwendung beschrieben und das Schreiben von XMLSchemas keinesfalls trivial ist, drängt sich die Erfordernis eines Schema- Generators auf. Im Rahmen dieser Arbeit wird die Entwicklung eines Generators vorgestellt, der aus einer endlichen Menge von XML-Instanzen ein XML-Schema für jeden Zielnamensraum erzeugt. Das Ziel-Schema wird unter den mitunter interferierenden Prämissen Instanzvalidierung, Restriktivität, Erweiterbarkeit, Redundanzfreiheit und Lesbarkeit konstruiert. Es wird sowohl die methodische Konzeption vorgestellt, als auch eine Implementierung des XSD (Extensible Schema Definition) - Generators vorbereitet.
Abstract:
Today, the Extensible Markup Language (XML) is generally accepted as a standardized serialization format and transfer syntax. Although the XMLschema has been developed even more recently, it has become successful, too. Therefore, the number of applications processing these new technologies is constantly increasing. Since both a schema is typically described first by equivalent instances of an application and the writing of XML-schemas is not trivial in any way, the need for an XML-generator is compelling. This work introduces the development of a generator generating an XML-schema for any target namespace from a finite number of XML-instances. The targetschema is constructed under the sometimes interfering premises instance validation, restrictivity, extensibility, non-redundancy and readability. This work does not only present the methodological conception but also suggests an operable implementation of the XSD (Extensible Schema Definition) - generator.

Inhaltsverzeichnis:Inhaltsverzeichnis:
Erklärungiii
Kurzfassungviii
Abstractix
Vorwortx
Danksagungx
Konventionx
1Einleitung1
1.1Zielsetzung1
1.2Motivation3
1.3Relevanz4
1.4Organisation5
2Grundlagen7
2.1XML Instanz7
2.1.1Intention und Grundlage der Extensible Markup Language.8
2.1.2Rückblick12
2.1.3Spezifikation14
2.1.4Struktur15
2.1.5Komponenten16
2.1.6Beispiel19
2.1.7Ausblick21
2.2XML Schema Definition22
2.2.1Intention und Grundlage der XML Schema […]

Leseprobe

Inhaltsverzeichnis

ID 7347

Pondorf, Denis: Entwicklung eines XSD (extensibles Schema Definition) Generators

Hamburg: Diplomica GmbH, 2003

Zugl.: Universität Bremen, Universität, Diplomarbeit, 2003

Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,

insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von

Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der

Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,

bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung

dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen

der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik

Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich

vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des

Urheberrechtes.

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in

diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,

dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei

zu betrachten wären und daher von jedermann benutzt werden dürften.

Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können

Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die

Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine

Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.

Diplomica GmbH

http://www.diplom.de, Hamburg 2003

Printed in Germany

[...] Having found one item, moreover, one has to emerge

from the system and re-enter on a new path. The human mind

does not work that way. It operates by association. with one

item in its grasp, it snaps instantly to the next that is suggested

by the association of thoughts, in accordance with some intricate

web of trails carried by the cells of the brain.

[...] Consider a future device for individual use, which is a sort

of mechanized private file and library. It needs a name, and,

to coin one at random,

memex" will do. A memex is a device

in which an individual stores all his books, records, and commu-

nications, and which is mechanized so that it may be consulted

with exceeding speed and flexibility. It is an enlarged intimate

supplement to his memory. It consists of a desk, and while it

can presumably be operated from a distance, it is primarily the

piece of furniture at which he works. On the top are slanting

translucent screens, on which material can be projected for con-

venient reading. There is a keyboard, and sets of buttons and

levers. otherwise it looks like an ordinaz desk. In one end is the

stored material.

[...] Books of all sorts, pictures, current periodicals, newspapers,

are thus obtained and dropped into place. Business correspon-

dence takes the same path.

[...] He can add marginal notes and comments, taking advantage

of one possible type of dry photography, and it could even be ar-

ranged so that he can do this by a stylus scheme, such as is now

employed in the telautograph seen in railroad waiting rooms, just

as though he had the physical pave before him. All this is con-

ventional, except for the projection forward of present-day mech-

anisms and gadgetry. It affords an immediate step, however, to

associative indexing the basic idea of which is a provision whereby

any item may be caused at will to select immediately and auto-

matically another. This is the essential feature of the memex.

The process of tying two items together is the important thing.

[...]

Vannevar Bush

, 1945

'Urvater' des Markup-Gedanken aus [6]

Inhaltsverzeichnis

Erkl¨

arung

iii

Kurzfassung

viii

Abstract

Vorwort

Danksagung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Konvention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Einleitung

1.1

Zielsetzung

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2

Motivation

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3

Relevanz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4

Organisation

. . . . . . . . . . . . . . . . . . . . . . . . . . .

Grundlagen

2.1

XML Instanz . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.1

Intention und Grundlage der Extensible Markup Lan-

guage . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.2

R¨

uckblick . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.3

Spezifikation

. . . . . . . . . . . . . . . . . . . . . . .

2.1.4

Struktur . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.5

Komponenten . . . . . . . . . . . . . . . . . . . . . . .

2.1.6

Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.7

Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2

XML Schema Definition . . . . . . . . . . . . . . . . . . . . .

2.2.1

Intention und Grundlage der XML Schema Definition

2.2.2

R¨

uckblick . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.3

Spezifikation

. . . . . . . . . . . . . . . . . . . . . . .

2.2.4

Komponenten . . . . . . . . . . . . . . . . . . . . . . .

2.2.5

Datentypen . . . . . . . . . . . . . . . . . . . . . . . .

2.2.6

Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.7

Alternativen

. . . . . . . . . . . . . . . . . . . . . . .

INHALTSVERZEICHNIS

2.2.8

Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3

Validierung . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Methodik

Konstruktionsmodell

Erweiterbarkeit

5.1

Mechanismen . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.1.1

Inklusion

. . . . . . . . . . . . . . . . . . . . . . . . .

5.1.2

Verfeinerung

. . . . . . . . . . . . . . . . . . . . . . .

5.1.3

Import . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.1.4

XInclude

. . . . . . . . . . . . . . . . . . . . . . . . .

5.2

Elementebene . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.2.1

Stilvarianten

. . . . . . . . . . . . . . . . . . . . . . .

5.2.2

Auswahl . . . . . . . . . . . . . . . . . . . . . . . . . .

5.3

Attributebene . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.3.1

Stilvarianten

. . . . . . . . . . . . . . . . . . . . . . .

5.3.2

Auswahl . . . . . . . . . . . . . . . . . . . . . . . . . .

5.4

Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Redundanzfreiheit

Restriktion

7.1

Einfaches Inhaltsmodell . . . . . . . . . . . . . . . . . . . . .

7.1.1

Atomare Datentypen . . . . . . . . . . . . . . . . . . .

7.1.2

Abgeleitete Datentypen: restriction . . . . . . . . . . .

7.1.3

Abgeleitete Datentypen: list . . . . . . . . . . . . . . .

7.1.4

Abgeleitete Datentypen: union . . . . . . . . . . . . .

7.1.5

Auswahl . . . . . . . . . . . . . . . . . . . . . . . . . .

7.2

Komplexes Inhaltsmodell

. . . . . . . . . . . . . . . . . . . .

7.3

Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.4

Direktiven . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Lesbarkeit

8.1

Bezeichner . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.2

Anordnung

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

Szenario

9.1

Eingabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.2

Ausgabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

INHALTSVERZEICHNIS

vii

10 Implementierung

10.1 Dialekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10.2 Parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10.3 Writer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10.4 Application Programming Interface . . . . . . . . . . . . . . .

10.5 Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11 Potentiale

12 Referenzl¨

osungen

12.1 XSD Inference

. . . . . . . . . . . . . . . . . . . . . . . . . .

12.2 XML Spy . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12.3 HitSOFTWARE Schema Generator . . . . . . . . . . . . . . .

12.4 DDbE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13 Epilog

Literaturverzeichnis

A XML Instanz Spezifikation (Auszug)

101

B XML Schema Spezifikation (Auszug)

106

Kurzfassung

Die Extensible Markup Language (XML) hat sich heute als standardiser-

tes Serialisierungsformat und Transfersyntax auf breiter Front durchgesetzt.

J¨

unger noch ist das XML-Schema, aber ebenso erfolgreich. Dementspre-

chend w¨

achst die Anzahl an diese neuen Technologien verarbeitenden Ap-

plikation stetig. Da typischerweise ein Schema vorab bereits durch ¨

aquiva-

lente Instanzen einer Anwendung beschrieben und das Schreiben von XML-

Schemas keinesfalls trivial ist, dr¨

angt sich die Erfordernis eines Schema-

Generators auf. Im Rahmen dieser Arbeit wird die Entwicklung eines Ge-

nerators vorgestellt, der aus einer endlichen Menge von XML-Instanzen ein

XML-Schema f¨

ur jeden Zielnamensraum erzeugt.

Das Ziel-Schema wird

unter den mitunter interferierenden Pr¨

amissen Instanzvalidierung, Restrik-

tivit¨

at, Erweiterbarkeit, Redundanzfreiheit und Lesbarkeit konstruiert. Es

wird sowohl die methodische Konzeption vorgestellt, als auch eine Imple-

mentierung des XSD (Extensible Schema Definition) - Generators vorberei-

tet.

viii

Abstract

Today, the Extensible Markup Language (XML) is generally accepted as a

standardized serialization format and transfer syntax. Although the XML-

schema has been developed even more recently, it has become successful, too.

Therefore, the number of applications processing these new technologies is

constantly increasing. Since both a schema is typically described first by

equivalent instances of an application and the writing of XML-schemas is not

trivial in any way, the need for an XML-generator is compelling. This work

introduces the development of a generator generating an XML-schema for

any target namespace from a finite number of XML-instances. The target-

schema is constructed under the sometimes interfering premises instance

validation, restrictivity, extensibility, non-redundancy and readability. This

work does not only present the methodological conception but also suggests

an operable implementation of the XSD (Extensible Schema Definition) -

generator.

Vorwort

Danksagung

An dieser Stelle m¨

ochte ich Herrn Prof. Dr. H.-J. Kreowski,

Universit¨

Bremen

, meinen Dank f¨

ur die freundliche Betreuung meiner Diplomarbeit

sowie f¨

ur die Nachsicht gegen¨

uber den durch meine Selbst¨

andigkeit beding-

ten h¨

aufigen Terminverschiebungen aussprechen.

Auch spreche ich Herrn Prof. Dr. P.-H. Zieschang,

University of Texas

meinen Dank f¨

ur die gute Zusammenarbeit aus und f¨

ur die kurzfristige Zu-

sage zu einer Funktion als Gutachter.

Außerdem danke ich der

Info Business Systems GmbH

, Hamburg, und der

ivy group

, Bremen, f¨

ur die zur Verf¨

ugung gestellten Ressourcen und manch

hilfreichen Rat.

Konvention

Es werden folgende drei Schriftformatierungen - welche jeweils unterschied-

licher Bedeutung unterliegen - angewandt:

· Italic:

W¨

orter der englischen Sprache, sowohl an Stellen mit explizitem ¨

Uber-

setzungshinweis (engl.: translation hint), als auch an Stellen wo dieser

f¨

ur nicht (mehr) n¨

otig erachtet wird. (Diese Arbeit wird auf viele Be-

griffe der englischen Sprache nicht verzichten wollen, da diese sowohl

die urspr¨

unglichen Spezifikationen des

w3c

als auch deren ¨

Ubersetzun-

gen durchdrungen haben.)

Technische Eigennamen (Bsp. Server), die sich noch nicht in der kata-

logisierten deutschen Sprache plazieren konnten. Innerhalb von ¨

Uber-

schriften wird von dieser Auszeichnung jedoch abgesehen.

· Source:

XML - Fragmente, -Elemente, -Tags.

Bold

Eigennamen von Organisationen, Institutionen und Unternehmungen.

VORWORT

· http://www.irgendwo.de:

URI (Uniform Ressource Identifier) bzw. URL (Uniform Ressource

Locator) zwecks Angabe der Lokalit¨

at eines Referenz-Dokumentes im

world wide web.

Kapitel 1

Einleitung

1.1

Zielsetzung

Ziel dieser Arbeit ist die methodische Konzeption und eines restriktiven

XSD (Extensible Schema Definition) - Generators.

Ein XSD-Generator

sei ein Prozessor, der eine endliche Menge von XML (Extensible Markup

Language) - Instanzen als Eingabe erh¨

alt und in derem Kontext XML-

Schema erzeugt. Dieser Generierungsprozeß kann auch als eine regelbasierte

Transformation verstanden werden, auf Grundlage eines hier erarbeiteten

Regelwerkes.

Folgendes Use-Case-Diagramm skizziert grob den Anwendungsfall XSD-Generator:

Abbildung 1.1: Use-Case-Diagramm XSD-Generator

Die Vorbedingungen an den Eingabestrom des Prozessors, an die zu parsen-

den XML-Instanzen, sind:

· Wohlgeformtheit,

KAPITEL 1. EINLEITUNG

· keine Schema-Direktiven.

Unter Wohlgeformtheit ist eine korrekte Syntax im Sinne der Produktions-

regeln im Anhang A zu verstehen.

Schema-Direktiven in den Instanzen werden ausgeschlossen bzw. ignoriert,

weil diese mit den zu generierenden Direktiven interferieren k¨

onnten. In

Konsequenz verletzen dem Namensraum http://www.w3.org/2001/XML-instance

zugeordnete Attribute in den Instanzen die Vorbedingung.

Das generierte Schema, welches nicht nur aus einem serialisierten XML-

Schema-Dokument bestehen muß, soll folgenden Bedingungen gen¨

ugen:

· Wohlgeformtheit,

· G¨

ultigkeit,

· Validierung,

· Restriktivit¨

at,

· Erweiterbarkeit,

· Redundanzfreiheit,

· Lesbarkeit.

Unter G¨

ultigkeit ist eine korrekte strukturelle Semantik bzgl. der Schema-

Spezifikation des

w3c

zu verstehen, und somit eine Validierbarkeit gegen das

XSD-Schema in Anhang B.

Alle XML-Instanzen der Eingabe m¨

ussen selbstverst¨

andlich durch das ge-

nerierte Schema korrekt validiert werden k¨

onnen, - bzgl. diesem also g¨

ultig

sein.

Die Menge der ¨

uber die konkret gegebenen Instanzen hinaus validierbaren

fiktiven anderen Instanzen sollte minimal sein. D.h. das Ziel-Schema va-

lidiert Instanzen maximal restriktiv, - hypostiert f¨

ur das gegebene Set von

Instanzen - und nur f¨

ur diese - ein passendes Prokrustesbett.

Wiederverwendbarkeit und Flexibilit¨

at des generierten Schemas sollten gege-

ben sein. Dementsprechend ist die Unterst¨

utzung der Schema-Konzepte zur

Erweiterbarkeit eine weitere wesentliche Anforderung an das Zieldokument,

auch wenn ¨

uber den Nutzen dieser Vor¨

uberlegung vorab eines konkreten

Anwendungsfalls keine Aussage getroffen werden kann.

Die Anforderung Redundanzfreiheit soll gew¨

ahrleisten, daß im Schema keine

Aussage-Duplikate auftreten, auf pleonastische Konstrukte verzichtet wird.

D.h. der Ordnungszustand des Ziel-Schemas ist maximal, die Entropie im-

plizit minimal.

Unter Lesbarkeit sei allgemein bzgl. verwendeter Schema-Konstrukte die

KAPITEL 1. EINLEITUNG

Ber¨

ucksichtigung einer Verh¨

altnism¨

aßigkeit gegen¨

uber dem unterstellt le-

senden Auge und einer 'Aufwandsintuition' gemeint, - die Kostenfaktoren

Prozeßdauer und Zielgr¨

oße sollen beachtet bleiben. Dieser relative Aspekt

kann sich insbesondere auch einschr¨

ankend auf eine absolute Umsetzung der

Anforderungen Restriktivit¨

at und Erweiterbarkeit auswirken.

Dar¨

uber hinaus soll der XSD-Generator entsprechende Attribute im Na-

mensraum http://www.w3.org/2001/XML-instance als Direktiven f¨

ur validie-

rende XML-Prozessoren generieren. Erst diese fixieren die Korrespondenz

zwischen Instanz und Schema.

1.2

Motivation

Zwei Fragen dr¨

angen sich als Motivationsgrundlage auf: Die nach dem Nut-

zen der XML-Schema-Technologie im Allgemeinen und die nach dem Bedarf

eines Generierungsprozesses zur Erzeugung eines Schema aus einer Instanz-

menge.

Die erste Frage beantwortet sich ausf¨

uhrlich in Kapitel 2.2.1: XML-Schemas

validieren und dokumentieren XML-Instanzen. Viele (und zunehmend mehr)

Anwendungen verarbeiten Schemas um die G¨

ultigkeit der Instanzen verifi-

zieren zu k¨

onnen oder um strukturelles Wissen zu extrahieren oder in den

Instanzverarbeitungsprozeß integrieren zu k¨

onnen.

Die Schema-Generierung kann als Unterst¨

utzung oder Alternative einer wahr-

scheinlichst m¨

uhsameren Autorent¨

atigkeit genutzt werden, insofern Instanz-

exemplare vorliegen. Typischerweise liegen diese Instanzen vorab eines Sche-

mas vor, zumal der Standard XML-Schema sehr viel j¨

unger ist als der seiner

Bezugsinstanzen. Auch sei an dieser Stelle an den Grundsatz erinnert, daß

die Lebensdauer von Daten l¨

anger w¨

ahrt als die ihrer Datenmodelle. Da je-

denfalls die Schema-Sprache f¨

ur Autoren gewiß nicht trivial ist, kann sogar

eine initiierte exemplarische Instanzerstellung mit folgendem Generierungs-

prozeß als Einstiegspunkt einer Autorent¨

atigkeit ggf. in Betracht gezogen

werden. Oftmals jedoch steht der Aufwand einer Autorent¨

atigkeit in keinem

Verh¨

altnis zum Nutzen. Hier k¨

onnen dann aufwandsunabh¨

angig mittels ei-

nes XSD-Generators Schemas erstellt werden.

Abschließend seien exemplarisch zwei motivierende Anwendungsf¨

alle be-

schrieben:

XMill [32] komprimiert erfolgreich - basierend auf dem Prinzip der Da-

tenreorganisation nach Strukturgleichheit vorab der Kompression - seria-

lisierte XML-Dateien und entschieden effektiver als g¨

angige Kompresso-

ren. Die Kompression mit aus einem passenden Schema geparsten Infor-

KAPITEL 1. EINLEITUNG

mationen kann die Kompressionsrate hierbei entschieden verbessern: XMill

unterst¨

utzt XML-Schema! Hier w¨

are es nun m¨

oglich den XSD-Generator

XMill voranzustellen um es dem Kompressor mit dem generierten Schema

zu erm¨

oglichen, seine Kompressionsrate zu optimieren.

Mittels JAXB (Java Architekture for XML Binding) [48] [22] werden im

wesentlichen zwei Prozesse unterst¨

utzt: Das sog. Marshalling (dt.: Arran-

gierung) und das Unmarshalling (dt.: Dearrangierung). Letzterer erzeugt

aus einem XML-Dokument eine Inhaltsobjektrepr¨

asentation im Format der

Sprache JAVA, ersterer transformiert ein Inhaltsmodell in das XML-Format.

Vorab beider Prozesse ist die Bindung von Strukturinformationen ¨

uber das

XML-Dokument an den JAXB-Prozessor obligatorisch. Diese Strukturin-

formationen zum Aufbau eines Inhaltmodells werden bei JAXB aus einem

Schema extrahiert. Ist f¨

ur zu prozessierende XML-Dokumente nun noch

kein Schema verf¨

ugbar, so kann mittels eines XSD-Generators nunmehr auch

JAXB alternativ zur klassischen Verarbeitungsmethodik basierend auf SAX

(Simple API for XML) [33] und DOM (Document Object Model) [55] ver-

wendet werden.

1.3

Relevanz

Unter Relevanz sei der praktische Bezug und die reale Nutzbarkeit einer un-

terstellten erfolgreich realisierten Zielvorgabe gemeint. Die Relevanz ergibt

sich aus der der Basistechnologie XML und der der der hier verwendeten

Schema -Sprache des

w3c

sowie aus dem Grad der S¨

attigung der noch jun-

gen XML-Landschaft mit vergleichbaren Produkten.

In [49] wurde unl¨

angst in einer weltweiten Studie die Marktdurchdringung

von XML untersucht. Demnach hat sich XML auf breiter Front durchge-

setzt und z¨

ahlt heute zu den Kerntechnologien moderner und zukunftsori-

entierter IT-Strategien. Diese Studie findet sich beispielsweise untermauert

in [17] und [63], wo eine Auswahl von aktuellen genormten und zertifizier-

ten Standards, welche XML als integrale Technologie erfolgreich verwenden,

vorgestellt wird.

Das XML-Schema ist noch relativ jung und konkurriert mit alternativen

Schema-Sprachen: Hier l¨

aßt sich bis auf eine eklatante Verdr¨

angung des

SGML-Reliktes der Document Type Definition (DTD) durch das XML-

Schema noch keine deutliche Prognose ¨

uber eine zuk¨

unftige Akzeptanz po-

stulieren.

Wie aus Kapitel 5 hervorgeht, existieren zum Zeitpunkt der Erstellung die-

ser Arbeit nur bedingt vergleichbare Produkte, v.a. keines - und da liegt der

initiale Fokus dieser Arbeit - welches auf Grundlage einer mehrelementigen

Instanzmenge generiert.

KAPITEL 1. EINLEITUNG

F¨

ur ein ¨

uber das world wide web zur Verf¨

ugung gestelltes praktisch nutzba-

res Implementierungsergebnis lassen sich Anwender aus den Bereichen der

XML-Anwendungsentwicklung erwarten.

1.4

Organisation

Folgender ¨

Uberblick soll das Gliederungskonzept vorstellen und Kapitelin-

halte umreißen:

Kapitel 1 (Einleitung)

beschreibt die Intention dieser Arbeit, motiviert

die Zielfindung und unterstreicht den Aspekt der Relevanz.

Kapitel 2 (Grundlagen)

f¨

uhrt in die beiden wesentlichen Technologien

XML und XSD als Inhaltsschwerpunkte der Arbeit ein.

Kapitel 3 (Methodik)

konzipiert Vorgehensmodell und Workflow des

Generierungsprozesses f¨

ur eine zu erreichende Zielvorgabe.

Kapitel 4 (Konstruktionsmodell)

modelliert ein wesentliches konsoli-

dierendes Zwischenmodell im Generierungsprozeß von XML-Instanzen hin

zu einem XML-Schema.

Kapitel 5 (Erweiterbarkeit)

untersucht den Einfluß des Kriteriums der

Erweiterbarkeit auf den Generierungsprozeß und resultiert in einer Vorgabe

der Komponentenarchitektur und Schema-Distribution.

Kapitel 6 (Restriktion)

behandelt M¨

oglichkeiten und Grenzen einer

Umsetzung der Vorgabe einer Restriktivit¨

at im Schema und m¨

undet im

wesentlichen in R¨

uckschl¨

ussen auf Typisierung und Strukturinferenz.

Kapitel 7 (Redundanzfreiheit)

kontrolliert den Status Redundanzfrei-

heit im Ziel-Schema.

Kapitel 8 (Lesbarkeit)

er¨

ortert die Gew¨

ahrleistung des Aspektes gege-

bener Lesbarkeit im Schema.

Kapitel 9 (Implementierung)

spricht eine m¨

ogliche Implementierung

im Kontext bisheriger Resultate an.

Kapitel 10 (Szenario)

simuliert Erwartung an input/output einer po-

tentiellen Implementierung.

KAPITEL 1. EINLEITUNG

Kapitel 11 (Potentiale)

betrachtet M¨

oglichkeiten der Entfaltung und

Weiterentwicklung der hier vorgestellten Ans¨

atze.

Kapitel 12 (Referenzprodukte)

wirft einen Blick auf relevante Pro-

dukte und L¨

osungen mit ¨

ahnlicher Zielvorgabe.

Kapitel 13 (Epilog)

faßt Ergebnisse und Erfahrungen der Arbeit zusam-

men.

Anhang A (XML-Spezifikation)

b¨

undelt die aus [56] extrahierten Pro-

duktionsregeln als Syntaxspezifikation der XML.

Anhang B (XSD-Spezifikation)

subsumiert die Schema-Struktur reifi-

kativ als Schema.

Kapitel 2

Grundlagen

Elementare Grundlage dieser Arbeit sind XML-Instanzen (Kapitel 2.1) und

XML-Schemata (Kapitel 2.2) sowie deren Interdependenzen bzgl. eines Va-

lidierungsprozesses (Kapitel 2.3) einer XML-Instanz durch ein korrespondie-

rendes XML-Schema.

Formal ist jedes XML-Schema eine XML-Instanz bzw. sind XML-Schemata

Teilmenge von XML-Instanzen. Dementsprechend besitzen alle Inhalte von

Kapitel 2.1 ebenso G¨

ultigkeit f¨

ur Kapitel 2.2. Um der Vordergr¨

undigkeit des

Validierungsaspektes gerecht zu werden, sollen jedoch beide Kapitel separat

betrachtet werden.

2.1

XML Instanz

Die Extensible Markup Langage (XML) geh¨

ort zur Klasse der Markup-

Sprachen und ist eine Teilmenge der Standard Generalized Markup Language

(SGML). Intention, Ursprung und Entwicklung der 'Erweiterten Auszeich-

nungssprache' werden beschrieben in den Kapiteln 2.1.1 und 2.1.2.

Die Begriffe XML, XML-Instanz, XML-Dokument, XML-Datei werden ge-

meinhin synonym verwendet, was bezeichnend ist f¨

ur die Eigenschaft einer

XML-Instanz, auch Transfersyntax und Serialisierungsformat gem¨

aß der in

Kapitel 2.1.3 verwiesenen Spezifikation zu sein. Ungeachtet dessen, ist im

dieser Arbeit der Begriff Instanz angebracht, um dem wesentlichen Aspekt

der Schema-Beziehung gerecht zu bleiben.

Auch wenn diese Einleitung eine Lekt¨

ure der Spezifikation nicht ersetzen

kann, werden in Kapitel 2.1.4 die Struktur und in Kapitel 2.1.5 die Kom-

ponenten innerhalb einer XML-Instanz zusammenfassend beschrieben im

Kontext der Zielsetzung dieser Arbeit.

Ein Design-Ziel f¨

ur XML liest sich in der Spezifikation [56] wie folgt: '[...]

XML documents should be human-legible and reasonably clear [...] shall be

easy to create [...]'. Dementsprechend ist in Kapitel 2.1.3 eines repr¨

asenta-

tives Beispiel einer serialisierten XML-Instanz verf¨

ugbar.

KAPITEL 2. GRUNDLAGEN

2.1.1

Intention und Grundlage der Extensible Markup Lan-

guage

Da XML- eine Entwicklung des

w3c

ist und auch von diesem ver¨

offentlicht

wird, lohnt es sich hier, die Intentionen des im Oktober 1994 gegr¨

undeten

Konsortiums n¨

aher vorzustellen:

Das

w3c

- der Name l¨

aßt darauf schließen - arbeitet um die globale Infra-

struktur des world wide web und entwickelt diesbez¨

uglich neue Standards.

Es will nach eigner Darstellung (http://www.w3.org) ¨

uber Entwicklungen

relevanter Technologien (Spezifikationen, Leitf¨

aden und Software) ein Fo-

rum f¨

ur Information, Kommerz, Inspiration, Unabh¨

angigkeit und Kollektiv-

verst¨

andnis schaffen, als Grundlage f¨

ur eine angestrebt hohe Aussch¨

opfung

der Potentiale des world wide web.

Unter den vom

w3c

benannten Zielen und Operationsprinzipien wird XML

unter 'Semantisches Web' aufgef¨

uhrt! Begr¨

unden l¨

aßt sich diese Zuordnung

durch die F¨

ahigkeit von XML nicht nur Transfersyntax f¨

ur den Austausch

von Daten zu sein, sondern auch Semantik mittels Strukturierung und Be-

schreibung der eigentlichen Dateninhalte zu erm¨

oglichen.

In [56] werden Designziele f¨

ur XML wie folgt zusammengefaßt benannt:

1. Nutzbarkeit direkt ¨

uber das Internet,

2. Applikationsunterst¨

utzung,

3. SGML - Kompatibilit¨

at,

4. Minimalaufwand f¨

ur XML verarbeitende Programme,

5. optionale Eigenschaften minimal,

6. Gew¨

ahrleistung von Klarheit und Lesbarkeit auch ohne maschinelle

Unterst¨

utzung,

7. formales, leichtes, klares Design,

8. leichte Erstellbarkeit.

Ab dem vierten Aufz¨

ahlungspunkt ist eine Beurteilung der N¨

ahe initialer

Designziele zur Realit¨

at der Spezifikation nur noch relativ m¨

oglich, aber der

Anspruch der Sprache wird deutlich.

Eine Markup-Sprache im allgemeinen ist gem¨

aß [24] charakterisiert als Nota-

tion zur Definition von Struktur und Formatierung eines Dokumentes mit-

tels Integration spezieller Zeichensequenzen, sogenannter Etiketten (engl.:

tag). Das so entstandene System von Tags, welches das auszuzeichnende

Dokument mit einer hierarchischen Struktur durchdringt, erlaubt die Iden-

tifikation logischer Komponenten im Dokument durch eine syntaktischen

KAPITEL 2. GRUNDLAGEN

Definition der Dokumentenstruktur.

In Anlehnung an die Grundlagen der Datenmodellierung bei Datenbanksy-

stemen [1] kann man analog die eigentlichen Informationen in einem XML-

Dokument als Prim¨

ardaten bezeichnen, alle anderen Informationen (Tags,

etc.) als Metadaten ('Daten ¨

uber Daten'). Mit festgelegter Syntax und

Semantik der Metadaten wird ein formales Rahmenwerk f¨

ur eine Datenbe-

schreibung fixiert, - das sog. Datenmodell. In diesem Sinne kann die Sprache

XML, welche ein Rahmenwerk f¨

ur die Ausstattung von Informationen mit

Typ und Struktur definiert, als abstraktes Datenmodell interpretiert wer-

den.

Letztlich aber ist XML ein vom

w3c

publizierter Satz von Empfehlungen,

welche Semantik und Syntax von XML (und verwandten Technologien) spe-

zifiziert: Das XML Information Set (Infoset) [58] modelliert als Satz von

strukturellen Information-Items die Kernabstraktionen der Sprache, wohin-

gegen in [56] und [61] eine Fixierung syntaktischer Details erfolgt. Erst die

syntaktische Definition der Sprache erm¨

oglicht ihren Einsatz als Transfer-

syntax f¨

ur den Austausch zwischen heterogenen Systemen und als Serialisie-

rungsformat. Genau genommen schreibt das Infoset weder eine programma-

tische Schnittstelle vor, noch erzwingt es die Benutzung der Syntaxvorgaben

in [56] und [61], jedoch hat sich eine isomorphe Abbildung zwischen dem Da-

tenmodell und dessen syntaktischer Serialisierung bew¨

ahrt.

In [50] werden Analogieschl¨

usse zwischen den Konzepten der semistruktu-

rierten Daten und XML gezogen, jedoch ist XML genau genommen und

entgegen h¨

aufig anderweitiger Aussagen [4] kein semistrukturierter Daten-

typ, auch kein abstrakter Datentyp, vielmehr eine universelle Datenbeschrei-

bungssprache.

In der Architektur des hierarchischen OSI (Open Systems Interconnection)

- Schichtmodells [44], welches ISO-standardisierte Funktionen und Begriffe

zur Kommunikation zwischen Computersystemen definiert, plaziert sich XML

als Transfersyntax in der Anwendungsschicht (Application Layer: level 7)

als benutzerspezifisches Kommunikationsmedium.

Der in Kapitel 2.1.2 angedeutete Ursprung des Markup-Gedankens als Doku-

mentenbeschreibungssprache sowie die Notwendigkeit einer Datenbeschrei-

bungssprache finden sich in XML vereint und f¨

uhren zu zwei strukturell

unterscheidbaren Kategorien von XML-Dokumenten, die als dokumenten-

und datenzentriert bezeichnet werden. In [66] werden diese beiden Katego-

rien wie folgt klassifiziert:

Dokumentenzentrierte Dokumente:

· gemischter Elementinhalt,

· unregelm¨

aßige Struktur (Text und Elemente),

KAPITEL 2. GRUNDLAGEN

· tiefe und beliebige Verschachtelung,

· Reihenfolge der Elemente ist relevant,

· starke Strukturunterscheidung zwischen Instanzen desselben Typs,

· typische Web (HTML) - Dokumente.

Datenzentrierte Dokumente:

· homogener ungemischter Elementinhalt,

· regul¨

are Struktur (Text oder Elemente),

· flache Verschachtelung,

· Reihenfolge der Elemente ist irrelevant,

· geringe Strukturunterscheidung zwischen Instanzen desselben Typs,

· typische Applikationstransfer-Dokumente.

Unter dem Inhaltsmodell eines XML-Dokumentes versteht man das Mo-

dell der Kinder der Dokumentenwurzel, analog unter dem Inhaltsmodell ei-

nes Elementes die unmittelbaren Kinder eines Elementes. Unabh¨

angig von

Attributen kann dem Inhaltsmodell einen der folgenden Zust¨

ande zugeord-

net werden:

· simple: Inhaltsmodell besteht nur aus Textknoten.

· complex: Inhaltsmodell besteht nur aus Elementen, aber keinerlei

Textknoten.

· mixed: Inhaltsmodell besteht aus einem beliebigen Konglomerat von

Text- und Elementknoten.

· empty: Inhaltsmodell besteht weder aus Text- noch Elementknoten.

Aufgrund der h¨

aufig synonymen Verwendung der Begriffe XML-Datei und

XML-Dokument sei hier der Unterschied klargestellt: Der Begriff XML-

Datei bezieht sich auf eine physische Textdatei (gem¨

aß Konvention mit dem

Suffix 'xml' versehen), bestehend aus einer Zeichensequenz im UTF-8 For-

mat. Der Begriff XML-Dokument bezieht sich auf eine abstrakte Struktur,

die eine Datenstruktur im Speicher sein kann. Das Dokument resultiert aus

dem Parsen einer Datei oder einer direkten Konstruktion im Speicher. Und

es ist nat¨

urlich m¨

oglich, daß verschieden Dateien ein und dasselbe Dokument

repr¨

asentieren, - die Umkehrung aber gilt nicht f¨

ur ein Dokumentmodell.

Artikel wie [23] sind bezeichnend f¨

ur den allerorts zu beobachtenden Hype

KAPITEL 2. GRUNDLAGEN

um die Sprache XML. Die Ursache hierf¨

ur liegt wohl eher in der Tatsache

begr¨

undet, daß man sich auf einen Akzeptanz versprechenden Serialisierungs-

und Transfer-Standard einigen konnte (und einer damit einhergehenden ¨

oko-

nomischen Opportunit¨

at), als in technischer Komplexit¨

at, - zumal XML

als echte Teilmenge der Sprache SGML (Standard Generalized Markup

Language) bereits seit fast zwei Jahrzehnten pr¨

asent ist.

In XML steckt das vielversprechende Attribut erweiterbar (engl. eXtensi-

ble), dessen X sich in vielen Nachbartechnologien (XSL, XPath, XQuery,

SchemoX, etc.) ebenso etabliert hat, - Grund genug darauf einzugehen: Die

Tatsache, daß XML lediglich die Sprache festlegt, aber keine konkrete Da-

tenstruktur, schon gar keine Interpretation, l¨

aßt dem Datenmodellierer alle

M¨

oglichkeiten mittels der Sprachdefinition konkrete XML-Instanzen oder

-Schemas zu modellieren. Diese Modellierungsfreiheit wird als Erweiterbar-

keit plakativ unterstrichen. Neu ist dies jedoch wohl nur f¨

ur diejenigen,

welche aus dem Dokumenten- oder HTML (Hypertext Markup Language)

-Lager (als durchaus wichtige Einflußstr¨

omung in der Entwicklung der XML)

kommend mit XML konfrontiert werden.

An dieser Stelle sei auch noch eine verbreitete aber unberechtigte Asso-

ziation der Sprachen XML und HTML [52] angesprochen: Typische Ge-

genwartspublikationen wie [46] oder [11] suggerieren die Redefinition von

HTML als XHTML (eXtensible Hypertext Markup Language) [29] als vor-

dergr¨

undige Intention der Sprache XML. Tats¨

achlich ist wie in Kapitel 2.1.2

gezeigt, HTML eine wesentliche Entwicklungsstr¨

omung f¨

ur XML, jedoch ist

diese Verbindung keinesfalls ¨

uberzubewerten. Die XHTML Spezifikation als

Standard f¨

ur die Sprache des world wide web ist lediglich eine XML Anwen-

dung bzw. jedes XHTML-Dokument ist eine Instanz bzgl. eines XHTML-

Schemas.

Analog sind alle XML-basierten Sprachen - wie beispielsweise

SAML (Security Assertions Markup Language) [16] - letztlich sehr spezielle

XML-Anwendungen, gleich einer Teilmenge der XML, deren Instanzen kon-

form sind zu einem vorhandenen bzw. erstellbaren XML-Schema.

Da die Begriffe XML-Server und XML-Datenbank [5] sehr gel¨

aufig gewor-

den sind, sei auch diesbzgl. hier eine abgrenzende Erl¨

auterung angebracht.

Konventionell dienen Server und Datenbanken allgemein der strukturierten

Speicherung von Informationen und der Anfragebearbeitung. XML-Server

und -Datenbanken setzen zumeist auf diese auf, aber definieren sich mehr

uber ihren Output und Verarbeitungsf¨

ahigkeiten, als ¨

uber ihre innere Struk-

tur, und fungieren als Middleware in n-tier Umgebungen. Genau genommen

handelt es sich hierbei um XML-Konverter oder -Interfaces, die basierend auf

der Auszeichnungssprache Daten verarbeiten, interpretieren, zur Verf¨

ugung

stellen. (Eine bemerkenswerte Ausnahme einer 'nativen' XML-Datenbank

KAPITEL 2. GRUNDLAGEN

wird allerdings in [14] beschrieben!) Diese terminologische Kontroverse wird

ausf¨

uhrlich in [62] untersucht.

2.1.2

R¨

uckblick

Der Ursprung der Markup-Sprachen liegt in der Dokumentenverarbeitung in

den fr¨

uhen 60er Jahren und basiert auf dem Anspruch, Text mit strukturel-

len, layout-technischen, typographischen, logischen Auszeichnungen (engl.:

markup) versehen zu k¨

onnen, wie in Abb. 2.1 exemplifiziert: Mittels Mar-

kierstift (marker) - nicht zuf¨

allig bezeichnend f¨

ur linguistischen Ursprung -

wurde hier der Text, die reinen Daten, mit einer strukturellen bzw. logischen

Auszeichnung versehen, die dem Interpreter des Dokumentes zus¨

atzliche Se-

mantik vermittelt.

Abbildung 2.1: Markup Beispiel

Auszeichnungssysteme vor dem Computerzeitalter finden sich insbeson-

dere im Buchdruck: Den nur Verbalinformationen beinhaltenden Manu-

skripten werden para- und nonverbale Informationen von Autor und Lektor

in Form von speziellen Auszeichnungen hinzugef¨

ugt. Diese Auszeichnungen

fungieren als Notizen und Anweisungen f¨

ur den Setzer bzw. Drucker, haben

eine festgelegte Syntax und Semantik, stellen somit eine eigene Sprache -

eine Auszeichnungssprache - dar.

Die Extensible Markup Language wurde ab dem Jahre 1996 unter der

Schirmherrschaft des

w3c

in der von Jon Bosak (

Sun Microsystems

) gef¨

uhr-

ten XML Working Group entwickelt.

Wie Abb. 2.2 veranschaulicht, sind es im Wesentlichen drei Str¨

omungen,

auf denen die Entwicklungen der Extended Markup Language baut: SGML

als ausdrucksst¨

arkere Markup-Sprache, HTML als wichtiges Anwendungs-

exempel, das Internet und dessen Technologien als Vorgabe eines Transfer-

mediums.

Die Generalized Markup (GM) wurde bereits in den fr¨

uhen 60er Jahren

KAPITEL 2. GRUNDLAGEN

Abbildung 2.2: XML Entwicklung

entwickelt, fristete jedoch ein Schattendasein bis zur Ratifizierung der Stan-

dard Generalized Markup Language (SGML) durch die

International Or-

ganization for Standardization

(ISO 8859) im Jahre 1986. Ein Maß f¨

die Stabilit¨

at der Sprache SGML ist allein die Tatsache, daß diese ¨

uber eine

Dekade mit keinerlei Spezifikations¨

anderungen konfrontiert werden mußte.

Allerdings wurden die Potentiale dieser Sprache bei weitem weder qualita-

tiv noch quantitativ ausgesch¨

opft: Die d¨

urftige Akzeptanz l¨

aßt sich v.a. auf

eine hohe Komplexit¨

at, entsprechenden Einarbeitungsaufwand und einen

un¨

uberschaubaren Spezifikationsumfang zur¨

uckf¨

uhren. Somit erweist sich

im R¨

uckblick die M¨

achtigkeit und Ausdrucksst¨

arke von SGML gleicher-

maßen als ihr Handikap. Bald wurde deutlich, daß eine Sprachreduktion

der Steigerung von Akzeptanz und Attraktivit¨

at eines Markup-Standards

f¨

orderlich ist.

Das 1969 etablierte

ARPANET

(Advanced Research Project Agency Net-

work) sowie die Entwicklungen des

CERN

(European Laboratory for Par-

ticle Physics) Anfang der 90er legten den Grundstein f¨

ur das Internet als

globales Netzwerk und Transferplattform f¨

ur den Informationsaustausch. In

Kapitel 2.1.1 wird Nutzbarkeit ¨

uber das Internet als eine wesentliche An-

forderung aufgef¨

uhrt. Somit flossen Erfahrungen im Informationsaustausch

uber das Internet - insbesondere bzgl. Protokollunterst¨

utzung und Anwen-

dungsinterpretation - in den Entwicklungsprozeß der XML ein.

Es war m¨

oglich, Dokumente zu einem weltweiten Netz (world wide web)

KAPITEL 2. GRUNDLAGEN

von Informationen zu verlinken. Als Beschreibungssprache zur Gestaltung

von Inhalten dieser Dokumente wurde die Hypertext Markup Language ent-

wickelt.

Diese erm¨

oglicht die Zusammenf¨

uhrung von Inhalt und Forma-

tierung sowie die Verlinkung von Dokumenten. Sprachmittel der HTML

werden von den Interpretationsm¨

oglichkeiten und -grenzen der pr¨

aferierten

Browser, als Empf¨

anger und Interpreter der Dokumente im world wide web,

vorgegeben, so daß kommerziell bedingtem 'Wildwuchs' jenseits eines Stan-

dards der Sprachmittel keine Grenzen gesetzt waren.

Dementsprechen waren im Jahre 1996 die Notwendigkeiten der Restandar-

disierung von HTML und der Simplifikation und Popularisation der SGML

dem

w3c

ausreichend Motivation zur Definition der Designziele einer neuen

Markup-Sprache, - der Extensible Markup Language. Am 10. Februar 1998

wurde die Spezifikation XML version 1.0 ver¨

offentlicht. Am 6. Oktober 2000

folgte eine stabilere und nunmehr bereits ¨

uber zwei Jahre bew¨

ahrte zweite

Auflage der Spezifikation 1.0.

2.1.3

Spezifikation

Folgende ¨

Ubersicht gibt Auskunft ¨

uber alle vom

w3c

herausgegebenen XML

relevanten Spezifikationen (Stand April 2003):

URL

Status

Datum

Beschreibung

Extensible Markup Language (XML) 1.0 (2nd Edition)

http://www.w3.org/TR/REC-xml

Recommendation

6.Okt.2000

Beschreibung von Struktur, In-

halt, Syntax der XML ohne

Namensr¨

aume.

Inkl.

XML-

Prozessor-Empfehlungen.

Extensible Markup Language (XML) 1.1

http://www.w3.org/TR/xml11/

Recommendation

Candidate

15.Okt.2002

Geringf¨

ugige Erg¨

anzungen zur

Spezifikation XML 1.0

Namespaces in XML 1.1

http://www.w3.org/TR/xml-names11/

Recommendation

Candidate

18.Dez.2002

Spezifiziert

Zusatz

der

Na-

mensraumbezeichnung

von

Element- und Attributnamen,

welche die Spezifikation XML

1.0 nicht erw¨

ahnt.

XML Information Set

http://www.w3.org/TR/xml-infoset

Recommendation

24.Okt.2001

Syntaxfreie Beschreibung der

XML auf hoher Abstraktions-

stufe.

KAPITEL 2. GRUNDLAGEN

Diese vom

w3c

ver¨

offentlichten Empfehlungen (engl.

Recommendation)

bzw. Empfehlungskandidaten (engl. Recommendation Candidate) sind die

maßgebliche Referenz f¨

ur den Standard XML. Unter dem Status Empfeh-

lungskandidat kann man sich ein noch nicht abgesegnetes Arbeitspapier vor-

stellen, wohingegen der Status Empfehlung bereits Stabilit¨

at und Akzeptanz

verspricht.

Die Erforderlichkeit eines Versionssprungs mit der Spezifikation XML 1.1 er-

gibt sich - wie beschrieben in [20] - v.a. aus Unzul¨

anglichkeiten der aktuellen

Recommendation bzgl. des Zeichensatzes:

· Aktueller Zeichensatz Unicode 3.2 erlaubt 45.962 neue Zeichen vergli-

chen mit Unicode 3.0 (auf dem XML 1.0 basiert);

· Eingeschr¨

ankte Bezeichnerkodierung;

· Whitespace-Zeichen der IBM-Mainframe-Welt werden nicht unterst¨

utzt.

Die Vergabe einer neuen Versionsnummer, die auch im Prolog eingef¨

ugt

werden muß, ergibt sich aus der Tatsache, daß XML 1.1 Dateien keinem

wohlgeformten XML 1.0 mehr entsprechen, - die beiden Versionen also in-

kompatibel zueinander sind.

Da sich derzeit die XML 1.1 im Status der Candidate Recommendation

befindet und in der Evolution des

w3c

erst die Stufe Proposed Recommen-

dation durchlaufen muß bevor der Status einer Recommendation erreicht

werden kann, orientiert sich diese Arbeit an der aktuellen Recommenda-

tion. Nicht zuletzt, da f¨

ur XML 1.1 noch keine voll funktionsf¨

ahigen Parser-

Implementierungen vorliegen.

2.1.4

Struktur

Zur Beschreibung der logischen Struktur der XML bietet es sich an, das

Infoset [58] - als die maßgebliche Definition des abstrakten Datenmodelles

eines XML-Dokumentes - zu fokussieren. Dieses definiert und beschreibt elf

Information-Items und deren Interdependenzen. In [3] findet sich eine ¨

uber-

sichtliche Modellierung des Infosets als Klassendiagramm der UML (Unified

Modelling Language) [21], in welchem alle Komponenten und Strukturab-

h¨

angigkeiten erfaßt sind. Aus Abbildung 2.3 wird deutlich, daß sich das

Infoset-Modell als ein baumorientierter Graph pr¨

asentiert, dessen Wurzel

das Dokument-Information-Item darstellt. Prozessionsinstruktions-, Kom-

mentar-, Element- und Zeichen-Information-Items fungieren als Endknoten

(Bl¨

atter). Element-Information-Items fungieren aufgrund der 0-n-Aggrega-

tionsbeziehung zu sich selbst als struktur- und tiefengebende interne Knoten,

und sind im ¨

ubrigen umfangreichster und am h¨

aufigsten genutzter Daten-

typ. Jedes XML-Dokument muß (mindestens) ein Element besitzen, - dieses

KAPITEL 2. GRUNDLAGEN

Abbildung 2.3: UML-Modell des XML-Infoset aus [3]

obligatorische Kindelement des Dokumentes wird auch als das Wurzel- oder

Dokumentelement bezeichnet. Die Tatsache, daß eine umkehrbar eindeutige

Transformation zwischen einer beliebigen Datenstruktur und einem baum-

orientierten Graphen aus Elementen und Zeichendaten leicht m¨

oglich ist,

macht Element-Information-Items sehr anpassungsf¨

ahig. Enth¨

alt ein Ele-

ment ausschließlich eine geordnete Menge von Kind-Elementen, so repr¨

asen-

tiert dieses Element einen strukturierenden Typ. Enth¨

alt ein Element aber

ausschließlich Zeichendaten, so repr¨

asentiert dieses einen atomaren Typen.

Erstere bezeichnet man als element-only-, letztere als text-only-Elemente.

Die Verschachtelung von Zeichendaten und Elementen unterhalb eines Ele-

ment-Knotens f¨

uhrt zu einem Mischmodell (mixed content) welches histo-

risch begr¨

undet erlaubt, aber f¨

ur eine Modellierung von Datenstrukturen

irrelevant ist. Das Element in Zeile 84 des Dokumentes in Kapitel 2.1.6

exemplifiziert ein mixed-content-Element. Elemente liegen als Kinder von

Elementen geordnet vor (children-Aggregation), wohingegen Attribute unge-

ordnet vorliegen (attributes-Aggregation). Demnach k¨

onnen Attribute nicht

uber ihre Position angesprochen werden, vielmehr aber ¨

uber einen eindeuti-

gen Namen. Modellierungstechnisch erweisen sich Attribute als substituier-

bar durch Elemente, - funktional gesehen sind sie sogar nur Teilmenge von

Elementen, da sie keine Prozessionsinstruktionen, Kommentare und Ele-

mente enthalten k¨

onnen.

2.1.5

Komponenten

Die Komponenten eines XML-Dokuments lassen sich direkt aus den Information-

Items des Infoset [58] ableiten. Eine syntaktische Korrespondenz der Information-

Items zum Serialisierungsformat ist gegeben. Im Folgenden werden die Kom-

ponenten aufgef¨

uhrt und im Umfang unter Bezugnahme auf die Relevanz zur

Zielvorgabe dieser Arbeit beschrieben. Die angegebene Produktionsnummer

KAPITEL 2. GRUNDLAGEN

bezieht sich auf die im Anhang A beschriebene Produktionsregel, die Zeilen-

nummer beispielhaft Bezug nehmend auf die in Kapitel 2.1.6 angegebene.

Dokument

Es existiert genau ein Dokument Information-Item, - alle anderen Information-

Items ordnen sich direkt oder indirekt unter. Es handelt sich demnach um

die Wurzel der Komponentenhierarchie, die mindestens eine Processing In-

struction enthalten muß sowie genau ein nachgestelltes Element.

Produktion: xml 1.0 [1]

Zeile: 00-100

Dokument-Typ-Deklaration

Die Dokument-Typ-Deklaration (eng.:Document Type Declaration), auch

gel¨

aufig als DTD, ist ausdrucksschwacher Vorl¨

aufer des

w3c

Schema und

wird daher im Kontext dieser Arbeit als obsolet betrachtet und ignoriert.

Produktion: xml 1.0 [28]

Zeile: n.v.

Notation

Notationen sind nur im Zusammenhang mit einer DTD relevant, - werden

daher als obsolet betrachtet und ignoriert.

Produktion: xml 1.0 [82]

Zeile: n.v.

Entit¨

aten sind nur im Zusammenhang mit einer DTD relevant, - werden

daher als obsolet betrachtet und ignoriert.

Produktion: xml 1.0 [70]

Zeile: n.v.

Namensraum

Ein Namensraum (eng.:namespace) ist jeweils jedem Element und Attribut

zugeordnet. Dieser wird charakterisiert durch ein Pr¨

afix (als Alias) und ei-

nem voll qualifiziertem Namensraumbezeichner.

Produktion: xmlns 1.1 [6]

Zeile: 02, 03 (Deklaration); 40 (impliziter Default-Namensraum 'http://jpegmarker.org'),

97 (expliziter Namensraum-Pr¨

afix 'http://www.authorcomment.net')

KAPITEL 2. GRUNDLAGEN

Element

Unter allen Element Information-Items im Dokument ist genau eines Doku-

mentelement (die Wurzel des Elementbaumes), - alle weiteren sind direkt

oder indirekt Kinder des Dokumentelementes.

Das Element ist 'Hierar-

chietr¨

ager', da es eine geordnete Menge von Elementen als Kinder besitzen

kann; Dar¨

uber hinaus auch Zeichen, Prozessionsinstruktionen, Kommentare

und eine ungeordnete Menge von Attributen. Das Element wird charakte-

risiert durch einen lokalen Namen und Zuordnung zu einem Namensraum.

Produktion: xml 1.0 [39]

Zeile: 40 (im Default-Namensraum); 97 (mit Namensraum-Pr¨

afix)

Attribut

Attribute haben ausschließlich Zeichen als Kinder und sind selbst Kinder von

Elementen. Das Attribut wird charakterisiert durch einen lokalen Namen

und Zuordnung zu einem Namensraum. Attribute unterst¨

utzen Elemente,

k¨

onnen jedoch - konform allgemeiner Modellierungstendenz - auch verlustfrei

zu Kind-Elementen derer Elemente transformiert werden.

Produktion: xml 1.0 [41]

Zeile: 17 (Attribut name)

Prozessionsinstruktion

Eine Prozessionsinstruktion (eng.:Processing Instruction), auch gel¨

aufig un-

ter und im Folgenden verwendet als PI, kann als Kind eines Dokument

Information-Items oder eines Element Information-Items ¨

uberall auftreten

und charakterisiert sich durch einen und Namen (eng.: target) und einen In-

haltstext. PIs als Name/Werte-Paare unterst¨

utzen v.a. Dokument-Prozessoren

und fungieren als Anweisungen oder Anmerkungen in einem serialisierten

XML-Zeichenstrom.

Mittels PIs l¨

aßt sich die hierarchische Struktur des

Elementgraphen aufbrechen und sogar eine komplett neue Architektur in-

nerhalb eines Dokumentes aufbauen.

Produktion: xml 1.0 [16]

Zeile: 08

Kommentar

Kommentar besteht aus einem Inhaltstext der den Kommentar charakteri-

siert und kann - gleich einer PI - als Kind eines Dokument Information-Items

oder eines Element Information-Items auftreten.

Produktion: xml 1.0 [15]

Zeile: 06

Details

Seiten
Erscheinungsform: Originalausgabe
Erscheinungsjahr: 2003
ISBN (eBook): 9783832473471
ISBN (Paperback): 9783838673479
Dateigröße: 2.1 MB
Sprache: Deutsch
Institution / Hochschule: Universität Bremen – Informatik
Erscheinungsdatum: 2014 (April)
Note: 1,7
Schlagworte: schema mark
Produktsicherheit: Diplom.de

Autor

Denis Pondorf (Autor:in)

Entwicklung eines XSD (extensibles Schema Definition) Generators

Zusammenfassung

Leseprobe

Inhaltsverzeichnis

Details

Autor

Denis Pondorf (Autor:in)