XML - Grundlagen, Prinzipien und Anwendungen

Aufgabe 1 (XML DTD)

Erstellung einer DTD und eines entsprechenden XML Dokuments

Abgabe bis Montag 17.4.2006

Hinweis: Falls ihr Fragen zur Übung habt, könnt ihr euch während der Übungsstunden an den Betreuer Hasan wenden, der an tardis-b03 sitzt.

Ziel dieser Aufgabe ist es, XML auf seiner grundlegenden Ebene kennenzulernen. Dazu sollen Informationen über verschiedene Musikstücke (z.B. MP3-Dateien) in einem XML-Dokument beschrieben und anschliessend auch verknüpft werden, das heisst die Beziehungen zwischen den verschiedenen im Dokument enthaltenen Informationen sollen ebenfalls im Dokument dargestellt werden. Zusätzlich soll sichergestellt werden, dass das Dokument eine vorgegebene Struktur und Form einhält, was seine elektronische Weiterverarbeitung ermöglicht. Hierzu soll eine Document Type Definition (DTD) erstellt werden, welche dem XML-Dokument zu grunde liegt. Das XML-Dokument muss also der DTD entsprechen. Das Design einer solchen XML DTD bestimmt massgeblich den Erfolg eines XML-basierten Projektes, so wie das Datenbankdesign auch der Kernpunkt jeder Datenbank-basierten Anwendung ist.

Aufgabe Tips

	Aufgabe	Tips
