Problemseminar: "Datenbankeinsatz im Internet"
Thema 6: "XML - Unterstützung durch Datenbanksysteme"

Bearbeiter: Steven Rickel
Betreuer: Herr Märtens

Universität Leipzig
Institut für Informatik
Abteilung Datenbanken

 

0. Inhalt

  1. Einleitung
    1.1. Übersicht
    1.2. XML, HTML und SGML
    1.2. Ziele bei der Entwicklung von XML
  2. Technische Einführung in XML
    2.1. XML-Markups
    2.2. XML-Dokumenttypdeklaration
    2.3. Gültigkeit von XML-Dokumenten
    2.4. Definition von XML
  3. Eine Anfragesprache für XML
    3.1. Ein Datenmodell
    3.2. XML-Query Language
  4. Anwendungen
    4.1. Chemical Markup Language und JUMBO
    4.2. Extensible Hypertext Markup Language
    4.3. Tamino - Informationsserver
  5. Zusammenfassung und Ausblick
  6. Literaturverzeichnis

 

1. Einleitung

1.1. Übersicht

Eine der wichtigsten Anwendungen im Internet ist der Austausch von elektronischen Dokumenten. Immer mehr Firmen wollen ihre Daten aus Datenbanken im Internet zugänglich machen. Um strukturierte Daten auszutauschen, benötigt man eine Beschreibungssprache (Markup Language). XML ist die Abkürzung für Extensible Markup Language, d.h. eine erweiterte Beschreibungssprache für strukturierte Dokumente. Strukturierte Dokumente bestehen aus Daten und Markups. Die Daten können Texte, Bilder oder Ähnliches sein. Markups geben die Struktur bzw. den Sinn der Daten wieder. Es ist z.B. ein Unterschied, ob "Uni Leipzig" als Überschrift oder Fußnote syntaktisch gedeutet wird und ob "Creme" als Kosmetika oder Schuhputzmittel semantisch gedeutet wird.

In dieser Ausarbeitung wird XML vorgestellt. In der Einführung wird dargelegt, wie XML sich zu HTML und SGML einordnet und welche Ziele sich die Entwicklungsgruppe von XML gestellt hatten. Im zweiten Teil folgt eine kurze technische Einführung in XML. Dabei geht es darum, wie XML-Dokumente aufgebaut sind. Im dritten Teil wird eine Anfragesprache für XML vorgestellt. Es wird zuerst ein Datenmodell definiert. Danach wird gezeigen, wie man XML-Daten abfragen kann. Im vierten Teil werden einige Anwendungen von XML angesprochen. Vorgestellt werden zwei Markup Languages und eine XML-Anbindungen zu Datenbanken. Zum Schluß gibt es noch eine Zusammenfassung der Ausarbeitung und Ausblicke von XML.

1.2. XML, HTML und SGML

HTML ist zur Zeit das verbreitetste Datenformat im WWW. Es ist gut geeignet, um einfache Texte und Bilder im Internet zu repräsentieren. In HTML ist der Satz an Tags festgesetzt. Es ist nicht erlaubt, neue Tags zu entwerfen. HTML ist somit nicht erweiterbar. Dies ist aber für speziellere Anwendungen notwendig. Für Chemiker ist es notwendig eine Chemical Markup Language zu erstellen, um Daten über chemische Vorgänge auszutauschen. HTML unterstützt nicht die Beschreibung von tiefen Strukturen, welche notwendig sind, um Datenbankschemas oder objektorientierte Hierarchien darzustellen. XML ist keine Erweiterung von HTML. In XML definiert man die Tags selber. XML ist somit eine Metasprache wie SGML. Genau genommen ist XML eine vereinfachte Form oder eine Untermenge von SGML. In SGML kann man die Semantik der Daten festlegen. Jedoch benötigt man Spezialisten, welche in SGML Anwendungen programmieren können, da SGML nicht so leicht erlernbar ist wie HTML. Es gibt jetzt eine Verbesserung von HTML 4.0, die Spezifikation XHTML 1.0. Diese ist eine Anwendung von XML 1.0. Bei der Entwicklung von XML wurde darauf geachtet, daß XML Eigenschaften von SGML übernimmt, dabei aber einfacher zu erlernen und zu benutzen ist. Die Vorteile von XML sind die willkürliche Erweiterung von Tags und Attributen sowie die Unterstützung von Dokumenten mit komplexer Struktur. Die Hauptanwendung von XML besteht im Austausch von Daten via Internet.

1.3. Ziele bei der Entwicklung von XML

