last modification on Sunday, 03-Jun-2001 16:43:50 CEST
Ziel dieser Aufgabe ist es, XML auf der grundlegendsten Ebene kennenzulernen. Das Design einer XML Document Type Definition (DTD) bestimmt massgeblich den Erfolg eines XML-basierten Projektes, so wie das Datenbankdesign auch der Kernpunkt jeder Datenbank-basierten Anwendung ist. Um die Theorie einer DTD (die ein Dokumenten-Schema beschreibt) in der Praxis umzusetzen (also Dokumente gemäss eines solchen Schemas zu erzeugen), müssen in dieser Aufgabe ausserdem mindestens zwei XML Dokumente geschrieben werden, die der selbstgeschriebenen DTD entsprechen.
| Aufgabe | Tips | |
|---|---|---|
| 1. | Im ersten Teil der Aufgabe soll eine DTD für die eigenen Web-Seiten geschrieben werden. Diese DTD soll so flexibel sein, dass sie nicht nur dazu dienen kann, die in Aufgabe 1 geschriebene eigene Homepage in XML zu codieren, sondern zudem entweder
| DTD-Design setzt (wie auch Datenbankdesign) voraus, dass man sich zuerst einmal Gedanken über die zu strukturierenden Daten macht. Ihr solltet also zuerst einmal entscheiden, welche der drei Möglichkeiten Ihr implementieren wollt. Danach 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.
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:
| 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, und Parameter Entities kann man gut verwenden, um redundante Definitionen bei Content Models oder Attributlisten zu vermeiden (generell solltet Ihr vermeiden, irgendwelche Teile deiner DTD mit Copy/Paste zu erzeugen, das ist fast nie eine gute Art der Modellierung).
|
| 3. | Im dritten Schritt der Aufgabe geht es darum, zwei XML Dokumente (jeweils eine Instanz der DTD) zu schreiben. Dazu könnt Ihr z.B. Eure Homepage aus Aufgabe 1 nehmen, und den Inhalt dieser Seite von HTML nach XML transformieren, und zwar so, dass es XML gemäss der von Euch in Schritt 1 erzeugten DTD ist. | In diesem Schritt wird (so ist zumindest die Idee...) klar, dass das automatische Erzeugen von XML aus HTML schwierig, oder in den meisten Fällen sogar unmöglich ist. Dies liegt daran, dass die XML DTD inhaltliche Aspekte beschreibt, die im HTML gar nicht repräsentiert werden konnten. Natürlich könnte man auch eine XML DTD schreiben, die kaum inhaltliche Aspekte transportieren kann (ein Beispiel dafür ist die XHTML DTD), aber in den meisten Fällen ist das nicht das Ziel einer XML DTD. |
Die Abgabe der Übung besteht darin, die URI einer Seite, auf der eine kurze Erklärung der DTD steht, an den Betreuer (www-vl@dret.net) zu mailen. Die Seite muss zusätzlich Links auf die DTD und die beiden XML Dokumente (also z.B. Eure XML Homepage in zwei Varianten gemäss der DTD) 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 die XML Dokumente valide Instanzen der DTD sind.
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 (aber Achtung: Die englische Version gibt es bereits in der "Second Edition", in der einige Fehler korrigiert wurden, die deutsche Übersetzung ist jedoch noch die erste Version des Standards).
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...
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).
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 Aufgabe 7 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.
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:
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 vielfältige zur Verfügung und sollten auch genutzt werden. Beispiele dafür sind das XML Validation Form der Brown University oder der XML well-formedness Checker and Validator. Falls Ihr weitere online Tools suchen oder etwas lokal installieren wollt, ist (wie immer) die entsprechende Cover Page ein exzellenter Startpunkt.
| please send comments to www-vl@dret.net last modification on Sunday, 03-Jun-2001 16:43:50 CEST |
|