1.	Im ersten Teil der Aufgabe soll eine DTD zur Darstellung von Musikstücklisten geschrieben werden. Diese kann dann verwendet werden, um Informationen über verschiedene Musikstücke zu archivieren. Die DTD muss also so flexibel geschrieben sein, dass sie für unterschiedliche Musikstücke geeignet ist, also z.B. sowohl Musikstücke einzelner Interpreten als auch ganzer Bands. Aus diesem XML-Dokument kann man hinterher zum Beispiel Darstellungen erzeugen, wie sie allmusic.com liefert. Dazu müsst ihr euch überlegen, welche wesentlichen Eigenschaften so ein Musikstück hat, die zum Beispiel für seine Archivierung oder sein Abspielen relevant sind. Ein weiteres Beispiel für die Eigenschaften von Musikstücken sind die im MP3-Format enthaltenen Metadaten, welche dem ID3-Format folgen (siehe auch http://www.id3.org). Dabei ist insbesondere die Beschreibung der Inhalte der ID3v2.4-Frames interessant. Ziel des DTD-Designs muss immer sein, eine DTD zu schreiben, die nicht nur für genau ein Dokument verwendet werden kann.	DTD-Design setzt (wie auch Datenbankdesign) voraus, dass man sich zuerst einmal Gedanken über die zu strukturierenden Daten macht. Dazu solltet Ihr Euch überlegen, was allgemeine und wiederkehrende Strukturierungsmerkmale der Dokumente sind, für die Ihr die DTD schreibt. Danach müsst Ihr entscheiden, welche Elemente es geben soll, wie diese kombiniert werden dürfen, und welche Attribute welchen Typs diese Elemente tragen können, Als letzten Schritt müsst Ihr diese Design-Entscheidungen in XML DTD-Syntax bringen und damit weiterverarbeitbar für ein XML-System machen. Am Anfang ist es ratsam, zunächst mit einer sehr einfachen DTD zu beginnen und sie zu validieren. Diese könnt ihr dann anschliessend schrittweise erweitern. Ihr könnt dabei das im obigen Bild vereinfacht dargestellte Datenmodell als Vorschlag fuer die Strukturierung der DTD verwenden. Es zeigt sämtliche Elemente mit ihren Attributen, sowie Referenzen zwischen diesen Attributen und Abbildung von Elementen auf einen elementaren Datentyp Text (entspricht #PCDATA). Natürlich müsst ihr euch dann immer noch Gedanken über das Auftreten der Elemente (genau eins, immer mehrere, eins von mehreren, ...) etc. machen. WICHTIG: Achtet besonders darauf, dass die XML DTD an inhaltlichen Kriterien orientiert ist, also nicht einfach eine Beschreibung der Präsentation eines Dokuments darstellt!
2.	Damit Ihr nicht nur extrem simple DTDs erzeugt, muss Eure DTD mindestens den folgenden Anforderungen genügen: Jeder der XML Occurrence Indicators (`?`, `+` und `*`) muss mindestens einmal (sinnvoll!) verwendet werden. Es muss `#REQUIRED` und `#IMPLIED` Attribute geben. Es müssen ID Referenzen verwendet werden, das heisst es muss mindestens ein Attribut vom Typ `ID` geben und eines vom Typ `IDREF`, welches auf ersteres verweist. Mindestens ein Element muss in verschiedenen Kontexten wiederverwendet werden (also im Content Model verschiedener Elemente verwendet werden). Es müssen alle möglichen Inhaltsmodelle von XML DTDs verwendet werden, d.h. `Element Only`, `Mixed` (mit und ohne Elementen) oder `Empty`. Die Element-Hierarchie muss mindestens dreistufig sein.	Es gibt für alle diese Bedingungen sehr sinnvolle Anwendungen, und Ihr solltet darauf achten, diese auch zu finden in Eurer DTD. Die Occurrence Indicators kann man gut für komplexe Content Models verwenden, Attribute sind oftmals einfach zu unterscheiden zwischen `#REQUIRED` und `#IMPLIED`, wiederverwendete Elemente sind ein wichtiges Zeichen für gute Datenmodellierung (generell solltet Ihr vermeiden, irgendwelche Teile deiner DTD mit Copy/Paste zu erzeugen, das ist fast nie eine gute Art der Modellierung). ID Referenzen solltet ihr vor allem dazu verwenden, eure Daten zu normalisieren, d.h. mehrmals vorkommende Daten nicht auch mehrmals aufzuführen, sondern durch eine Referenz einzubinden. Dies gilt zum Beispiel für mehrere Musikstücke des gleichen Künstlers. Ein schlankes, aber dennoch sehr hilfreiches Nachschlagewerk stellt die im O'Reilly-Verlag erschienene XML Pocket Reference dar. Ansonsten existieren zahlreiche Web-Seiten zum Thema, so zum Beispiel XML.com oder XML.org.
3.	Im dritten Schritt der Aufgabe geht es darum, ein XML-Dokument (eine Instanz der DTD) zu schreiben. Dazu müsst ihr eine Musikstückliste erstellen, welche wiederum mindestens zwei verschiedene Musikstücke enthält. Das XML-Dokument muss dabei valide gemäss eurer in den Schritten 1 und 2 erzeugten DTD sein.	Ob das von euch erzeugten XML-Dokument der DTD entspricht lässt sich am einfachsten mit automatischen Validators überprüfen, welche zahlreich im WWW verfügbar sind (ein Link dazu am Ende dieser Seite).

Im ersten Teil der Aufgabe soll eine DTD zur Darstellung von Musikstücklisten geschrieben werden. Diese kann dann verwendet werden, um Informationen über verschiedene Musikstücke zu archivieren. Die DTD muss also so flexibel geschrieben sein, dass sie für unterschiedliche Musikstücke geeignet ist, also z.B. sowohl Musikstücke einzelner Interpreten als auch ganzer Bands. Aus diesem XML-Dokument kann man hinterher zum Beispiel Darstellungen erzeugen, wie sie allmusic.com liefert.

Dazu müsst ihr euch überlegen, welche wesentlichen Eigenschaften so ein Musikstück hat, die zum Beispiel für seine Archivierung oder sein Abspielen relevant sind. Ein weiteres Beispiel für die Eigenschaften von Musikstücken sind die im MP3-Format enthaltenen Metadaten, welche dem ID3-Format folgen (siehe auch http://www.id3.org). Dabei ist insbesondere die Beschreibung der Inhalte der ID3v2.4-Frames interessant.

Ziel des DTD-Designs muss immer sein, eine DTD zu schreiben, die nicht nur für genau ein Dokument verwendet werden kann.

DTD-Design setzt (wie auch Datenbankdesign) voraus, dass man sich zuerst einmal Gedanken über die zu strukturierenden Daten macht. Dazu solltet Ihr Euch überlegen, was allgemeine und wiederkehrende Strukturierungsmerkmale der Dokumente sind, für die Ihr die DTD schreibt. Danach müsst Ihr entscheiden, welche Elemente es geben soll, wie diese kombiniert werden dürfen, und welche Attribute welchen Typs diese Elemente tragen können, Als letzten Schritt müsst Ihr diese Design-Entscheidungen in XML DTD-Syntax bringen und damit weiterverarbeitbar für ein XML-System machen.

Am Anfang ist es ratsam, zunächst mit einer sehr einfachen DTD zu beginnen und sie zu validieren. Diese könnt ihr dann anschliessend schrittweise erweitern.

Ihr könnt dabei das im obigen Bild vereinfacht dargestellte Datenmodell als Vorschlag fuer die Strukturierung der DTD verwenden. Es zeigt sämtliche Elemente mit ihren Attributen, sowie Referenzen zwischen diesen Attributen und Abbildung von Elementen auf einen elementaren Datentyp Text (entspricht #PCDATA). Natürlich müsst ihr euch dann immer noch Gedanken über das Auftreten der Elemente (genau eins, immer mehrere, eins von mehreren, ...) etc. machen.

WICHTIG: Achtet besonders darauf, dass die XML DTD an inhaltlichen Kriterien orientiert ist, also nicht einfach eine Beschreibung der Präsentation eines Dokuments darstellt!

Damit Ihr nicht nur extrem simple DTDs erzeugt, muss Eure DTD mindestens den folgenden Anforderungen genügen:

Jeder der XML Occurrence Indicators (?, + und *) muss mindestens einmal (sinnvoll!) verwendet werden.
Es muss #REQUIRED und #IMPLIED Attribute geben.
Es müssen ID Referenzen verwendet werden, das heisst es muss mindestens ein Attribut vom Typ ID geben und eines vom Typ IDREF, welches auf ersteres verweist.
Mindestens ein Element muss in verschiedenen Kontexten wiederverwendet werden (also im Content Model verschiedener Elemente verwendet werden).
Es müssen alle möglichen Inhaltsmodelle von XML DTDs verwendet werden, d.h. Element Only, Mixed (mit und ohne Elementen) oder Empty.
Die Element-Hierarchie muss mindestens dreistufig sein.

Es gibt für alle diese Bedingungen sehr sinnvolle Anwendungen, und Ihr solltet darauf achten, diese auch zu finden in Eurer DTD. Die Occurrence Indicators kann man gut für komplexe Content Models verwenden, Attribute sind oftmals einfach zu unterscheiden zwischen #REQUIRED und #IMPLIED, wiederverwendete Elemente sind ein wichtiges Zeichen für gute Datenmodellierung (generell solltet Ihr vermeiden, irgendwelche Teile deiner DTD mit Copy/Paste zu erzeugen, das ist fast nie eine gute Art der Modellierung). ID Referenzen solltet ihr vor allem dazu verwenden, eure Daten zu normalisieren, d.h. mehrmals vorkommende Daten nicht auch mehrmals aufzuführen, sondern durch eine Referenz einzubinden. Dies gilt zum Beispiel für mehrere Musikstücke des gleichen Künstlers.

Ein schlankes, aber dennoch sehr hilfreiches Nachschlagewerk stellt die im O'Reilly-Verlag erschienene XML Pocket Reference dar. Ansonsten existieren zahlreiche Web-Seiten zum Thema, so zum Beispiel XML.com oder XML.org.

3. Im dritten Schritt der Aufgabe geht es darum, ein XML-Dokument (eine Instanz der DTD) zu schreiben. Dazu müsst ihr eine Musikstückliste erstellen, welche wiederum mindestens zwei verschiedene Musikstücke enthält. Das XML-Dokument muss dabei valide gemäss eurer in den Schritten 1 und 2 erzeugten DTD sein. Ob das von euch erzeugten XML-Dokument der DTD entspricht lässt sich am einfachsten mit automatischen Validators überprüfen, welche zahlreich im WWW verfügbar sind (ein Link dazu am Ende dieser Seite).

Die Abgabe der Übung besteht darin, die URI einer Seite, auf der eine kurze Erklärung der DTD steht, an den Betreuer (hasan@tik.ee.ethz.ch) zu mailen. Die Seite muss zusätzlich Links auf die DTD und das XML-Dokument (also die DTD-entsprechende Musikstückliste) enthalten. Die Überprüfung der Übung durch den Betreuer besteht darin, nachzuschauen, ob die Aufgabe korrekt gelöst wurde, d.h. DTD und XML syntaktisch korrekt sind, die DTD eine sinnvolle Gliederung ermöglicht und allgemein wiederverwendbar ist, und ob das XML-Dokument eine valide Instanz der DTD ist. Desweiteren wird überprüft, ob die erstellten Dokumente den im zweiten Schritt genannten Anforderungen genügen.

Schritt 1 (Erstellen einer DTD)

Eine XML DTD ist ein normales ASCII-File, das meistens die Extension .dtd trägt. Im Unterschied zu XML Dokumenten, die die bekannte HTML-ähnliche Syntax haben, verwendet XML für die Beschreibung einer DTD jedoch eine andere Syntax. Diese Syntax ist als Grammatik im XML Standard definiert, dieser ist jedoch nicht besonders einfach les- oder als Referenz benutzbar. Das beste ist, mit einer einfachen Beispiel-DTD zu beginnen, die einige wenige Elemente enthält, und sich auf diese Weise mit der DTD-Syntax anzufreunden.

Wer interessiert daran ist, XML genau kennenzulernen, der sollte natürlich mal einen Blick in den Standard werfen, der auf der Web-Seite des World Wide Web Consortium zu finden ist. Und wem das auf Englisch zu mühsam ist, der kann sich die deutsche Übersetzung des Standards ansehen.

Um zu überprüfen, ob die DTD tatsächlich korrekt ist, empfiehlt es sich, die DTD zu validieren, also auf Korrektheit zu überprüfen. Dies kann entweder mit einem lokal zu installierenden Programm (auf dem Netz schwirren zahllose herum), oder mit einem über das Netz verfügbaren Validator-Tool geschehen. Welche Variante Ihr wählt, bleibt Eurem Geschmack überlassen, auf jeden Fall werden invalide DTDs von uns mehr oder minder kommentarlos abgelehnt werden.

In den meisten Fällen könnt Ihr dann übrigens das Validator-Tool, sei es nun lokal installiert oder über das Netz verfügbar, auch zum Validieren der XML Dokumente gegen die DTD verwenden, so dass Ihr bei Verwendung eines solchen Tools zwei Fliegen mit einer Klappe schlagen könnt. Ihr solltet Euch von solchen Tools aber auch nicht das Denken abnehmen lassen (zumindest nicht bei dieser Aufgabe), sondern selber ein bisschen Mühe darin investieren, sozusagen im Kopf zu validieren...

Schritt 2 (Erstellen einer komplexeren DTD)

Im ersten Schritt habt Ihr vielleicht eine DTD erzeugt, die sehr einfach ist, und nur eine grobe Strukturierung der von Euch gewählten Informationen ermöglicht. Das ist als Beginn des DTD-Schreibens auch gut so und sinnvoll im Sinne eines Top-Down Ansatzes.

Im zweiten Schritt ist es am einfachsten, wenn Ihr die DTD inkrementell verfeinert (so z.B. aus einem Name Element mit einem (#PCDATA) Content Model ein Name Element mit einem (Titel?, Vorname+, Nachname) Content Model macht, die Ihrerseits als Elemente definiert werden), und auf diese Weise einen feineren Zugriff auf die verschiedenen Inhalte der später zu erzeugenden Instanzen ermöglicht. Eine weitere Art der Verfeinerung könnte das Hinzufügen von Attributen sein (so könnte das Titel Element mit einem Attribut ergänzt werden, das angibt, ob der Titel beim Erzeugen von Inhalten verwendet werden soll).

Hint: Besonders wichtig ist in diesem Fall, dass ihr euch überlegt, welche Teile der Musikstückeigenschaften häufig gleich sind und deshalb über Referenzen eingebunden werden sollten. Dies hat den Vorteil, dass sich dann hinterher Musikstücke mit gleichen Eigenschaften einfacher finden lassen.

Es ist oftmals eine Designentscheidung und keine Frage von objektiv "richtig" oder "falsch", in welcher Weise man Daten modelliert bzw. strukturiert. Ihr solltet beim Design Eurer DTD allerdings bedenken, dass Ihr in späteren Aufgaben die Inhalte Eurer XML Dokumente (oder zumindest wichtige Teile davon) nach XHTML transformieren sollt, und je besser und logischer Ihr Eure Daten jetzt strukturiert, desto einfacher wird Euch diese Aufgabe dann fallen.

Schritt 3 (Erstellen eines XML Dokuments gemäss DTD)

In diesem Schritt soll nun ein XML-Dokument erstellt werden, das der in Schritt 1 erzeugten DTD entspricht. Dazu gibt es nun zwei grundlegende Möglichkeiten:

Es wird ein normaler Text-Editor verwendet, in dem das XML Dokument erstellt wird. Wir empfehlen diesen Weg, weil man auf diese Weise am besten ein Gefühl für die Syntax von XML bekommt.
Es kann ein XML-Editor verwendet werden, der aufgrund der DTD das erstellen einer Instanz gemäss der DTD ermöglicht. Der Vorteil von solch einem syntaxgesteuerten Editor ist, dass man gar kein falsches Dokument erzeugen kann. Der Nachteil ist, dass man es dann auch nie tut, und einem dadurch wahrscheinlich ein paar interessante Erkenntnisse verlorengehen... Eines der XML-Editoren ist der Exchanger XML (die Lite-Version: Exchanger XML Lite V3.2 ist gratis verfügbar).

Der Exchanger XML Lite V3.2 ist auf den tardis-Rechnern installiert und kann mit dem folgenden Befehl aufgerufen werden:

$ ~xml06_00/xngrlite

Wie auch immer Ihr das XML erstellt, wie bei der DTD gilt auch hier, dass wir syntaktisch inkorrektes XML (sei es nun nicht einmal well-formed oder zwar well-formed aber nicht valid) relativ kommentarlos ablehnen werden, Tools zur Validierung stehen, neben dem XML Editor, vielfältige zur Verfügung und sollten auch genutzt werden. Ein Beispiele dafür ist die XML Validation Form der Brown University. Falls Ihr weitere online Tools suchen oder etwas lokal installieren wollt, ist (wie immer) die entsprechende Cover Page ein exzellenter Startpunkt.

WICHTIG: Beim Überprüfen der Lösung durch den Betreuer wird der erwähnte Validator der Brown University verwendet, welcher zum Teil kritischer ist als der in emacs integrierte. Bevor ihr eure Lösung abgebt, testet sie also bitte einmal mit diesem Validator. Danke!

please send comments to xml-vl@dret.net
last modification on Tuesday, 04-Jul-2006 10:16:48 CEST