1996 wurde eine Gruppe unter der Schirmherrschaft des World Wide Web Consortium (W3C) gegründet. Mitglieder dieser Arbeitsgruppe waren SGML Spezialisten. Diese hatten die Aufgabe, XML zu entwerfen. Dabei sollten 10 Ziele erfüllt werden [nach Wa97].

  1. XML sollte im Internet einfach zu handhaben sein. Benutzer können XML-Dokumente so einfach und so schnell versenden, empfangen und verarbeiten, wie es heute mit HTML-Dokumenten möglich ist. Dies setzt natürlich auch voraus, daß XML-fähige Browser im Internet weit verbreitet sind. Der erste XML-fähige Browser war JUMBO, welcher in der chemischen Industrie verwendet wird. Microsoft Internet Explorer 5 unterstützen ebenso XML.
  2. XML sollte eine große Auswahl an Anwendungen unterstützen. Diverse Anwendungen wie z.B. Texte verfassen, im Internet "browsen" oder Inhalte analysieren ist mit XML möglich. Das Hauptanliegen ist jedoch das Verarbeiten von strukturierten Daten im Netz.
  3. XML sollte zu SGML kompatibel sein. XML wurde in der Weise entworfen, daß es kompatibel zu dem SGML-Standard ist und das Versenden von strukturierten Daten im Internet zu ermöglichen. XML ist eine Untermenge von SGML.
  4. Es sollte einfach sein, ein Programm zu schreiben, welches XML-Dokumente verarbeitet. XML ist nicht so schwer zu programmieren wie SGML. Um dieses Ziel auszudrücken wird in Wa97 beschrieben, daß ein Informatikstudent im hohem Semester zwei Wochen benötigt, um eine XML-Anwendung zu schreiben.
  5. Die Anzahl von optionalen Merkmalen sollte in XML auf ein Minimum gehalten werden. Optionen sind unvermeidlich, um Kompatibilitätsprobleme zu lösen, wenn sich Benutzer Daten teilen. Manchmal führt dies jedoch zu Konfusionen und Frustrationen.
  6. XML-Dokumente sollten für Menschen lesbar und verständlich sein. Wenn man keinen XML-Browser zur Hand hat und mittels einem Texteditor XML-Dokumente ansieht, läßt sich der Inhalt lesen und verstehen.
  7. Das XML-Design sollte schnell angefertigt sein. XML wird jetzt gebraucht um Probleme, die gerade jetzt da sind, zu lösen. Der Zeitfaktor ist also sehr wichtig. XML wurde so schnell wie möglich entwickelt.
  8. Das XML-Design sollte formal und präzise sein. XML muß in der EBNF (erweiterten Backus-Naur-Form) ausgedrückt werden und von modernen Computertools und -techniken lesbar sein.
  9. XML-Dokumente sollten einfach zu erstellen sein. Obwohl es spezielle XML-Editoren geben wird, ist es möglich mittels einfachen Editoren und Shells XML-Dokumente zu erstellen und zu bearbeiten.
  10. Die Kürze von XML-Markups ist nur ein kleines Ziel. Mehrere SGML-Merkmale können das Eingeben von Text erleichtern. In XML wurde darauf verzichtet. Die meisten Editoren unterstützten so wie so Shortcuts.

Im Februar 1998 wurde die erste Version präsentiert. Heute gibt es schon viele Anwendungen. Einige werden im vierten Teil beschrieben. Der Trend für XML ist weiter steigend. Wie ist nun ein XML-Dokument aufgebaut?

 

2. Technische Einführung in XML

2.1. XML-Markups

XML-Dokumente setzen sich aus den Daten (data) und den Informationen über die Daten (markup) zusammen. Eine XML-Datei kann sich aus drei Teilen zusammensetzen [Br97]. Die ersten beiden Teile sind optional. Als Erstes kann eine Prozessorinstruktion stehen. Diese gibt an, welche Version von XML verwendet wird, wie es kodiert ist und ob es sich auf externen Dateien bezieht oder nicht. Dies könnte so aussehen.

<?xml version="1.0" standalone="yes">

Als Zweites kann eine Dokumenttypdeklaration stehen. Diese wird entweder direkt angegeben oder durch eine externe Datei referenziert, z.B.

<!DOCTYPE bib SYSTEM "http://www.mybib.com/dtd/bib.dtd">

Der letzte Teil ist das eigentliche Dokument mit einem root Element und allen Subelementen und den Daten.

Zur Beschreibung der Daten gibt es 6 verschiedene Markup-Typen [Wa97]: Elemente (elements), Referenzen auf Entitäten (entity references), Kommentare (comments), Verarbeitungsanweisungen (processing instructions), markierte Abschnitte (marked sections) und Dokumenttypdeklarationen (document type declarations). Im folgenden werden diese kurz beschrieben. Die Dokumenttypdeklarationen (DTD) wird in einem Extraabschnitt behandelt.

Elemente

Elemente sind die am häufigsten verwendeten Markups. Die meisten Elemente beschreiben Merkmale des eingeschlossenen Inhaltes. Der Inhalt liegt zwischen einem Start-Tag und einem End-Tag (<element> Inhalt </element>). Ein Element kann auch inhaltslos sein (<element/>). Elemente können Attribute haben, welche wie folgt angegeben werden müssen <element attribut="wert">.

Referenzen auf Entitäten

Um Markups von Daten zu unterscheiden, werden einige Zeichen reserviert. Das Kleiner-Zeichen (<) z.B. gibt den Beginn eines Start- oder End-Tags eines Elementes an. Um solche Zeichen auch als Daten verwenden zu können, muß ein alternativer Weg eingeführt werden. In XML werden Entitäten verwendet um auch diese Sonderzeichen als Daten zu verwenden. Außerdem werden Entitäten verwendet um auf sich oft wiederholenden Text zu verweisen und um Inhalt von einer externen Datei einzubinden. Jede Entität muß einen eindeutigen Namen besitzen um dann auf diese eindeutig verwiesen zu können. Ein Verweis auf eine Entität beginnt mit dem Und (&) und endet mit dem Semikolon (;). Zum Beispiel umschreibt die Entität lt ein "<"-Zeichen. Somit wird der String <element> durch die Zeichenkette &lt;element> in XML präsentiert.

Kommentare

Kommentare können an allen Stellen in einem XML-Dokument stehen. Sie beginnen mit der Zeichenfolge "<!--" und enden mit "-->" (<!-- Kommentar -->). Kommentare sind nicht Teil eines Textes und werden auch nicht vom Prozessor mit verarbeitet.

Verarbeitungsanweisungen

Verarbeitungsanweisungen (PIs) sind keine Text im XML-Dokument, denn sie werden vom XML-Prozessor zur Verarbeitung einer Anwendung verwendet. PIs haben die Form <?name pidata?>. Der Name (PI-target) identifiziert die PIs für eine Anwendung. Anwendungen sollen nur anerkannte PIs verarbeiten und die anderen ignorieren. PI-Namen beginnen mit "<?XML", eine dafür reservierte Zeichenfolge. Eine PI, welche die XML-Version festlegt und sich nicht auf externen Dateien bezieht, könnte so aussehen:

<?xml version="1.0" standalone="yes">

CDATA-Sektionen

In CDATA-Abschnitten werden die Markups ignoriert. Zwischen dem Start-Tag "<![CDATA[" und dem End-Tag "]]>"werden alle Zeichen direkt für eine Anwendung verwendet. Kommentare, Elemente usw. werden nicht als diese erkannt. Im folgenden Bsp. wird q nicht als Entität angesehen und nach dem i beginnt kein Element:

<![CDATA[
*p = &q;
b = (i <= 3);
]]>

 

2.2. Dokumenttypdeklarationen

Eine DTD gibt die Beziehung der verschiedenen Elemente im Dokument an. Anders gesagt, definiert man damit die Tags mit den eingebundenen Tags (nested tags), die Attributwerte, deren Typen und Defaults und die Namen von externen Dateien. Es gibt vier Arten von Deklarationen, welche folgend kurz beschrieben werden.

Deklaration eines Elements

Die Deklaration eines Elements definiert den Namen und die eingebauten Elemente. Man betrachte den folgenden Beispiel einer Elementdeklarationen.

<!DOCTYPE bib [
<!ELEMENT book (author+, title, publisher)>
<!ELEMENT article (author+, title, year?, (shortversion|longversion))>
<!ELEMENT author (#PCDATA | firstname | lastname)>
<!ELEMENT title (#PCDATA)>
<!ELEMENT year (#PCDATA)>
]>

Das Element book muß mindestens einen Autor (gekennzeichnet durch das Plus), genau einen Titel und genau einen Verlag enthalten. Das Element article besteht aus Autoren, einen Titel, optional das Erscheinungsjahr (gekennzeichnet durch das Fragezeichen) und einer Kurzversion oder einer Vollversion (gekennzeichnet durch den vertikalen Strich). Der Ausdruck #PCDATA steht für parsed character data und bedeutet, daß hier ein beliebiger String oder ein gültiges Tag stehen darf. Man kann auch inhaltslose Elemente deklarieren. Diese werden durch den Ausdruck empty angegeben, wie folgendes Beispiel zeigt. <!ELEMENT EmptyPage empty>. Dieses Element würde dann in einem XML-Dokument folgendermaßen verwendet. <EmptyPage/>

Deklaration eines Attributes

Die Deklaration von Attributen erfolgt ähnlich zu den Elementdeklarationen. Der eigentliche Unterschied zwischen einem Element und einem Attribut ist, daß ein Attribut nicht weiter mit Subelementen verzweigt werden kann. Bei dieser Deklaration wird definiert, zu welchem Element die Attribute gehören, welche Attribute das Element haben kann, welche Werte sie annehmen können und was die Defaultwerte sind. Betrachtet man folgendes Beispiel.

<!ATTLIST book year CDATA #implied>
<!ATTLIST article type CDATA #required>

Das Element book besitzt das Attribut year und das Element article das Attribut type. Was CDATA, #implied und #required bedeutet, wird weiter unten erklärt.

Jedes Attribut in einer Deklaration besteht aus drei Teilen, den Namen des Attributes, den Typen und den Defaultwert. Der Name ist frei wählbar, jedoch ist pro Element ein Name nur einmal zu verwenden. Dann gibt es sechs verschiedene Typen und vier verschiedene Defaultwerte, welche deklariert werden können.

Der CDATA-Typ (character data) erlaubt jeden Text. Das CDATA sollte nicht verwechselt werden mit den CDATA-Sektionen. Der ID-Typ erwartet einen Namen. Die ID-Werte müssen im ganzen Dokument eindeutig sein und Elemente können nur einen ID-Typen enthalten. Der IDREF-Typ muß einen Wert enthalten, der den Wert eines ID-Typen im Dokument entspricht. Der IDREFS-Typ enthält mehrere ID-Referenzen getrennt durch Leerzeichen. Der ENTITY-Typ erwartet als Wert eine Entität des Dokumentes (ENTITIES-Typ mehrere Entitäten mit einem Leerzeichen getrennt). NMTOKEN-Typ (name token) ist eine Form von Stringattributen, welches ein einzelnes Wort enthalten muß aber keine weiteren Beschränkungen unterliegt. Der NMTOKENS-Typ kann mehrere NMTOKEN enthalten, welche durch ein Leerzeichen getrennt sind. Beim letzten Typ wird eine Liste von Namen (a list of names) übergeben. Dieser Typ wird auch aufzählender Typ genannt (enumerated typ), weil jeder der Werte explizit in einer Deklaration aufgezählt wird.

Bei der Angabe des Defaulwertes #REQUIRED ist die Auftreten des Attributes zwingend. Beim Defaulwert #IMPLIED muß das Attribut nicht angegeben werden und es existiert auch kein Defaultwert. Als Defaultwert kann auch irgendein Wert (value) angegeben werden, so daß dieser Wert angenommen wird, wenn das Attribut nicht angegeben wird. Um einen festen Defaultwert anzugeben, benutzt man #FIXED "value". In diesem Fall ist das Attribut nicht nötig, wenn es aber angegeben wird, muß es das angegeben sein.

Deklaration einer Entität

Eine Deklaration eine Entität ermöglicht eine Assoziation eines Namens mit einem Teil regulären Textes, eines DTD oder einen Verweis auf einer externen Datei wie folgende Beispiele zeigen.

<!ENTITY UNI "University Leipzig, Department Computer Science">
<!ENTITY notice SYSTEM "/standard/notice.xml">
<!ENTITY MyLogo SYSTEM "/standard/logo.gif" NDATA GIF87A>

Es existieren drei verschiedene Typen von Entitäten. Die erste Deklaration definiert eine interne Entität (internal entity). Dabei kann man Shortcuts definieren für häufig verwendeten Text oder sich oft veränderten Text. Es wird dabei auf einen Text verwiesen, der in der Deklaration steht. In XML sind fünf interne Entitäten vordefiniert. Dies sind &lt; für das Kleinerzeichen (<), &gt; für das Größerzeichen (>), &amp; für das Undzeichen (&), &apos; das Apostroph ('), &quot; das Anführungszeichen ("). Die zweite Deklaration definiert eine externe Entität (external entity) weil dabei auf Text einer anderen Datei verwiesen wird. Diese Datei enthält Text. Eine externe Datei kann entweder Text oder binäre Daten enthalten. Text wird an der Stelle der Referenz als Text behandelt, binäre Daten jedoch nur als Referenz. Der dritte Typ sind Parameterentitäten (parameter entity), welche nur in DTD's auftreten können und dabei direkt der referenzierte Text für die DTD verwendet wird.

Deklaration einer Notation

Eine Notation gibt an, welchen Typ eine externen binäre Datei hat. Damit kann der Prozessor diese in einer Anwendung verarbeiten.

<!NOTATION GIF87A SYSTEM "GIF">

 

2.3. Gültigkeit von XML-Dokumenten

In Bezug zur den Typdeklarationen gibt es gültige und nicht gültige Dokumente. Man unterscheidet zwischen zwei Kategorien von XML-Dokumenten, wohlgeformte und gültige.

wohlgeformte Dokumente

Ein Dokument ist nur wohlgeformt, wenn es der Syntax von XML folgt, z.B. gibt es mindestens ein Element in Dokument, es gibt genau ein ausgezeichnetes Element (root) und jedes Start-Tag besitzt auch eine End-Tag. Überlappende Elemente sind dabei nicht erlaubt wie z.B.

<p> here is an emphasize <em> paragraph. </p> </em>

gültige Dokumente

Ein wohlgeformtes Dokument ist nur gültig, wenn es zu einer korrekten DTD gültig ist, d.h. das Dokument folgt vollständig den Regeln der DTD. Mit gültigen Dokumenten läßt es sich fehlerfrei arbeiten, wie z.B. abfragen.

 

2.4. Definition von XML

XML ist definiert durch vier Spezifikationen, welche hier nur kurz erwähnt werden sollen. XML (Extensible Markup Language) definiert die Syntax vom XML wie in diesem Kapitel eingeführt wurde.

XLL (Extensible Linking Language) definiert den Weg um Verweise zwischen verschiedenen Quellen zu repräsentieren. Multi-direktionale Links ermöglichen z.B. einen Zwei-Wege-Link um wieder auf das Original zurück zu gelangen. Es werden Links zu mehreren Zielen unterstützt und es kann der Inhalt eines Links gleich in ein Dokument angezeigt werden.

XSL (Extensible Style Language) definiert die Präsentation von XML. XSL ist eine Sprache um den Stil auszudrücken, wie ein XML-Dokument präsentiert wird.

XUA (XML User Agent) soll User Agents wie z.B. Browser standardisieren.

An dieser Stelle wird die technische Betrachtung abgebrochen. Für weitere Informationen verweise ich auf [Wa97].

 

3. Eine Anfragesprache für XML

3.1. Ein Datenmodell

In Datenbanken werden Daten extrahiert, transformiert und integriert mittels einer Anfragesprache. Eine Anfragesprache fordert ein Datenmodell. Beim traditionellen relationalen Datenmodel kann SQL und beim objektorientierten Datenmodel kann OQL als Anfragesprachen verwendet werden. XML-Daten unterscheiden sich jedoch von diesen Datenmodellen. Jedoch sind XML-Daten sehr ähnlich zum den semistrukturierten Daten. Es existiert eine Anfragesprache für XML, nämlich XML-QL, welche nun kurz vorgestellt wird.

Zuerst muß jedoch eine Datenmodel definiert werden. Ein XML-Dokument kann als ein XML-Graphen modelliert werden. Die formale Definition sieht folgendermaßen aus.

Definition. Ein XML-Graph G ist definiert durch:
- jeder Knoten wird durch einen eindeutigen String repräsentiert, den Object Identifier (OID),
- jede Kante wird markiert durch ein Elementnamen,
- jeder Knoten wird markiert durch einen Satz von Attribut Werte Paare,
- jedes Blatt wird markiert durch einen Wert und
- jeder Graph hat einen ausgezeichneten Knoten (root).

Folgendes Beispiel wird jetzt betrachtet. Diese XML-Daten sind zu der DTD vom Abschnitt 2.2 passend.

<bib>
<book year="1995">
<!-- A good introductory text -->
<title> An Introduction to Database Systems </title>
<author> <lastname> Date </lastname> </author>
<publisher> <name> Addison-Wesley </name > </publisher>
</book>
<book year="1998">
<title> Foundation for Object/Relational Databases: The Third Manifesto </title>
<author> <lastname> Date </lastname> </author>
<author> <lastname> Darwen </lastname> </author>
<publisher> <name> Addison-Wesley </name > </publisher>
</book>
</bib>

Der dazugehörige Graph in Abb1 sieht folgendermaßen aus. Von der Wurzel (root) gehen zwei Kanten ab, welche mit dem Element book markiert sind und in jeweils einen Knoten enden. Diese Konten sind mit dem Attribut year markiert. Von dort aus gehen jeweils mehrere Kanten aus. Diese repräsentieren eingebaute Elemente vom Element book. Die Blätter sind mit dem Inhalt der Elemente markiert. Wenn keine OID explizit angegeben wird, wird diese generiert. Bei diesem Graph wurde auf die Object Identifier und auf das root verzichtet.

Abb1: "XML graph" nach [DF98]

Wie werden nun ID und IDREF modelliert? Man betrachtet folgenden Auszug einer DTD.

<!ATTLIST person ID ID #REQUIRED>
<!ATTLIST article author IDREFS #IMPLIED>

<person ID="o123">
<firstname>John</firstname>
<lastname>Smith</lastname>
</person>
<person ID="o234"> . . .
</person>
<article author="o123 o234">
<title> . . . </title>
</article>

Anders als die anderen Attribute wird ein IDREF durch eine Kante zum referenzierten Element dargestellt und mit dem Attributnamen markiert. ID-Attribute werden zu den OID's der Knoten. Der folgende Graph in Abb2 wurde zum oberen Beispiel modelliert.

Abb2: "XML graph" nach [DF98]

Es werden die Elemente und die IDREF(S)-Attribute gleich modelliert. Beide werden durch eine Kante dargestellt. Dies erlaubt z.B. Join-Anfragen auf ID's zu generieren. In diesem Datenmodell läßt sich die folgenden XML-Daten aber nicht darstellen, da nur Blätter Werte enthalten und auch nur einen Wert.

<title>A Trip to <titlepart> the Moon </titlepart></title>

Man muß dies in folgende XML-Daten umschreiben.

<title><CDATA> A Trip to </CDATA>
<titlepart><CDATA> the Moon</CDATA></titlepart> </title>

Nun lassen sich diese XML-Daten in einen Graphen darstellen, wie in Abb3.

Abb3: "XML graph" nach [DF98]

In diesem Datenmodell sind die Graphen ungeordnet, d.h. es gibt keine feste Reihenfolge für das Auftreten von eingebauten Elementen (Kanten im Graph). Dies vereinfacht das Datenmodell und auch die Anfragesprache. Natürlich läßt sich auch ein geordneter Graph modellieren. Dies ist besonders dann wichtig, wenn den Elementen in der DTD eine Ordnung aufgeschrieben wird.

Ein XML-Graph entsteht nun also aus der Analyse eines XML-Dokuments. Es wurde ein Datenmodell eingeführt und jetzt können darauf Anfragen gestellt werden.

 

3.2. XML - Query Language

XML-Query Language ist ein Vorschlag des W3C [DFLS98]. Mit XML-QL kann man Anfragen auf XML-Dokumenten legen, welche Daten aus den Dokumenten extrahieren. Dies wird nun an ein einführendes Beispiel gezeigt. Ausgegangen wird von folgender DTD (aus Abschnitt 2.2.):

<!ELEMENT book (author+, title, publisher)>
<!ATTLIST book year CDATA>
<!ELEMENT article (author+, title, year?, (shortversion|longversion))>
<!ATTLIST article type CDATA>
<!ELEMENT publisher (name, address)>
<!ELEMENT author (firstname?, lastname)>

Diese DTD legt fest, daß ein book-Element einem oder mehreren Autoren, einen Titel und einen Verlag beinhaltet und eine year-Attribut besitzt. Das article-Element beinhalten einen oder mehrere Autoren, einen Titel, das Jahr als Option, ein shortversion- oder longversion-Element und ein type-Attribut usw.

Einfache Anfrage

WHERE <book>
<publisher><name>Addison-Wesley</name></publisher>
<title> $t</title>
<author> $a</author>
</book> IN www.a.b.c/bib.xml
CONSTRUCT $a

Diese Anfrage gibt eine Liste von Autoren zurück, welche im XML-Dokument http://www.a.b.c/bib.xml unter dem book-Element stehen und mindestens einen Titel, einen Autor und einen Verlag mit dem Namen Addison-Wesley haben. Variablen werden vom Dollarzeichen angeführt um sie von Strings zu unterscheiden. Oft ist es besser das Ergebnis in einem XML-Dokument einzugeben. Die folgende Anfrage macht dies.

CONSTRUCT-Anweisung

WHERE <book>
<publisher><name>Addison-Wesley</></>
<title> $t</> <author> $a</>
</> IN www.a.b.c/bib.xml
CONSTRUCT <result>
<author> $a</> <title> $t</>
</>

Um dies an einem Beispiel zu sehen folgt ein XML-Dokument, auf welches die oben angegebene Anfrage gelegt wird (Bsp. aus Abschnitt 3.1.).

<bib>
<book year="1995">
<title> An Introduction to Database Systems </title>
<author> <lastname> Date </lastname> </author>
<publisher> <name> Addison-Wesley </name > </publisher>
</book>
<book year="1998">
<title> Foundation for Object/Relational Databases: The Third Manifesto </title>
<author> <lastname> Date </lastname> </author>
<author> <lastname> Darwen </lastname> </author>
<publisher> <name> Addison-Wesley </name > </publisher>
</book>
</bib>

Das Ergebnis sieht so aus.

<result>
<author> <lastname> Date </lastname> </author>
<title> An Introduction to Database Systems </title>
</result>
<result>
<author> <lastname> Date </lastname> </author>
<title> Foundation for Object/Relational Databases: The Third Manifesto </title>
</result>
<result>
<author> <lastname> Darwen </lastname> </author>
<title> Foundation for Object/Relational Databases: The Third Manifesto </title>
</result>

Gruppierungen

In diesem Ergebnis treten die Autoren eines Buches in verschiedenen Ergebnissen auf. Um Gruppierungen in einer Abfrage zu ermöglichen, werden nested queries verwendet. Die folgende Anfrage gruppiert nach dem Buchtitel.

WHERE <book>
<title> $t </>
<publisher><name>Addison-Wesley </> </>
</> CONTENT_AS $p IN www.a.b.c/bib.xml
CONSTRUCT <result><title> $t </>
WHERE <author> $a</> IN $p
CONSTRUCT <author> $a</>
</>

Die Anweisung CONTENT_AS $p IN www.a.b.c/bib.xml bindet das Ergebnis der WHERE-Klausel an die Variable p. Die kann nun gleich auf der rechten Seite einer IN-Anweisung im selben WHERE-Ausdruck oder in einem nested CONSTRUCT stehen. Diese Anfrage bringt folgendes Ergebnis.

<result>
<title> An Introduction to Database Systems </title>
<author> <lastname> Date </lastname> </author>
</result>
<result>
<title> Foundation for Object/Relational Databases: The Third Manifesto </title>
<author> <lastname> Date </lastname> </author>
<author> <lastname> Darwen </lastname> </author>
</result>

Joins

In XML-QL lassen sich auch Joins ausdrücken. Folgende Abfrage enthält einen Join über den Namen von Autoren. Dabei werden alle Artikel gesucht, welche mindestens einen Autor besitzen, welcher auch ein Buch nach 1995 geschrieben hat. Der Join erfolgt durch die Verwendung der selben Variablen.

WHERE <article>
<author>
<firstname> $f </>
<lastname> $l </>
</>
</> CONTENT_AS $a IN www.a.b.c/bib.xml
<book year=$y>
<author>
<firstname> $f </>
<lastname> $l </>
</>
</> IN "www.a.b.c/bib.xml",
y > 1995
CONSTRUCT <article> $a </>

Tag-Variablen

XML-QL unterstützt das Abfragen von Element-Tags mittels Tag-Variablen. Die folgende Anfrage findet alle Veröffentlichungen von 1995 mit Smith als Autor oder Herausgeber. Die Variablen a und e sind Tag-Variablen.

WHERE <$p>
<title> $t </title>
<year>1995</>
<$e> Smith </>
</> IN "www.a.b.c/bib.xml",
$e IN {author, editor}
CONSTRUCT <$p>
<title> $t </title>
<$e> Smith </>
</>

Datentransformation

XML-Daten lassen sich durch XML-QL transformieren und integrieren. Bei der Datentransformation werden Daten aus einer Quelle abgefragt und in ein Ziel gelegt. Das Ziel kann eine neue DTD enthalten wie folgendes Beispiel.

<!ELEMENT person (lastname, firstname, address?, phone?, publicationtitle*)>

Mit der folgenden Anfrage erhält man ein neues Dokument mit der neuen DTD.

WHERE <$> <author> <firstname> $fn </>
<lastname> $ln </>
</>
<title> $t </>
</> IN "www.a.b.c/bib.xml",
CONSTRUCT <person ID=PersonID($fn, $ln)>
<firstname> $fn </>
<lastname> $ln </>
<publicationtitle> $t </>
</>

Die Transformation liegt dabei in der CONSTRUCT-Anweisung. Wenn eine Person ausgewählt wurde, wird der Vor- und Nachname sein OID. Im Fall, daß nun eine Person zum zweiten mal auftritt, wird kein neues Element <person> angelegt. Jedoch wird der Titel der Veröffentlichung mit in dem schon vorher angelegten Element <person> hinzugefügt.

Datenintegration

Man kann auch Daten verschiedener Quellen in einem Dokument integrieren. Dazu können XML-QL Anfragen in Blocks und Subblocks strukturiert werden. Subblocks werden in geschweifte Klammern geschrieben. Man betrachte folgendes Beispiel.

{ WHERE <person>
<name> </> ELEMENT_AS $n
<ssn> $ssn </>
</> IN www.a.b.c/data.xml
CONSTRUCT <result ID=SSNID($ssn)> $n </> }
{ WHERE <taxpayer>
<ssn> $ssn </>
<income> </> ELEMENT_AS $i
</> IN www.irs.gov/taxpayers.xml
CONSTRUCT <result ID=SSNID($ssn)> $i </> }

In dieser Anfrage ist der Root-Block leer und es gibt zwei Subblocks. Im ersten Subblock werden alle Personen extrahiert und die Sozialversicherungsnummer ist der ID. Im zweiten Block werden die Einkommen der Personen ermittelt. Wenn nun eine Person ermittelt wird, welche vorher schon extrahiert wurde, dann wird das Element <income> hinzugefügt. Diese Anfrage ist ein Outer-Join von den zwei Quellen. Subblocks sind ein sehr vielseitiges und mächtiges Merkmal von XML-QL. Anfragen können auch in Daten eingebettet werden wie folgendes Beispiel.

<result>
<articles>
WHERE <article< <title> $t </>
<year> $y </>
</> in "www.a.b.c/bib.xml", $y > 1995
CONSTRUCT <title> $t </>
</>
<books>
WHERE <book< <title> $t </>
<year> $y </>
</> in "www.a.b.c/bib.xml", $y > 1995
CONSTRUCT <title> $t </>
</>
</>

Funktionen

Als letztes hier vorgestelltes Merkmal lassen sich auch Funktionen definieren. Das folgende Beispiel gibt eine Funktionsdefinition des oben betrachteten Beispiels an.

FUNCTION findDeclaredIncomes($Taxpayers, $Employees)
WHERE <taxpayer> <ssn> $s </>
<income> $x </> </> IN $Taxpayers,
<employee> <ssn> $s </>
<name> $n </> </> IN $Employees
CONSTRUCT <result> <name> $n </>
<income> $x </> </>
END

Diese Funktion kann dann folgendermaßen aufgerufen werden.

findDelcaredIncomes("www.irs.gov/taxpayers.xml", "www.a.b.c/employees.xml")

XML-QL unterstützt das Anfragen, Transformieren und Integrieren von XML Daten. Ob diese Anfragesprache sich für XML-Daten nun durchsetzten wird, ist jetzt noch nicht zu sagen.

 

4. Anwendungen

Nach dem Erscheinen der XML-Spezifikation im Februar 1998 gibt es viele Ansätze für XML-Anwendungen. Jedoch gibt es zur Zeit nur wenige Anwendungen, welche schon voll im Einsatz sind. Folgend werden zwei Markup Languages und ein auf XML basierender Server kurz vorgestellt.

 

4.1. Chemical Markup Language und JUMBO

Die Chemical Markup Language (CML) nach [MR98] ist eine plattform- und konventionsunabhängige Spezifikation zum Austausch von Informationen zu Molekularwissenschaft. Diese ist kompatibel zu XML und soll die Zukunft in wissenschaftliche Veröffentlichungen in der Molekular-Chemie haben. CML wurde in Verbindung mit XML-Software getestet und wird vom XML-fähigen Browser JUMBO unterstützt. Folgend werden einige Merkmale kurz beschrieben.

JUMBO ist der erste XML-fähige Browser. Er unterstützt jede DTD und ist somit nicht nur auf CML beschränkt. Er kann die Baumstruktur eines Dokumentes grafisch anzeigen und erlaubt das Editieren. JUMBO beinhaltet über 300 Java-Klassen und verbindet Elemente mit diesen um z.B. Moleküle graphisch darzustellen.

CML unterstützt die Beschreibung von unter anderem organischen und anorganischen Molekülen, Makromolekülen wie Proteine, chemische Reaktionen und theoretische Berechnungen. Dafür stehen allgemeine Elemente wie <person>, <units> oder <bib> und spezifische wie <atom>, <mol> oder <sequence> zur Verfügung.

CML-Dokumente können eine komplexe interne Baumstruktur haben und auf andere Dokumente verweisen. Tags können semantisch gewertet werden. JUMBO arbeitet mit Java-Klassen, welche durch einige Tags aufgerufen werden. Somit wird durch das Tag <MOLECULE> die Java-Klasse jumbo.MOLECULE.class aufgerufen.

CML wird ständig weiterentwickelt und unterstützt von der Open Molecule Foundation. Die OMF bietet eine kostenlose CD-ROM an, welche das Potential von JUMBO zeigt. CML wird mit MathML zusammenarbeiten, eine XML-Anwendung zur Präsentation, Austausch und Ausführung von Mathematik im Internet.

 

4.2. Extensible Hypertext Markup Language

Extensible Hypertext Markup Language ist eine Anwendung von XML 1.0 und eine Neuformulierung von HTML 4.0 durch eine Arbeitsgruppe des WWW-Konsortiums. In Anlehnung zu HTML 4.0 wurden drei ähnliche Dokumenttypdeklarationen geschrieben.

XHTML ist erweiterbar, es lassen sich also neue Elemente und Attribute definieren. Ein XHTML-Dokument muß einige Kriterien erfüllen. So muß z.B. das Dokument gültig sein zu einer der drei DTD's, welche unter www.w3.org/TR/xhtml1/DTD/ zu finden sind. Weiterhin muß das root-Element <html> sein. Das folgende Beispiel zeigt, welche Form ein XHTML-Dokument mindestens haben muß.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/strict.dtd">
<html xmlns="http://www.w3.org/TR/xhtml1">
<head>
<title>XHTML - document</title>
</head>
<body>
<p>A very short document.</p>
</body>
</html>

Ein HTML-Dokument ist kein gültiges XHTML-Dokument. Es gibt Unterschiede, die beachtet werden müssen. So dürfen keine überlappenden Elemente vorkommen, Element- und Attributnamen müssen klein geschrieben werden und Elemente müssen ein End-Tag besitzen usw.

XHTML kann eine große Zukunft im Internet haben. Zwar sind die bestehenden HTML-Dokumente nicht gültig zu einer der drei DTD's aber diese Transformation sollte sich auch automatisieren lassen.

4.3 Tamino - Informationsserver

Tamino ist ein Informationsserver für Electronic Business und wurde von der Software AG entwickelt. E-Business wird bestimmt durch geschäftliche Transaktionen im Internet. Tamino ist ein Informationsserver, da alle Arten von Informationen unterstützt werden. Zur CeBIT99 wurde Tamino vorgestellt und soll Ende dieses Jahr erhältlich sein. Mittels Tamino können heterogene Daten vereinheitlicht werden. Dies ist dadurch möglich, daß die in XML strukturierten Daten als diese abgespeichert werden und nicht in Tabellen und Spalten eines relationalen Schemas gepreßt werden. Da die Struktur der XML-Daten erhalten bleibt, verspricht Tamino sehr hohe Speicher- und Zugriffsgeschwindigkeiten. Folgende Merkmale gibt der Hersteller an.

Einige Merkmale von Tamino

Systemarchitektur von Tamino (Abb4)

Abb4: Tamino Architektur

X-Machine ist der Hochleistungskernel zum Abspeichern und wieder Auslesen von XML-Daten. X-Machine verwaltet alle Datenformate wie XML, Texte, Bilder usw. X-Node ermöglicht den Zugang zu bestehenden Datenbanken mit traditionellen Datenstrukturen. X-Node kann diese Daten zu XML-Daten transformieren. Somit kann Tamino als Server für bestehende Datenbanken über das Internet und mit Internet-basierenden Anwendungen agieren. SQL Engine erlaubt das Speichern von SQL-Daten. SQL-Daten können auch Teile von XML-Dokumenten sein. Außerdem können Anwendungen, welche relationale Datenbankschemas verwenden, auf der selben Plattform laufen wie Tamino. Mit dem X-Manager kann der Administrator alle XML-Daten zu internen Daten transformieren und er kann administrieren. Data Map beinhaltet DTD's, style sheets, relationale Schemas usw. Data Map bestimmt außerdem, wie XML-Daten physikalisch in die Datenbank gespeichert wird.

 

5. Zusammenfassung und Ausblick

Die XML-Beschreibung wurde vom W3C im Februar 1998 als ein Standard angenommen. In dieser Ausarbeitung wurde zuerst die Einordnung von XML zu HTML und SGML geklärt und darauf wurden die Entwicklungsziele des W3C dargelegt. Im ersten Hauptteil wurde eine technische Einführung in XML gegeben. Die DTD spielt dabei eine wichtige Rolle, da diese die Syntax von XML-Daten vorschreibt. Im zweiten Hauptteil wurde eine Anfragesprache auf XML-Dokumenten vorgestellt, um zu zeigen, wie man mit XML-Dokumenten arbeiten kann. Ob sich dieser Weg oder ein anderer Weg durchsetzen wird und ob diese Anfragesprache eine gute Performance hat, läßt sich jetzt noch nicht sagen. Im dritten und letzten Hauptteil wurden Anwendungen vorgestellt. Viele Experten glauben, daß XML das dominante Datenaustauschformat im Internet werden wird. Nach [PR98] wird dies in 3 Phasen geschehen.

1. Phase, Daten in XML: Das Senden von XML-Inhalten zu Browsern im Internet ermöglicht erhebliche Einsparung von Ladezeiten zwischen dem Server und dem Klienten. Sortierungen, Gruppierungen usw. können lokal auf dem Klienten durchgeführt werden. Somit wird das ständige Hin- und Hersenden von Daten unterbunden. Den Klienten ist es möglich, auf denselben gut strukturierten Daten verschiedene Ansichten für verschiedene Benutzer zu erstellen. Phase 1 ist ein gewaltiger Schritt in Richtung Austausch von strukturierten Daten im Internet.

2. Phase, Daten und Anfragen in XML: Internetseiten werden ihre Anfragemöglichkeiten durch XML beschreiben, um die Integration von individuellen Webseiten in strukturierten Suchmaschinen zu erleichtern. Hauptnutzen in XML liegen im Austausch von strukturierten Daten und in der Anfragenmöglichkeit auf ihnen. Es wird ermöglicht, benutzerspezifische Anfragen auf dieselben Webseiten zu legen.

3. Phase, Daten, Anfragen und Transaktionen in XML: Phase 3 wird die Virtualisierung von Organisationen beschleunigen. Konsumenten erhalten dann per Internet vollen Service, welcher ja schon heute mehr oder weniger in manchen Branchen praktiziert wird, z.B. Online-Banking. Virtuelle Datenbanktechnologie wird die Basis für virtuelle Organisationen sein.

 

6. Literaturverzeichnis