Kapitel 3 Einführung XML

3.1 Einleitende Beispiele 56

3.2 Software 59

3.3 Schnelleinstieg 66

3.4 Document Type Definition (DTD) 76

3.5 XML Beschreibung 99

3.6 XML Data Island 101

3.7 XML-Dokumente im Browser anzeigen 102

3.8 Erweiterte XML-Syntax 104

3.1 Einleitende Beispiele

Als Einstieg ins das Thema XML und um Ihnen eine Idee zu geben, wie die neue Sprache sinnvoll eingesetzt werden kann, werden wir zunächst zwei kleine Praxisbeispiele vorstellen. Bestimmt sind diese schon ein Anstoß für eigene Umsetzungen und eine Hilfe für das Verständnis der Extensible Markup Language. Zusätzlich werden wir die Beispiele mit einer Umsetzung in HTML vergleichen, um Parallelen und Unterschiede der beiden Auszeichnungssprachen deutlich zu machen.

3.1.1 Beispiel: CD-Sammlung

Eine einfache Verwaltung einer CD-Sammlung ist im folgenden Beispiel aufgeführt. Eingeleitet wird die Datei mit dem Hinweis auf die verwendete XML-Version. Das umschließende Markup <CDSAMMLUNG> bildet das Wurzelelement des Dokuments. Die einzelnen CDs unserer - mit zwei CDs zugegeben etwas mageren - Sammlung sind durch das Element <ALBUM> umschlossen. Innerhalb der <ALBUM>-Deklaration finden wir alle Informationen über eine einzelne CD.

<?xml version="1.0"?>
<CDSAMMLUNG>
   <ALBUM>
      <INTERPRET>Billy Joel</INTERPRET>
      <TITEL>River of Dreams'</TITEL>
      <LABEL>Sony Music</LABEL>

      <TRACK>No Man's Land</TRACK>
      <TRACK>The Great Wall Of China</TRACK>
      <TRACK>Blonde Over Blue</TRACK>
      <TRACK>A Minor Variation</TRACK>
      <TRACK>Shades Of Grey</TRACK>
      <TRACK>All About Soul</TRACK>
      <TRACK>Lullabya</TRACK>
      <TRACK>The River Of Dreams'</TRACK>
      <TRACK>Two Thousand Years</TRACK>
      <TRACK>Famous Last Words</TRACK>
   </ALBUM>

   <ALBUM>
      <INTERPRET>Madonna</INTERPRET>
      <TITEL>Ray of light</TITEL>
      <LABEL>Drowned world</LABEL>

      <TRACK>Swim</TRACK>
      <TRACK>Ray of light</TRACK>
      <TRACK>Candy perfume girl</TRACK>
      <TRACK>Skin</TRACK>
      <TRACK>Nothing really matters</TRACK>
      <TRACK>Sky fits heaven</TRACK>
      <TRACK>Shanti</TRACK>
      <TRACK>Frozen</TRACK>
      <TRACK>The power of good-bye</TRACK>
      <TRACK>To have and not to hold</TRACK>
      <TRACK>Little star</TRACK>
      <TRACK>Mer girl</TRACK>
   </ALBUM>
</CDSAMMLUNG>

Abb. 3.18: Unser Beispiel angezeigt im Editor Microsoft XML Notepad.  Das Programm liegt der CD-ROM zum Buch bei.

Als HTML-Dokument mit gleichem Textinhalt würden wir die einzelnen Elemente vielleicht in eine Tabelle integrieren, um so eine gewisse Übersichtlichkeit herzustellen:

<HTML>
<HEAD>
<TITLE>CD-Sammlung</TITLE>
</HEAD>
<BODY>
<TABLE BORDER>
      <TR><TD>Billy Joel</TD></TR>
      <TR><TD>River of Dreams'</TD></TR>
      <TR><TD>Sony Music</TD></TR>
      <TR><TD>No Man's Land</TD></TR>
      <TR><TD>The Great Wall Of China</TD></TR>
      <TR><TD>Blonde Over Blue</TD></TR>
      <TR><TD>A Minor Variation</TD></TR>
      <TR><TD>Shades Of Grey</TD></TR>
      <TR><TD>All About Soul</TD></TR>
      <TR><TD>Lullabya</TD></TR>
      <TR><TD>The River Of Dreams'</TD></TR>
      <TR><TD>Two Thousand Years</TD></TR>
      <TR><TD>Famous Last Words</TD></TR>
      </TABLE>
<TABLE BORDER>
      <TR><TD>Madonna</TD></TR>
      <TR><TD>Ray of light</TD></TR>
      <TR><TD>Drowned world</TD></TR>
      <TR><TD>Swim</TD></TR>
      <TR><TD>Ray of light</TD></TR>
      <TR><TD>Candy perfume girl</TD></TR>
      <TR><TD>Skin</TD></TR>
      <TR><TD>Nothing really matters</TD></TR>
      <TR><TD>Sky fits heaven</TD></TR>
      <TR><TD>Shanti</TD></TR>
      <TR><TD>Frozen</TD></TR>
      <TR><TD>The power of good-bye</TD></TR>
      <TR><TD>To have and not to hold</TD></TR>
      <TR><TD>Little star</TD></TR>
      <TR><TD>Mer girl</TD></TR>
</TABLE>

</BODY>
</HTML>

An diesem Beispiel wird der Unterschied zwischen XML und HTML sehr gut deutlich. Obwohl die Information, bei welchem Text es sich um einen Titel und bei welchem um den Namen des Interpreten handelt, vielleicht für die Weiterverarbeitung noch einmal wichtig werden kann, sind diese strukturellen Informationen im HTML-Dokument völlig verloren gegangen.

Während es in der XML-Datei darum ging, Struktur in die vorhandenen Textdaten zu bringen, ist man bei der Verwendung von HTML ausschließlich damit beschäftigt sich um die Ausgabe auf den Bildschirm zu konzentrieren.

Waren Sie bisher gewohnt in HTML zu programmieren und zu denken müssen Sie sich jetzt umstellen. Überlegen Sie nicht mehr, wie dieses oder jenes Element auf dem Bildschirm wirken könnte und ob eine Tabelle oder doch lieber eine Fettschrift sich optisch besser macht. Nebenbei: Diese Aspekte werden bei XML nicht völlig ausgeklammert, doch darum kümmert sich in erster Linie die Stylesheet-Sprache XSL.

Vergessen Sie also physische Auszeichnungen und konzentrieren Sie sich ganz auf den Inhalt, der mit semantischen Auszeichnungen seine Struktur erhält.

Abb. 3.19: In einem HTML-Browser

3.1.2 Beispiel: Informationsverwaltung

Eine noch etwas weiter verzweigte Struktur enthält unser zweites Beispiel. Es verwaltet in einer Liste die Zitate bekannter Persönlichkeiten. Neben den Zitaten selbst sind noch die Namen und einige Daten des Zitierenden integriert.

<?xml version="1.0">
<LISTE>
   <PERSON>
      <NAME>John Osborne</NAME>
      <INFO>engl. Dramatiker</INFO>
      <GEBOREN>1929</GEBOREN>
      <GESTORBEN/>
      <ZITAT>
         <TEXT>
         Der Computer ist die logische Weiterentwicklung
         des Menschen: Intelligenz ohne Moral.
         </TEXT>
         <WANN>1976</WANN>
      </ZITAT>
      <ZITAT>
         <TEXT>
         Die Historiker sind so etwas wie die
         Schminkmeister des großen Welttheaters.
         </TEXT>
         <WANN>1963</WANN>
      </ZITAT>
   </PERSON>

   <PERSON>
      <NAME>Helmar Nahr</NAME>
      <INFO>dt. Mathematiker</INFO>
      <GEBOREN>1931</GEBOREN>
      <GESTORBEN/>
      <ZITAT>
         <TEXT>
         Beispiele sind die Schwimmbojen der Logik.
         </TEXT>
         <WANN>1972</WANN>
      </ZITAT>
   </PERSON>
</LISTE> (siehe Abb. 3.3)

Also ist auch eine komplexere Datenstruktur mithilfe von XML umsetzbar und kann mit entsprechenden Programmen umgesetzt und sichtbar gemacht werden. XML eignet sich hervorragend als einheitliches Format zur Speicherung von komplexen und weniger komplexen, strukturierten Textdaten.

3.2 Software

Gerade eine ganz neue Technologie wie XML bringt es mit sich, dass unterstützende Software zunächst noch Mangelware ist. Im Gegensatz zu HTML, zu dem wir allein hunderte von Editoren finden, sind solche Programme für XML bisher kaum veröffentlicht.

Wir möchten uns daher im nächsten Abschnitt ausführlich mit der vorhandenen oder in der Entwicklung befindlichen Software befassen und einige Programme kurz vorstellen. Denn die Suche nach solcher Software, beispielsweise im Internet, gleicht immer noch eher der Suche nach der Nadel im Heuhaufen.

Trotzdem ist schon heute der Trend der breiten Unterstützung und das Bekenntnis zu XML, insbesondere durch die Industrie zu spüren. Allen voran ist in der Software-Industrie Microsoft eine der treibenden Kräfte dieser Entwicklung. Einerseits fördert Microsoft die Unterstützung von XML durch die eigenen Internet-Browser und die Entwicklung von XSL. Auf der anderen Seite ist besonders die Implementierung in das bestehende Office-Paket 2000 ein großer Schritt. So können sowohl Word 9.0 als auch Excel 9.0 bereits heute Dateien statt im proprietären Format als gültiges XML-Dokument abspeichern.

Abb. 3.20: Die Baumstruktur ist im XML-Editor deutlich zu erkennen.

Weitere Anbieter, beispielsweise Corel für WordPerfect, haben ähnliche Absichten angekündigt. Auch auf leistungsfähige XML-Editoren werden wir nicht mehr lange warten müssen, einige können wir Ihnen hier sogar schon vorstellen. Die Firma SoftQuad, Hersteller des HTML-Editors HotMetal, hat in der weiterentwickelten nächsten Version den Editor XmetaL mit XML-Unterstützung angekündigt. Die Firma Vervet Logic rühmt sich schon heute damit, den ersten XML-fähigen Editor auf den Markt gebracht zu haben.

In erster Linie sind es drei Gruppen von Anwendungen, die wir Ihnen vorstellen möchten:

Browser

Browser mit denen sich XML-Dateien anzeigen lassen sind dadurch das wichtigste Bindeglied zwischen Anwender und den im Dokument enthaltenen Informationen. Nur durch eine konsequente Verbreitung von Browsern, die XML unterstützen, wird sich diese Sprache auch weltweit zum anerkannten Standard für Websites entwickeln können.

Programmiertools / Editoren

Im Grunde genommen reicht, wie bei HTML und jeder anderen textorientierten Markup-Sprache, bereits ein einfacher Texteditor aus, um gültige XML-Dateien zu erstellen. Meist verwendet man für die erstellten Dateien die Extension ».xml«. Aber gerade bei der hohen Komplexität von XML benötigt der Programmierer weitere Hilfsmittel. SGML und XML-Editoren erleichtern die Erstellung und Verwaltung von XML-Dokumenten oder den zugehörigen DTDs.

Den Editor X-Metal von SoftQuad, der sich auch als Trial-Version auf der beiliegenden CD-ROM befindet, beschreiben wir im Kapitel »XML in der Praxis«.

Anwendungen

Da XML sich als Datenformat für jede Art von Informationen nicht nur für die Darstellung im Internet versteht, wird es auch für andere Anwendungen beispielsweise aus dem Druckbereich interessant auf XML als Format zur Speicherung der Daten zu setzen. Außerdem ist das Format auch zur Verarbeitung größerer Mengen strukturierter Daten, wie sie beispielsweise in Datenbankprogrammen auftauchen, einsetzbar. Auch wenn es in diesem Sektor eher als flexibles Austauschformat, denn als Basisformat eingesetzt werden wird.

3.2.1 Verarbeitung von XML-Daten

Zur Verarbeitung von XML-Daten nennt die W3C-Spezifikation zwei Stufen: den so genannten Parser oder Prozessor und die Anwendung. Ausgehend vom XML-Dokument verarbeitet der Parser die Daten und stellt sie aufbereitet den verschiedenen Anwendungen zur Verfügung. Die folgende Übersicht zeigt das Zusammenspiel der einzelnen Instanzen (siehe Abb. 3.4):

Abb. 3.21: Der Parser bereitet die Daten zur Verarbeitung durch die Anwendungen auf.

Im Gegensatz zum Verhalten des Parsers macht die offizielle Spezifikation keinerlei Aussagen über den Umgang der Anwendung mit den erhaltenen Daten. Man unterscheidet zwei Typen von Parsern:

Validierende Parser überprüfen die exakte Gültigkeit, sowie die Wohlgeformtheit des XML-Dokuments und geben bei Verstößen Fehlermeldungen aus. Nicht-validierende Parser überprüfen lediglich Verstöße gegen die Wohlgeformtheit des Dokuments.

Die Aufgabe des Parsers ist es das vorhandene Dokument so aufzubereiten, dass es von der Anwendung weiterverarbeitet werden kann. Dazu gehört neben der Überprüfung auf Fehler auch die Zusammenführung der verschiedenen Bestandteile des Dokuments, die sich möglicherweise in unterschiedlichen Dateien befinden. Zusätzlich sorgt der Parser mithilfe der DOM-Schnittstelle dafür, dass Anwendungen beispielsweise mithilfe einer Script-Sprache auf die Inhalte einzelner Elemente der Seite zugreifen können.

Aufgabe jedes Parsers, ob validierend oder nicht-validierend, ist es den zugrundeliegenden XML-Quelltext zu überprüfen und dem Benutzer oder der Anwendung Verletzungen der Spezifikationen mitzuteilen. Die genaue Überprüfung ist relativ aufwendig, daher verzichten viele Parser darauf zu validieren und führen nur eine einfachere nicht-validierende Kontrolle durch. Bevor ein XML-Dokument veröffentlicht wird sollte man es auf jeden Fall mit einem validierenden Prozessor genau auf Konformität überprüfen.

3.2.2 Browser

Microsoft Internet Explorer 4.0

Der Microsoft Internet Explorer war einer der ersten Browser der eine XML-Unterstützung angeboten hat. Schon dieser Version wurde das Channel Definition Format eingeführt. Es basiert vollständig auf der XML Definition. Diese Push Channel Technologie fasst Websites zu Channels zusammen und enthält außerdem Einstellungen zur Updatehäufigkeit und Aktualisierung der Inhalte.

Für den Microsoft Explorer 4.0 wird ein externer XML Parser als ActiveX-Objekt angeboten.

Microsoft Internet Explorer 5.0

Der Internet Explorer 5.0 verspricht eine umfangreiche XML Unterstützung. Beispielsweise durch den integrierten context-sensitiven XML Parser. Sowohl eine Unterstützung der aktuellen XML 1.0 Version inklusive den Namespaces ist voll umgesetzt, als auch eine XSL-Unterstützung basierend auf dem letzten Entwurf des W3C.

Microsoft Internet Explorer 5.5

Der Internet Explorer 5.5 wird schrittweise zusätzlich um weitere XML-Funktionen erweitert. Dazu gehört beispielsweise eine weitgehende Unterstützung der SMIL-Syntax.

Netscape Communicator 5.0

Netscape bietet mit der künftigen Version 5.0 des Communicators einen verbesserten XML-Parser an. Der Parser ist dabei direkt in den Quellcode des Programms eingebunden und verspricht somit eine hohe Leistungsfähigkeit. Damit setzt Netscape fast alle Empfehlungen des XML Standards um.

Da Netscape den Quellcode des Communicators freigegeben hat, findet die Entwicklung nicht mehr nur innerhalb des Unternehmens statt. Schon wenige Stunden nach der Freigabe der aktuellen Version im Netz waren schon Fehlerkorrekturen zurückgesandt worden. Ein Third-Party-Entwickler hat »Expat«, einen der fortschrittlichsten und aktuellsten Parser in das Software-Produkt, integriert.

Auf der Website http://www.mozilla.org sind aktuelle Hinweise und Quellcodes der aktuellen Browserentwicklungen von Netscape zu finden.

3.2.3 Programmiertools

ADEPT Editor 7.0

Der von ArborText entwickelte Editor ermöglicht es XML-Dokumente zu erzeugen und diese mit Text und Grafiken zu versehen. Sein Einsatzgebiet liegt schwerpunktmäßig in der Entwicklung von Büchern, Katalogen und Nachschlagewerken.

Astoria 3.0

Die amerikanische Firma Chrystal Software entwickelte dieses Content Managementsystem zur Verwaltung von besonders komplexen Dokumenten und technischen Publikationen.

Insbesondere die Verwaltung von technischen Publikationen eines Unternehmens macht es erforderlich neben Programmen zur Erstellung der Dokumente, zusätzliche Tools zur Organisation einzusetzen. Das Programm Astoria 3.0 vereint die große Anzahl anfallender Informationen, wie die Zusammenarbeit verschiedener Autoren, Grafiker und technischer Redakteure, unter einer Oberfläche. So ist eine exakte Kontrolle bereits im Stadium der Entwicklung und Überarbeitung von Inhalten möglich. Über die gesamte Lebensdauer eines Dokuments wird der Inhalt und alle zusätzlich anfallenden Informationen in einer Datenbank verwaltet. Das Verfassen, Überprüfen, Produzieren, Verteilen und Pflegen von Informationen ist also mit einem Produkt möglich.

Abb. 3.22: Das Astoria 3.0 Content Managementsystem

Es wird immer deutlicher, dass der Einsatz eines gezielten Dokumentmanagements dem Unternehmen nicht nur einen subjektiven Informationsvorsprung verschafft, sondern dass sich dieser in einen realen betriebswirtschaftlichen Gewinn umsetzen lässt.

Zusätzliche Module erweitern das Astoria-System. Speziell für die Unterstützung multilingualer Dokumente und der Verwaltung von Übersetzungen (Lingua Translation Management) und zur Veröffentlichung im Internet (Web Services) existieren einzelne Module, um die das Programm erweitert werden kann. Chrystal Software setzte bei der Entwicklung der aktuellen Version von Astoria konsequent auf die Auszeichnungssprache XML zur kontrollierten und präzisen Verarbeitung der Informationen.

Auch in Deutschland setzen zahlreiche große Unternehmen bei ihrer Dokumentenverwaltung auf das Produkt von Chrystal, beispielsweise: Daimler Benz, Debis, Lufthansa und Siemens Nixdorf.

HotMetal Pro

Der HTML-Editor HotMetall Pro von SoftQuad unterstützt in der aktuellen Version XML.

Author Editor 3.5

Der Author Editor von SoftQuad ist ein klassisches Produkt zur Erstellung von SGML Dokumenten. Die aktuellste Version hat allerdings auch schon einige Jahre hinter sich, das letzte Programmupdate stammt von 1996. So dass von XML damals natürlich noch keine Rede war. Das Programm ist in erster Linie ein professioneller SGML-Editor, der sich nur begrenzt für die Erstellung von XML-Dokumenten einsetzen lässt.

Abb. 3.23: Der SGML-Editor Author Editor.

Rules Builder 3.0

Wie der Name uns schon verrät: dieses Programm dient ausschließlich dazu Document Type Definitions zu erstellen. Auch dieses Programm wurde von SoftQuad entwickelt und es ist insbesondere auf die Zusammenarbeit mit dem Author Editor abgestimmt. Für die Erstellung von XML-Document Type Definitions ist auch dieses Programm nur begrenzt geeignet (siehe Abb. 3.7).

Abb. 3.24: Der Rules Builder von SoftQuad.

Microsoft XML Notepad

Das Microsoft XML Notepad ist eine sehr einfache Anwendung um kleine XML-Dokumente zu erstellen. Es befindet sich zurzeit noch in der Entwicklungsphase und wird vielleicht in Zukunft in andere größere Applikationen übergehen.

Mit dem kleinen nützlichen Tool lässt sich zwar noch nicht besonders viel anfangen, aber da echte XML-Programme noch sehr rar auf dem Markt sind, leistet dieses Produkt erste Hilfe. Elemente lassen sich leicht in bereits bestehende XML-Strukturen einfügen. Die Elemente lassen sich schnell mit Attributen und Inhalt versehen und werden noch dazu übersichtlich als Baumstruktur angezeigt (siehe Abb. 3.8).

Abb. 3.25: Das Microsoft XML Notepad.

Adobe Framemaker und Framemaker+SGML

Adobe Framemaker+SGML ist ein Publishing-Tool, mit dem Anwender SGML-Dokumente erstellen, bearbeiten und publizieren können. Nachdem sich Framemaker schon lange als Produkt zur professionellen Dokumentenbearbeitung etabliert hat, erweitert Adobe mit der neuesten Version das Produkt zusätzlich um SGML- und XML-Unterstützung.

Die Dokumenten- und Informationsverwaltung POET Content Management Suite beispielsweise setzt den Framemaker zur Erstellung von Dokumenten, als integrierte Lösung ein.

Abb. 3.26: Framemaker+SGML

XML-Pro

Der Editor von Velvet Logic, der selbst von sich behauptet einer der ersten XML-Editoren zu sein ist mit intuitiver grafischer Oberfläche ausgestattet und ermöglicht so den leichten Zugang zur Erstellung von XML-Dokumenten. Bei der Umsetzung des Programms trat allerdings der Aspekt der Geschwindigkeit in den Hintergrund. So ist eine Bearbeitung von Dokumenten auf langsameren Rechnersystemen nur schleppend möglich.

Abb. 3.27: XML-Pro im Überblick.

POET Content Management Suite

Mit der POET Content Management Suite bietet POET eine flexible und erweiterbare Komplett-Lösung zur Verwaltung von SGML und XML-Dokumenten. Kernstücke der neuen Technologie sind ein Content Server und der Content Client, eine mehrbenutzerfähige und Workgroup-geeignete Oberfläche für das Dokumenten-Management. Für den Zugriff auf die Daten steht außerdem eine Programmierschnittstelle zur Verfügung. Die Content Management Suite unterstützt XML. Diese Elemente erlauben eine Speicherung von komplexen SGML/XML-Inhalten, HTML und zahlreichen weiteren Dokumenten-, Grafik-, Audio- oder Video-Formaten (siehe Abb. 3.11).

Abb. 3.28: Struktur der POET Content Management Suite

Der POET Content Client bietet eine Lösung für die Verwaltung von Dokumenten im Single- und Multiuser-Betrieb. Der Content Client ist als Browser konzipiert und ermöglicht Projekt-Verwaltung, Check-In/Check-Out, die Exploration von Komponenten, Viewing und Versions-Kontrolle. Die Applikation kann sowohl auf lokale Content Datenbanken als auch auf Server-Datenbanken (POET Content Server) zugreifen (siehe Abb. 3.12).

Abb. 3.29: Ein Blick auf die POET Content Management Suite

Der POET Content Server ist optimiert für die Verwaltung von SGML/XML-Daten. Mit der POET Web Factory (Web Server Plug-In) können die Dokumente einer beliebigen POET Content Datenbank im Internet veröffentlicht werden. POET Content Datenbanken können Internet-Anbindung und den Zugriff durch den einen oder mehreren Anwendern über das World Wide Web gleichzeitig verwalten.

Web Valet

Das Programm Web Valet ist ein universeller Editor, der den Entwickler bei der Erstellung seiner Websites unterstützt. Dabei ist Web Valet nicht an eine Sprache gebunden. Befehle lassen sich selbst definieren und einsetzen. Damit lassen sich mit diesem Produkt durchaus XML Dokumente erstellen. Eine breite Unterstützung der XML-Fähigkeiten kann man aber hier nicht erwarten. Das Programm lässt sich lediglich dann einsetzen, wenn eine feste Dokumenten-Struktur bereits feststeht und diese nicht mehr verändert wird.

Abb. 3.30: Der Universal-Editor: Web Valet.

Symposia doc+

Mit Symposia lassen sich problemlos Web Dokumente erstellen. Die Stärke von Symposia liegt in der Erstellung von HTML-Dokumenten. Allerdings ist auch das Einfügen von XML-Tags in der aktuellen Version integriert (siehe Abb. 3.14).

Abb. 3.31: Symposia Doc+

Allaire

Die Firma Allaire entwickelt zurzeit die beiden Programme HomeSite 4.0 und Cold Fusion 4.0. Beide werden in Kürze erwartet und unterstützen XML inklusive Stylesheet-Definitionen. Eine Microsoft-Channel-Definition-Umsetzung ist schon jetzt in HomeSite 3.0 integriert.

3.2.4 Applikationen

Microsoft Office 2000

Die Vision vom übergreifenden Format für alle Anwendungen und Datenstrukturen rückt mit XML ein Stückchen näher. Microsoft hat sich im Office-Paket klar dieser Vision verschrieben. Alle Programme des Office-Pakets können in einem einheitlichen HTML-Format mit XML-Unterstützung aufwarten (siehe Abb. 3.15).

Abb. 3.32: Ein Word-Dokument im Browser.

Der Internet-Explorer 5.0 erkennt anhand des HTML-Quellcodes von welchem Programm die Dokumente erstellt wurden und bietet eine direkte Bearbeitung an. Also steht auch dem lückenlosen Import der entstandenen HTML-Dokumente in vorhandene Applikationen nichts im Wege (siehe Abb. 3.16).

Abb. 3.33: Eine Excel-Tabelle inklusive Diagramm im Internet Explorer.

Abb. 3.34: PowerPoint bietet seine Präsentation komplett im webfähigen Format an.

3.3 Schnelleinstieg

Im folgenden Abschnitt erfahren Sie alles, was Sie für einen schnellen Einstieg in die Sprache XML benötigen. Insbesondere Unterschiede zur HTML-Syntax werden dabei immer wieder hervorgehoben.

3.3.1 Allgemeine syntaktische Hinweise

Gültige Zeichen

Ein XML-Dokument wird in erster Linie im reinen Textformat erstellt. Das Dokument enthält, wie bei einer Auszeichnungssprache üblich, einerseits entsprechend delimitierte Markup-Befehle sowie »normale« Zeichendaten. Ein Zeichen wird in der ISO/IEC 10646 definiert.

Unterstützt die eingesetzte Software diesen Zeichensatz, so können insbesondere deutschsprachige Texte inklusive aller Sonderzeichen und Umlaute eingegeben werden. Neben den Text- und Grafikzeichen des Unicodes sind auch Tabulatoren, Zeilenumbrüche [CR] (carriage return) und Wagenrückläufe [LF] (line feed) einsetzbar.

Windows-Systeme setzen beim Druck auf die Eingabetaste automatisch Carriage Return und Line Feed ein. Dagegen verwenden Unix-Systeme lediglich ein Line Feed für einen Zeilenumbruch. Macintosh Rechner setzen ein Carriage Return ein.

Abb. 3.35: Ein Editor, der zwischen Unix/Mac und Windows-Format konvertieren kann.

Beachten Sie dies bei der Konvertierung von Dokumenten zwischen den Systemen. So werden Dokumente, die von Unix-Systemen erstellt wurden, auf Windows-Rechnern ganz ohne Zeilenumbrüche dargestellt. Mit geeigneten Tools können Sie die Formate konvertieren.

Case-Sensitiv

Im Gegensatz zur Verwendung von Markup- und Attribut-Bezeichnungen bei HTML wird in XML-Dokumenten zwischen Groß- und Kleinschreibung unterschieden. Inzwischen ist auch die neuere Parser-Generation »case-sensitive«. Die erste Anweisung eines Dokuments, die angibt, dass es sich um ein gültiges XML-Dokument handelt, ist in Kleinbuchstaben abzufassen:

<?xml version="1.0"?>

Viele Software-Produkte, die sich noch in der Entwicklung befinden, unterstützen in der ersten Generation noch keine »case-sensitive« Unterscheidung. Im Hinblick auf die weiteren Fortschritte sollten Sie aber schon jetzt die »richtige« Schreibweise in Ihren Dokumenten verwenden.

Zeichenreferenz

Für Sonderzeichen, die wir nicht auf der normalen Tastatur finden, sowie Zeichen, die in XML eine andere (beispielsweise delimitierende) Bedeutung haben, muss eine andere Möglichkeit zur Eingabe verwendet werden.

Insbesondere sind dies die folgenden Zeichen:

& < > '  "

Diese Zeichen können mithilfe einer so genannten Entity-Umschreibung eingesetzt werden. Eingeleitet wird die Entity mit einem kaufmännischen »Und« ("&"). Dann folgt eine abgekürzte Umschreibung des Zeichens, die mit einem Semikolon abgeschlossen wird. Wahlweise kann das Zeichen auch mithilfe einer Dezimalzahl dargestellt werden. Im nächsten Beispiel finden Sie die Entities für die deutschen Umlaute. Im Anhang dieses Buchs haben wir eine komplette Übersicht aller Abkürzungen für Sie zusammengestellt.

Buchstabe Entity Abkürzung Dezimalzahl
ä
&auml;
a Umlaut
&#228;
Ä
&Auml;
A Umlaut
&#196;
ö
&ouml;
o Umlaut
&#246;
Ö
&Ouml;
O Umlaut
&#214;
ü
&uuml;
u Umlaut
&#252;
Ü
&Uuml;
U Umlaut
&#220;

Innerhalb der DTD-Beschreibungen können Sie selbst Entities als Abkürzungen nicht nur für Sonderzeichen, sondern für ganze Textabschnitte definieren. Siehe dazu Kapitel Entity-Definition.

CDATA Abschnitte

Der CDATA (character Data) Abschnitt innerhalb eines Dokuments weist den Parser an, diesen Text nicht auszuwerten und insbesondere Markup-Befehle und Entities zu ignorieren. Eingesetzt wird diese Form etwa, wenn man Quellcode in die Seite integrieren möchte und dieser auch genau so angezeigt werden soll.

<![CDATA[
Beispiel für einen XML-Quelltext:
<ORT>Paderborn</ORT>
]]>

Alle Zeichen, die sich zwischen dem einleitenden Markup "<![CDATA[" und dem abschließenden "]]>" befinden, werden ohne weitere Bearbeitung vom Parser an die Applikation weitergereicht.

Die einzige Zeichenfolge, die sich natürlich nicht innerhalb des Abschnitts befinden darf, ist das Abschluss-Tag. Auch eingebettete Kommentare ("<!-- Kommentar -->") werden ohne Berücksichtigung an die Anwendung übermittelt.

Alternativ hätten Sie diesen Quelltext natürlich auch mithilfe der oben genannten Entities darstellen können:

Beispiel für einen XML-Quelltext:
&lt;ORT&gt;Paderborn&lt;/ORT&gt;

Sie erkennen schon an diesem Beispiel, dass die Verwendung der CDATA-Section, insbesondere für längere Quellcodes, wesentlich einfacher und übersichtlicher als die alternative Verwendung von Entities ist.

Angabe von Attributen

Attribute von Markup-Befehlen müssen anders als in HTML grundsätzlich in Anführungszeichen angegeben werden. Dabei spielt es keine Rolle, ob man die doppelten oder einfachen Anführungszeichen verwendet. Beide Schreibweisen sind korrekt:

<ADRESSE PRIVAT="ja">
<ADRESSE PRIVAT='ja'>

Ein Attributname darf höchstens einmal innerhalb eines Markup-Elements auftreten. Außerdem darf der Wert eines Attributs keine öffnenden spitzen Klammern enthalten, wie sie zur Delimitierung eines Markups verwendet werden. Folgende Schreibweisen entsprechen nicht der korrekten Syntax:

<ADRESSE PRIVAT=ja>                     <!-- FALSCH! -->
<ADRESSE PRIVAT="ja" PRIVAT="nein">     <!-- FALSCH! -->
<ADRESSE PRIVAT="<ja">                  <!-- FALSCH! -->

3.3.2 Grundgerüst eines XML-Dokuments

Die offizielle Spezifikation des W3C für den Aufbau eines gültigen und so genannten wohlgeformten XML-Dokuments liest sich recht kryptisch und unverständlich, dennoch möchten wir sie Ihnen im Original nicht vorenthalten:

document ::= prolog element Misc*

Ein Objekt ist ein gültiges XML-Dokument, wenn es im Sinne dieser Definition wohlgeformt ist. Im folgenden Abschnitt werden wir Ihnen diese Struktur unabhängig von der oben genannten Codierung deutlich machen. Auch auf den Begriff der Wohlgeformtheit werden wir näher eingehen. Auch die Syntax, in der das oben genannte Beispiel definiert ist (Extended Backus-Naur Form), werden wir noch eingehend erläutern.

Abb. 3.36: Der Aufbau eines typischen XML-Dokuments

Das Dokument besteht aus drei Datenteilen. Wobei die Verwendung der ersten beiden Teile optional ist. Im so genannten Prolog, der Einleitung des XML-Dokuments befindet sich die Verarbeitungsanweisung und die Document Type Definition. Danach folgt der eigentliche Inhalt der Datei.

Processing Instruction (PI)

Wird ein Tag innerhalb eines XML-Dokuments mit einem Fragezeichen eingeleitet und geschlossen ("<? ... ?>"), so handelt es sich um eine so genannte Processing Instruction (engl. Verarbeitungsanweisung) oder kurz PI. Verarbeitungsanweisungen, die mit dem Schlüsselwort XML beginnen, sind für die XML-Standarddefinition reserviert. Diese Verarbeitungsanweisung teilt dem Parser mit, dass er aktiv werden muss und beispielsweise eine DTD-Datei hinzugeladen werden muss.

Die anfängliche Verarbeitungsanweisung teilt dem Parser mit um welches XML-Format es sich beim vorliegenden Dokument handelt.

<?xml version="1.0"?>

Augenblicklich ist als Versionsangabe ausschließlich die Version 1.0 vorgesehen. Aber im Hinblick auf weitere Entwicklungen der Sprache sollte man diese trotzdem korrekt verwenden.

Der innerhalb eines Dokuments verwendete Zeichensatz kann in der Verarbeitungsanweisung über das Schlüsselwort ENCODING näher bestimmt werden.

<?xml version="1.0" encoding="ISO-8859-1"?>

Dabei steht neben der ISO-Norm 8859 mit ihren zehn Untergliederungen auch die ISO/IEC 10646-Norm zur Verfügung. Jeder XML-Prozessor muss in der Lage sein mindestens die Formate UTF-8 und UTF-16 zu lesen.

ISO-Norm Zeichensatz
UTF-8 internationaler Zeichensatz
UTF-16 internationaler Zeichensatz
ISO-8859-1 West Europa (Latin-1)
ISO-8859-2 Ost Europa (Latin-2)
ISO-8859-3 Süd Europa (Latin-3)
ISO-8859-4 Nord Europa (Latin-4)
ISO-8859-5 Kyrillisch
ISO-8859-6 Arabisch
ISO-8859-7 Griechisch
ISO-8859-8 Hebräisch
ISO-8859-9 Türkisch (Latin-5)
ISO-8859-10 Nordisch (Latin-6)

Die Option STANDALONE (engl. alleinstehend) in der Verarbeitungsanweisung kennzeichnet, ob der Parser eine externe DTD einlesen muss oder nicht. Der Wert "yes« zeigt an, dass keine externen Dateien hinzugezogen werden müssen. Der Wert "no" zeigt lediglich an, dass eine externe Datei existiert. Der Dateiname muss dann in der DOCTYPE-Definition angegeben werden.

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

Der Befehl ist optional anzuwenden. Wird er nicht eingesetzt und existiert eine externe DTD so wird der Wert STANDALONE="no" angenommen, andernfalls hat die Standalone-Deklaration keine Bedeutung. Die Verwendung von Document Type Definitions werden wir im nächsten Abschnitt ausführlich erläutern.

Wie Sie schon erfahren haben, gibt es zwei Möglichkeiten eine DTD einer XML-Datei zuzuordnen. Einerseits in einer separaten Datei und alternativ innerhalb des Dokuments. Der Parser muss sich die Angaben zur DTD dann nicht aus einer externen Datei holen, sondern kann sie direkt der XML-Datei entnehmen.

Beispiel: externe DTD

<!DOCTYPE Adressen SYSTEM "Adressen.dtd">

Möchten Sie auf eine öffentlich zugängliche DTD-Definition verweisen so verwenden Sie statt des Schlüsselworts SYSTEM einfach PUBLIC und geben den vollständigen URL-Pfad an.

<!DOCTYPE Adressen
            PUBLIC "http://www.domain.de/Adressen.dtd">

Beispiel: interne DTD

<!DOCTYPE Adressen [ interne DTD-Anweisungen ]>

Das komplette Grundgerüst, bestehend aus den drei Teilen Processing Instruction und Document Type Definition, sowie dem eigentlichen Inhalt des Dokuments möchten wir Ihnen im Folgenden als kurzes zusammenfassendes Beispiel zeigen. Die ersten beiden Teile sind untergebracht im Prolog, also dem ersten Teil der Datei.

Processing Instruction

<?xml version="1.0" standalone="no" encoding="ISO-8859-1" ?>

Document Type Definition

<!DOCTYPE Adressen SYSTEM "Adressen.dtd">

Inhalt des Dokuments

<ADRESSE>
[...]
</ADRESSE>

Wohlgeformtheit (wellformed)

Ein Begriff wird Ihnen bei der Arbeit mit XML immer wieder in Bezug auf korrekte Umsetzung der Spezifikation begegnen: Wohlgeformtheit. Die Wohlgeformtheit eines Dokuments (oder englisch wellformed document) besagt im Grunde genommen nichts anderes, als dass sich das vorliegende Konstrukt vollständig an die offiziellen Regeln des W3C zur Erstellung von XML-Dokumenten hält. Insbesondere gehört dazu auch, dass es aus einem Prolog und mindestens einem Element besteht.

Beispiel:

<?XML version="1.0"?>
<dokument>
      <daten>Text</daten>
</dokument>

Für die eingesetzten Elemente gilt, dass diese korrekt ineinander verschachtelt sind. Also wenn sich das Start-Tag eines Elements im Inhalt eines anderen Elements befindet, so muss sich auch dessen End-Tag im Inhalt des anderen Elements befinden. Im Hinblick auf die Zusammenarbeit oder Konvertierung von XML zu SGML ist es wichtig zu wissen, dass jedes wellformed Dokument gleichzeitig auch ein SGML Dokument ist.

Gültigkeit (valid)

Neben der Wohlgeformtheit eines Dokuments spielt auch die Überprüfung auf die Gültigkeit eine wichtige Rolle. Drei Punkte bestimmen, ob ein XML Gültigkeit besitzt oder nicht:

Das bedeutet, schon das Fehlen einer DTD wirkt sich auf die Gültigkeit des Dokuments aus. XML-Dokumente ohne DTD können keine gültigen Dokumente im Sinne der Spezifikation sein. Da die Verarbeitung und Überprüfung der DTD nicht einfach ist, verzichten viele Parser darauf Dokumente auf Gültigkeit zu überprüfen.

Das einfachste gültige XML-Dokument mit integrierter DTD-Definition eines Elements müsste also mindestens aus den folgenden Zeilen bestehen:

<?xml version="1.0"?>
      <!DOCTYPE dokument [
         <!ELEMENT daten (#PCDATA)>
      ]>
<daten>Hier sind die Daten ...</daten>

Wie man aus den Bedingungen für Gültigkeit ersehen kann, folgert daraus, dass jedes gültige Dokument auch ein wohlgeformtes Dokument sein muss. Die Überprüfung auf Gültigkeit schließt die Überprüfung auf Wohlgeformtheit ein.

In vielen Fällen ist die weitreichende Überprüfung auf Gültigkeit nicht notwendig. Beispielsweise wenn die Dokumentenstruktur so einfach ist, dass keine DTD erforderlich ist oder der Processor die DTD sowieso nicht berücksichtigt.

<?xml version="1.0"?>
      <!DOCTYPE dokument [
      <!ELEMENT daten (#PCDATA)>
         ]>
<daten>
Dieses Dokument ist zwar
<fachbegriff>wohlgeformt</fachbegriff>,
aber nicht
<fachbegriff>gültig</fachbegriff>.
</daten>

Das obige Beispiel zeigt ein Dokument, das zwar die Bedingungen der Wohlgeformtheit erfüllt, aber nicht gültig ist. Denn das Element <fachbegriff> ist zwar richtig eingesetzt, es wird aber nicht in der zugehörigen DTD definiert.

Nach der Definition ist ein nicht-wohlgeformtes Dokument kein XML-Dokument.

3.3.3 Extended Backus-Naur Form (EBNF)

Die Intention unseres Buches ist es ja eigentlich Ihnen XML anhand eindeutiger Formulierungen und anschaulichen Praxisbeispielen verständlich zu machen. Ein genaues Studium der offiziellen XML-Recommendation des W3C möchten wir Ihnen gerne ersparen.

Dennoch verspüren Sie vielleicht hin und wieder den Wunsch sich diese Empfehlungen einmal im Original anzusehen. Die offiziellen Definition des XML-Standards folgt einer ganz besonderen Syntax.

Diese Syntax ist so gestaltet, dass sie durch eine Software, beispielsweise durch einen Parser ausgewertet und verstanden werden kann. So muss der Programmierer eines solchen Parsers nicht die W3C-Empfehlungen Schritt für Schritt in Programmform umsetzen, sondern er muss dem Parser nur beibringen die Syntax der Definition zu verstehen.

Um die Syntax einer Sprache dem Computer verständlich zu machen, bedient man sich des »Extended Backus-Naur«-Formats (EBNF). Mit dessen Hilfe ist es möglich logische Definitionen in einen speziellen Programmcode umzuwandeln. Das System ist zur Konstruktion eines Compilers entwickelt worden. Wenn Sie dieses Thema näher interessiert, erhalten Sie weitere Informationen in zahlreichen Fachbüchern zum Compilerbau.

Die W3C-Empfehlung zu XML enthält zurzeit insgesamt 89 solcher Definitionen im EBN-Format. Diese sind durchgängig nummeriert. Die Nummerierung finden Sie jeweils vor der Definition in eckigen Klammern. Neben diesen Syntax-Begriffsbestimmungen enthält der Original-Text natürlich noch eine Reihe von ergänzenden Erklärungen.

EBNF ist eine Auflistung von Bedingungen (so genannten »productions«). Jede Bedingung beschreibt ein Fragment der Syntax.

[Nummer] Bezeichnung ::= Definition

Kurz zusammengefasst besteht eine EBNF-Bestimmung grundsätzlich aus einer Bezeichnung und der Definition, getrennt durch zwei Doppelpunkte und ein Gleichzeichen.

Im folgenden Beispiel sehen Sie die Definition des Kommentar-Blocks:

[15]
Comment ::= '<!--' ((Char - '-') | ('-' Char - '-')))* '-->'

Abb. 3.37: Der Kommentarblock als Ablaufgrafik dargestellt

Schlüsseln wir die Bestandteile dieser Definition unseres Beispiels nun einmal Stück für Stück auf:

Definition Bedeutung
'<!--'
Die Zeichenkette ist unbedingt zu Beginn des Markups notwendig.
'-->'
Mit dieser Zeichenkette wird der Markup-Befehl abgeschlossen.
(Teil 1 | Teil 2)
Neben Start- und Schluss-Delimitierung finden wir zwei weitere Definitionsteile. Die beiden Teile sind mit einem senkrechten Strich verbunden. Das bedeutet, entweder muss die eine ODER die andere Definition (Teil 1 oder Teil 2) gelten.
(Char - '-')
Die erste Definition sagt aus, dass zwischen den Delimitierungen ein beliebiges Zeichen (Character) stehen darf. Mit dem nach dem Minus stehenden Zeichen (»-«) wird der Trennstrich als folgendes Zeichen ausgeschlossen.
('-' (Char - '-')
Um einen Trennstrich vor einem Zeichen zuzulassen, wurde noch ein Definition hinzugenommen.
(Teil 1 | Teil 2)*
Das Sternchen hinter den beiden Teilen gibt uns an, dass beliebig viele den Regeln folgender Zeichen eingesetzt werden dürfen.

Zeichenräume definieren

Nach diesem Beispiel möchten wir Ihnen die gesamte formale Grammatik der erweiterten Backus-Naur-Form genauer erläutern.

Jeder Ausdruck stellt das Muster eines oder einer ganzen Reihe von Zeichen dar. Für die Angabe der gültigen Zeichen sind folgende Ausdrücke einsetzbar:

Ausdruck Folgende Zeichen sind gültig ...
[a-z]
... alle Zeichen innerhalb des angegeben Intervalls.
[^a-z]
... alle Zeichen außerhalb des angegebenen Intervalls.
[*abc]
... alle Zeichen außer den genannten.
"Zeichen"
... die angegebene Zeichenkette.
'Zeichen'
... die angegebene Zeichenkette.

Verknüpfung von Ausdrücken

Neben der Definition von Zeichen und Zeichenketten kann man diese miteinander kombinieren, wie auch schon in unserem Beispiel gesehen. A und B sind in der obigen Tabelle genannte Ausdrücke.

Muster Kurz Bedeutung
A?
Optional Die Benutzung des definierten Symbols ist optional.
A B
UND Die Symbole müssen in der genannten Reihenfolge vorkommen.
A | B
ODER Entweder muss das Symbol A oder B eingesetzt werden.
A - B
OHNE Das Symbol A mit der Ausnahme B muss eingesetzt werden.
A+
Einfach oder mehrfaches Das Symbol muss mindestens einmal, darf aber auch öfter vorkommen.
A*
Gar nicht, einfach oder mehrfach Das Symbol muss nicht vorkommen, darf aber auch einmal oder öfter auftauchen.

Mehrere auf oben beschriebene Weise verknüpfte Ausdrücke können in Klammern gesetzt werden und sind dann als eine Einheit (ein Ausdruck) zu betrachten.

Beispiel: Verarbeitungsanweisung

Die Verarbeitungsanweisung zur Definition der XML-Version kennen Sie schon aus dem vorangegangenen Abschnitt. Im folgenden Beispiel erläutern wir die Definition dieses Befehls (wir haben aus Gründen der Verständlichkeit den Befehl um einige Optionen gekürzt):

<?xml version="1.0"?>

Die Befehlsdefinition der einleitenden Processing Instruction findet sich in der offiziellen Darstellung wie folgt wieder:

[23] XMLDecl      ::=
                  '<?xml' VersionInfo EncodingDecl? Sdecl? '?>'
[24] VersionInfo  ::=
                  'version='  (' VersionNum ' | "VersionNum")
[26] VersionNum   ::=
                  ([a-zA-Z0-9_.:] | '-')+

Deutlich zu sehen ist, dass in Defintion [23] auf die weiteren Definitionen VersionInfo, EncodingDecl und Sdecl zurückgegriffen wird. Die beiden letzt genannten, die wir schon als die Attribute ENCODING und STANDALONE kennen, sind optional (zu erkennen am angehängten Fragezeichen).

Die Versionsnummer selbst, die im Augenblick ja ausschließlich "1.0" lauten darf, ist in [24] festgelegt, so dass sie in doppelten Anführungszeichen oder alternativ in einfachen Anführungszeichen angegeben werden darf. Diese Alternative ist übrigens für alle Attribute gegeben.

Die Zahl zur Angabe der Version erfährt eine weitere genaue Definition in [26]. Beliebige Buchstaben, Zahlen sowie Unterstrich, Punkt oder Doppelpunkt sind zulässig. Alternativ ist ein Bindestrich einsetzbar. Das abschließende Pluszeichen zeigt, dass mindestens eins oder mehrere zu dem Muster passende Zeichen einzusetzen sind.

Ein XML-Dokument ist dann gültig, wenn es auf eine einzige, spezifische Bedingung reduziert werden kann. Das heißt jeder Bestandteil lässt sich in eine EBNF-Bedingung auflösen, dieser ist rekursiv wieder Bestandteil einer umschließenden Bedingung. Hat man alle Bedingungen eines Dokuments aufgelöst muss folgende zugrunde liegende Definition herauskommen:

[1] document ::= prolog element Misc*

Auch wenn das EBN-Format nicht gerade eine menschlich verständliche Definition einer Syntax bildet, bietet es doch einen unmissverständlichen und nur auf eine Weise interpretierbaren Mechanismus eine Sprache festzulegen. Textbeschreibungen, noch dazu in verschiedenen Übersetzungen, bieten häufig einen gewissen Spielraum für Interpretation und sind damit nicht eindeutig. Im Zweifelsfall bietet es sich also durchaus an, bevorzugt die EBN-Form der XML-Syntax zu Rate zu ziehen. Daher haben wir im Anhang dieses Buches alle 89 Regeln des W3C zur XML Version 1.0 als Übersicht für Sie zusammengestellt.

3.4 Document Type Definition (DTD)

3.4.1 Kurzübersicht DTD

Wenn Sie bisher Internetseiten unter HTML erstellt haben, wird Ihnen der Begriff Document Type Definition sicherlich schon einmal begegnet sein. Zumindest wenn Sie in der ersten Zeile eines Dokuments angegeben haben, welche HTML-Version Ihr Dokument unterstützt.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">

Dafür sich näher mit einer DTD zu beschäftigen sahen Sie bisher sicherlich keinen Grund. Wir haben ja in unserem einleitenden Titel schon auf die Verwendung von DTDs unter HTML hingewiesen. Wenn Sie sich jetzt näher mit XML beschäftigen, kommen Sie allerdings nicht um eine gründliche Einarbeitung des Themas herum.

Die Document Type Definition ist ein zentraler Bestandteil jedes SGML und auch XML-Dokuments. Sie können vielleicht zunächst auf einige vorhandene DTDs zurückgreifen, zumindest müssen Sie aber deren Funktionsweise verstehen. Später werden Sie sicherlich den Drang verspüren selbst DTD zu erstellen oder vorhandene an individuelle Projekte anzupassen. Dieser Abschnitt wird Ihnen einen Einblick in das gar nicht so schwierige Thema verschaffen.

In einer Document Type Definition werden die Grundregeln für die Struktur eines Dokuments festgelegt. In der DTD zur HTML-Sprache sind alle einsetzbaren Markups und deren Attribute definiert. Die DTD legt zudem fest wie die Elemente ineinander verschachtelt werden können. Beispielsweise, dass innerhalb der <HTML>-Tags der Textkörper <BODY> folgt.

<HTML>
      <BODY>
      </BODY>
</HTML>

Hierbei ist für die Autoren der auf dieser DTD basierenden Dokumente natürlich eine hohe Disziplin erforderlich, sich an die festgelegten Regeln zu halten. Das Hauptaugenmerk bei der Verwendung von XML sollte also bei der Gestaltung der DTD liegen. Die definierten DTD-Elemente dann in eine korrekte Form innerhalb des XML-Dokuments zu bringen ist eher der leichtere zweite Schritt.

Interne oder externe DTD

Freigestellt ist, ob die Dokumenttyp-Definition innerhalb des Dokuments selbst oder als externe Datei untergebracht wird. Bei einer externen DTD spricht man auch von einer externen DTD-Untermenge. Wenn die DTD innerhalb des Dokuments untergebracht wird, steht die interne DTD-Untermenge am Anfang der Datei.

Anhand der DTD ist eine spätere Überprüfung der Syntax durch den Parser möglich und erforderlich. Sofern ein validierender Parser eingesetzt wird ist der Zugriff auf eine DTD unbedingt erforderlich.

Der folgenden Hinweis auf eine externe DTD-Datei muss innerhalb jedes Dokuments eingefügt werden. Der Zusatz SYSTEM gibt an, dass es sich um eine externe Datei handelt. Diese muss sich in unserem Beispiel im gleichen Verzeichnis wie die Quelldatei befinden.

<!DOCTYPE adressen SYSTEM "adressen.dtd">

Diese Deklaration gibt an, dass sich das Dokument auf die DTD "adressen.dtd" bezieht. Natürlich sind auch Bezüge auf andere Verzeichnisse möglich:

<!DOCTYPE adressen SYSTEM "http://www.xml.de/adressen.dtd">

Bei kürzeren DTDs bietet es sich oft an, diese direkt im XML-Dokument unterzubringen. Die großen Vorteile von XML, DTDs in einer ganzen Reihe von Dokumenten unterzubringen, gehen damit aber unweigerlich verloren oder fordern einen hohen Mehraufwand. Für eine interne DTD werden die einzelnen Definitionen im Prolog des XML in der DOCTYPE-Anweisung innerhalb eckiger Klammern angegeben.

<!DOCTYPE adressen [ interne DTD-Anweisungen ]>

Ohne zunächst näher auf die einzelnen verwendeten Befehle einzugehen, konfrontieren wir Sie zunächst mit einem kleinen Beispiel. Zunächst folgt die externe DTD gespeichert unter dem Dateinamen "adressen.dtd" zur Definition einer Adresse. Vielleicht erkennen Sie anhand der einfachen Struktur schon den einen oder anderen Zusammenhang. Keine Sorge, wenn dem noch nicht so ist. Im weiteren Verlauf werden wir jedes Detail genau erklären.

<!-- DTD-Definition Adressen -->
<!ELEMENT adresse (vorname, name, strasse, plz, ort)>
      <!ELEMENT vorname   #PCDATA>
      <!ELEMENT name      #PCDATA>
      <!ELEMENT strasse   #PCDATA>
      <!ELEMENT plz       #PCDATA>
      <!ELEMENT ort       #PCDATA>

Mithilfe der erstellten DTD ließe sich das unten stehende Dokument mit externem Hinweis auf adressen.dtd erzeugen:

<?xml version="1.0"?>
<!DOCTYPE adressen SYSTEM "adressen.dtd">
<ADRESSE>
   <VORNAME>  Peter      </VORNAME>
   <NAME>     Meyer      </NAME>
   <STRASSE>  Waldweg 5  </STRASSE>
   <PLZ>      36756      </PLZ>
   <ORT>      Detmold    </ORT
</ADRESSE>

Jede XML-Definition kann sich auf eine oder mehrere DTDs beziehen. Sollten sich einzelne Befehle in den DTDs überschneiden, so ist die Definition gültig, die zuerst eingelesen wurde. Mit diesem wichtigen Feature ist es möglich ein Dokument auf der Basis von HTML zu schreiben und mithilfe einer weiteren DTD eigene Befehle hinzuzufügen oder bestehende anzupassen. Dies erleichtert den Umgang mit XML. Das Rad muss nicht jedes Mal neu erfunden werden, lediglich einzelne Befehle werden neu definiert.

Das obige Beispiel könnte auch als interne DTD realisiert werden. Sowohl DTD-Definition als auch Quelltext der XML-Datei werden dazu in ein Dokument gepackt.

<?xml version="1.0"?>
<!-- interne DTD -->
<!DOCTYPE adressen [
<!ELEMENT adresse (vorname, name, strasse, plz, ort)>
   <!ELEMENT vorname    #PCDATA>
   <!ELEMENT name       #PCDATA>
   <!ELEMENT strasse    #PCDATA>
   <!ELEMENT plz        #PCDATA>
   <!ELEMENT ort        #PCDATA>
]>
<!-- Beginn des Textkörpers -->
<ADRESSE>
   <VORNAME>  Peter     </VORNAME>
   <NAME>     Meyer     </NAME>
   <STRASSE>  Waldweg 5 </STRASSE>
   <PLZ>      36756     </PLZ>
   <ORT>      Detmold   </ORT
</ADRESSE>

Setzt man interne und externe Document Type Deklarationen parallel ein, so sollte die interne vor der externen Deklaration erfolgen. Typischerweise bindet man eine globale DTD als externe Datei ein und führt individuelle Änderungen für das Dokument als interne Deklaration durch.

<!DOCTYPE adressen [
<!ELEMENT telefon (vorwahl, nummer, durchwahl)>
   <!ELEMENT vorwahl   #PCDATA>
   <!ELEMENT nummer    #PCDATA>
   <!ELEMENT durchwahl #PCDATA>
]>
<!DOCTYPE artikel SYSTEM "artikel.dtd">

Wie Sie in unseren Beispielen schon feststellen konnten, besteht jede DTD aus einer Reihe von Deklarationen. Jede Deklaration ist von zwei Zeichengruppen eingeschlossen, die wir auch schon zur Delimitierung von Markups kennen ("<! ... >").

Übersicht: Schlüsselwörter

Die folgenden Schlüsselwörter klassifizieren jeden Eintrag in der DTD:

<!ELEMENT ... > Definition eines neuen Markup-Befehls

<!ATTLIST ... > Definition von Attributen

<!ENTITY ... > Definition von Entities

<!NOTATION ... > Definition einer Datentyp-Notation

<!-- Kommentar --> Einfügen eines Kommentars

Wie Sie bereits in unseren einleitenden Kapiteln erfahren haben, unterscheidet man zwischen logischen und physischen Strukturen. Und so kann man auch die Befehle, die in der DTD eingesetzt werden, in diese zwei Gruppen einteilen.

Logische Strukturen lassen sich mithilfe der ELEMENT-Definition und den zugehörigen ATTLIST-Deklarationen darstellen. ENTITIY und NOTATION bilden die physischen Strukturen.

In den folgenden Abschnitten werden wir alle Schlüsselwörter und deren zahlreiche Optionen detailliert erläutern.

3.4.2 Entity Definition

Allgemeine Entities

Entities sind uns schon aus HTML bekannt. Mit Ihrer Hilfe werden Sonderzeichen mithilfe von Abkürzungen definiert.

Beispielsweise wird mit dem Entity &copy; das Copyright-Zeichen "(c)" definiert. Im weiteren Verlauf des Dokuments kann dann statt des Sonderzeichens die vereinbarte Abkürzung eingesetzt werden. Entities sind in diesem Fall unbedingt notwendig, da der Zeichensatz der Textdatei nur 128 Zeichen enthält und in diesem keine landesspezifischen Sonderzeichen enthalten sind.

Zusätzlich lassen sich Kürzel zur Verfügung stellen, die automatisch durch längere und häufig eingesetzte Zeichenfolgen ersetzt werden. Eine Entity-Deklaration in der DTD wird durch das Schlüsselwort ENTITY (übersetzt: Existenz) eingeleitet. Mit dem folgenden Beispiel weist man der Abkürzung "gw" den kompletten Namen zu:

<!ENTITY gw "Gunter Wielage">

Möchte man diese Abkürzung innerhalb eines Dokuments verwenden, setzt man den vereinbarten Namen einfach als Entity ein:

<?xml version="1.0" ?>
Der Autor dieses Dokuments ist &gw;

Achten Sie bei der Definition von eigenen Entities auf die schon vorgegebenen Abkürzungen für den Zeichensatz. Man könnte Entities also als Deklaration von Abkürzungen für Zeichen oder Zeichenfolgen definieren. Wobei es natürlich von Ihnen abhängt, ob ein Entity wirklich eine »Abkürzung« ist.

Parameter Entity

Eine weitere Unterscheidung kann zwischen den allgemeinen Entities und den so genannten Parameter Entities erfolgen. Während allgemeine Entities in der DTD definiert werden und erst im XML-Dokument in Verbindung mit dem Parser in Aktion treten, betreffen Parameter Entities nur die DTD selbst. Beim Prozess des Parsing werden diese Entities innerhalb der DTD durch den Ersetzungstext ausgetauscht.

Der Unterschied zwischen allgemeinen und Parameter Entities besteht in der Syntax lediglich durch ein zugefügtes Prozentzeichen (»%«). Während in der Entity Definition das Prozentzeichen von Leerzeichen getrennt stehen muss, wird das Entity aufgerufen durch den Namen oder die Abkürzung des Entities mit vorangestelltem Prozentzeichen.

Tauchen in einer DTD beispielsweise regelmäßig die gleichen Elementlisten auf, so können diese vorab als Entity definiert, später immer wieder aufgerufen werden.

<!ENTITY %  gliederung "kapitel|absatz|zeile">

Der Aufruf des Parameter Entity erfolgt im Dokument dann mit vorangestelltem Prozentzeichen und abschließendem Semikolon. Das Prozentzeichen hat außerhalb der DTD, also im XML-Dokument selbst verwendet, keine besondere Bedeutung.

%gliederung;

In der Praxis könnten solche Parameter Entities immer dann Verwendung finden, wenn häufig gleiche Zeichenketten verwendet werden.

Die folgende Auflistung kann dann in der DTD ...

<!ELEMENT DOKUMENT (kapitel|absatz|zeile)*>

... ganz einfach durch das abkürzende Entity ersetzt werden:

<!ELEMENT DOKUMENT (%gliederung;)*>

Oder auch als Ergänzung zu anderen Elementen:

<!ELEMENT DOKUMENT (buch|%gliederung;|wort)*>

Parameter Entities lassen sich aber auch in einer weiteren Entity-Deklaration einsetzen:

<!ENTITY %  gliederung "kapitel|absatz|zeile">
<!ENTITY dokument %gliederung>

Rekursive Entity-Deklarationen, also Deklarationen, die sich selbst oder ein Entity aufrufen, das selbst mithilfe des aufrufenden Entities deklariert ist, sind verständlicherweise nicht möglich:

<!ENTITY % gliederung %dokument>
<!ENTITY % dokument %gliederung>

Eine weitere Einschränkung gilt in Hinsicht auf die Ersetzung von Markup-Befehlen Entities durch Entities. Ein Start-Tag darf nicht in einem anderen Entity deklariert sein, wie das zugehörige End-Tag. Das folgende Beispiel ist also nicht korrekt:

<!ENTITY % start "&lt;dokument&gt;">
<!ENTITY % ende "&lt;/dokument&gt;">

Auch leere Elemente, also Markups zu denen kein End-Tag gehört, lassen sich auf diese Weise nicht in Entities definieren.

Interne und externe Entities

Alle Entities, die wir bisher kennen gelernt haben, waren interne Entities. Das heißt der Ersetzungstext wird in das Dokument integriert. Neben dieser internen Variante existieren auch noch die externen Entities. Der Parser kann nicht jeden Datentyp verarbeiten und in das Dokument einfügen.

Bei einem externen Entity erfolgt ein Verweis auf eine externe Datenquelle, beispielsweise ein weiteres XML-Dokument.

Internes Entity:

<!ENTITY datum "10.10.1999">

Externes Entity:

<!ENTITY beschreibung
         SYSTEM "http://www.domain.de/dokument.xml">

Hier wird der Parser das Wort &beschreibung; ersetzen durch den Inhalt der angegebenen Datenquelle. Bei externen Entities besteht aber das Problem, dass sich nicht jede Art von Daten so einfach in das bestehende Dokument einfügen lässt. Spätestens, wenn wir als externe Datenquelle eine binäre Grafikdatei angeben, stoßen wir auf Schwierigkeiten. In diesem Fall findet eine weitere Unterscheidung zwischen analysierten und nicht-analysierten Entities, also vom Parser zu verarbeitende oder nicht zu verarbeitenden Daten, statt.

Die vordefinierten Entities wie beispielsweise &lt; und &gt; für die Zeichen "<" und ">" zählen zu den internen Entities auch wenn sie eigentlich nicht intern deklariert werden.

Alle internen Entities sind analysierte, d.h. vom Parser verarbeitete Entities. Der Unterscheidung von analysierten und nicht-analysierten Entities widmen wir uns im nächsten Abschnitt.

Analysierte und nicht-analysierte Entities

Man unterscheidet zwischen Entities, die vom Parser ausgewertet und analysiert (parsed) werden und nicht-ausgewerteten (unparsed) Entities. Ein Entity, das eine Abkürzung für eine Zeichenkette enthält, wird vom Parser analysiert und gegen die längere vollständige Zeichenkette oder das Sonderzeichen ersetzt. Der ersetzte Text wird damit zum integralen Bestandteil des Dokuments.

Ein nicht-analysiertes Entity kann beliebigen Inhalts sein und wird vom Parser an die Anwendung weitergeleitet. Diese muss dann gewährleisten, dass sie die Daten in irgendeiner Form weiterverarbeitet oder anzeigt. Nicht-analysierte Entities sind beispielsweise Grafik- oder Sound-Ressourcen.

Soll ein Dokument der Wohlgeformtheitsbeschränkung genügen, so ist es unbedingt erforderlich, dass ausschließlich Entities eingesetzt werden, die auch in der zugehörigen DTD definiert sind. Eine Ausnahme bilden die vorgegebenen Entities für die Zeichenreferenzen:

"&amp;",  "&lt;",  "&gt;",  "&apos;" und "&quot;".

Sehen wir uns im folgenden Beispiel einmal ein externes und nicht-analysierendes Entity genauer an. Es verweist auf eine externe Datei, in der Daten im EPS-Format vorliegen. Diese können natürlich nicht einfach in die bestehende XML-Datei eingefügt werden, da Sie in binärer Form vorliegen und keinerlei Markups zur Auswertung enthalten.

<!ENTITY anleitung SYSTEM
         "http://www.domain.de/anleitung.eps" NDATA EPS>

Das Schlüsselwort NDATA gibt dem Parser den Hinweis, dass die im Entity enthaltenen Daten nicht verarbeitet werden sollen, weil es sich in der Regel um binäre Daten handelt.

Zusätzlich muss noch der Datentyp der Datei angegeben werden, in diesem Fall EPS für Encapsulated PostScript. Mit diesen Datentypen werden wir uns noch einmal unter dem Stichwort Notation-Deklaration näher beschäftigen. In dieser Notation muss dem Parser mitgeteilt werden, wie die binären Daten zu behandeln sind, bzw. wie sie auf dem Bildschirm angezeigt werden können.

Grafiken im Dokument

In XML sind Entities unbedingt erforderlich, wenn externe Bilder- oder Sound-Dateien eingebunden werden. Wie wir schon gesehen haben, werden in diesem Fall externe, nicht-analysierte Entities eingesetzt. Für jede eingebundene Datei wird ein Entity deklariert, das den entsprechenden Verweis auf die Datei enthält.

Deklaration einer Grafik im JPEG-Format und im GIF-Format:

<!ENTITY produkt_1 SYSTEM
  "images/produkt01.jpg"
  NDATA JPEG>
<!ENTITY produkt_2 SYSTEM
  "images/produkt02.gif"
  NDATA GIF>

Eine Besonderheit ist beim Einsatz von nicht-analysierten Entities zu beachten: Diese dürfen innerhalb des XML-Dokuments nicht einfach in den Text eingesetzt werden, sondern benötigen ein Element in dem sie als Wert eines Attributs übergeben werden.

Folgendes funktioniert also nicht:

<?xml version="1.0"?>
<dokument>
Jetzt folgt ein Produktfoto: &produkt_1;
... und hier noch eins: &produkt_2;
</dokument>

Das Entity muss also dem Attribut eines Elements als Wert übergeben werden. Der Wertebereich des Attributs muss vom Typ ENTITY sein. Daher kann auf Angabe der sonst das Entity kennzeichnenden Zeichen "&" und ";" verzichtet werden.

<?xml version="1.0"?>
<dokument>
   <image quelle="produkt_1">
   <image quelle="produkt_2">
</dokument>

Zusammenfassung Entities

Entities können eine ganze Reihe von Bedeutungen und Funktionen haben. Einzig gemeinsam haben alle Entities, dass ein Name oder eine Bezeichnung einer Datenmenge zugeordnet wird. Unbedeutend ist dabei, ob diese zugewiesene Datenmenge aus einzelnen Zeichen besteht oder eine ganze Datei ist. Sobald der Parser auf ein in einem Entity definiertes Kürzel trifft, ersetzt er es durch die zuvor definierten Daten.

Wir haben Ihnen die verschiedenen bisher erwähnten Entity-Typen noch einmal in einer Übersicht zusammengestellt:

analysierte Entities nicht-analysierte Entities
Der Inhalt der Entities wird vom Parser direkt weiterverarbeitet. Der Inhalt der Entities wird vom Parser ohne weitere Bearbeitung zur Applikation weitergereicht.
<!ENTITY ab "Abkürzung">
<!ENTITY logo SYSTEM "bild.gif"
NDATA GIF>
allgemeine Entities Parameter Entities
Werden für Ersetzungen innerhalb des XML-Dokuments genutzt. Beziehen sich ausschließlich auf die DTD und finden im XML-Dokument keinen Einsatz.
<!ENTITY ab "Abkürzung">
<!ENTITY % ab "Abkürzung">
interne Entities externe Entities
Interne Entities werden innerhalb der DTD definiert. Beispielsweise die Ersetzung einer »Abkürzung« durch eine Zeichenkette. Externe Entities verweisen auf eine externe Datenquelle in der sich beispielsweise eine Grafik- oder Sound-Ressource befindet.
<!ENTITY ab "Abkürzung">
<!ENTITY text SYSTEM "text.xml">

Abb. 3.38: Alle möglichen Kombinationen im Überblick.

Obwohl es insgesamt drei verschiedene Unterscheidungen mit jeweils zwei Möglichkeiten gibt, existieren nicht insgesamt acht Kombinationsmöglichkeiten, sondern nur fünf. Alle fünf Kombinationen können Sie dem oben gezeigten Schaubild entnehmen.

3.4.3 Kommentare

Innerhalb einer Document Type Definition können beliebige Kommentare eingefügt werden, um die Übersichtlichkeit und eine spätere Nachbearbeitung zu erleichtern.

<!-- Hier könnte ein längerer Kommentar eingefügt werden  -->

Die Kommentare werden, analog zu HTML, delimitiert. Innerhalb eines Kommentars darf aus Kompatibilitätsgründen die Zeichenfolge »--« nicht vorkommen.

<!-- Hier folgt die Definition für das Element <ADRESSE> -->

Der Text, der sich innerhalb der Kommentardefinition befindet, wird vom Parser nicht weiter ausgewertet, daher ist auch die Verwendung von Markups problemlos möglich. Der Parser kann allerdings optional eine Möglichkeit zur Darstellung der Kommentarzeilen bereitstellen.

3.4.4 Element Definition

Das Element ist der wichtigste Bestandteil einer DTD. Es legt fest welche Markup-Befehle verwendet werden dürfen. Die Definition eines neuen Tag wird mit dem Stichwort ELEMENT gefolgt von einem Leerzeichen eingeleitet.

<!ELEMENT name ...>

Elementnamen

Ein Elementname muss mindestens mit einem Buchstaben beginnen, zusätzlich kann er aber auch Zahlen enthalten. Außerdem sind einige weitere Interpunktionszeichen zulässig (".", "-", "_" und ":"). Sonst sind der Wahl des Elementnamens keine Grenzen insbesondere nicht der Länge gesetzt. Sie dürfen allerdings keinen Elementnamen in einer DTD doppelt verwenden. Namen, die mit der Zeichenkette "xml" beginnen, sollten im Hinblick auf kommende Entwicklungen keine Verwendung finden.

Beispiele für mögliche gültige Elementnamen:

"i"
"Artikel:B-5000"
"Auch_laengere_Elementnamen_sind_kein_Problem"

Der Doppelpunkt kann zwar innerhalb eines gültigen Namens eingesetzt werden, die Spezifikation sieht ihn aber schon heute als Trennzeichen beispielsweise für Namensräume vor. Das bedeutet, dass das Zeichen in Zukunft eine andere Verwendung finden kann und bestehende Dokumente dann aktualisiert werden müssten.

Semantische Tags

XML setzt konsequent auf die Benutzung der so genannten semantischen Tags. In HTML ist es üblich physische Auszeichnungen wie <B> (für »bold« = fett) oder <TITLE> (für den Titel) einzusetzen. Diese Tags machen durch ihren Namen deutlich, dass sie Formatierungshinweise oder Strukturelemente kennzeichnen. Semantische Tags wie <ADRESSE> enthalten Bezeichnungen, die etwas über den Inhalt des Dokuments aussagen. Sie dienen weniger der Darstellung oder der Dokumentstruktur, sondern der späteren Auswertung der Daten nach inhaltlichen also semantischen Gesichtspunkten.

Inhalt eines Elements

Elemente dienen dazu, dass mit ihrer Hilfe Text ausgezeichnet wird. Das geschieht durch die Umschließung mit einem Start-Tag und einem Schluss-Tag des Elements. Da diese Elemente einen Inhalt (den Text oder engl. »content«) haben, nennt man sie auch »Container«.

<DATUM>01.01.1999</DATUM>

In der DTD kann definiert werden, wie der Inhalt zwischen den beiden Markups gestaltet sein kann. Mithilfe des Schlüsselworts #PCDATA wird angegeben, dass der Inhalt des Elements aus beliebigen Zeichenfolgen bestehen darf.

<!ELEMENT datum (#PCDATA)>

Um diese Eingaben noch genauer spezifizieren zu können, gibt es eine komplexere Deklaration für Elemente:

<!ELEMENT entscheidung (ja|nein|j|n)*>

Innerhalb der Klammern werden die möglichen Eingaben getrennt durch einen Balken angegeben. Hier sind für das Element entscheidung die Eingaben "ja", "nein", "j" und "n" möglich und gültig. Man kann diese Definition auch mit dem #PCDATA Schlüsselwort vermischen.

<!ELEMENT entscheidung (#PCDATA|ja|nein)*>

Neben dem Inhalt "ja" oder "nein" ist jetzt auch jeder beliebige andere Text möglich.

Leere Elemente

Mit leeren Elementen sind Markup-Befehle gemeint, die für sich alleine stehen können und in die kein Text eingebunden ist. In HTML kennen wir beispielsweise das IMG-Tag, mit dem externe Bilder in das Dokument eingebunden werden. Alle HTML-Befehle, die kein abschließendes Tag benötigen sind solche »leeren Elemente«. Im Gegensatz zu Elementen mit Inhalt wendet man auf leere Elemente den Begriff »Container« folglich nicht an.

<IMG SRC="picture.gif">

In XML muss die Schreibweise dieser leeren Markups etwas anders lauten. Zwei Schreibweisen sind alternativ zulässig. Entweder beendet man den Befehl ordnungsgemäß mit einem regulären Schluss-Tag oder man beendet das Start-Tag nicht wie üblich mit einem Größerzeichen, sondern mit der Zeichenfolge "/>".

<IMG SRC="picture.gif"></IMG>
<IMG SRC="picture.gif"/>

Element-Gruppen

In den meisten Fällen besteht der Inhalt eines Elements nicht einfach nur aus Text, sondern weitere Markup-Befehle tauchen innerhalb eines äußeren Elements wieder auf. Das heißt der Inhalt eines Elements besteht aus weiteren Inhalten. Um eine Struktur festzulegen, muss man definieren welche Elemente innerhalb von anderen eingesetzt werden dürfen. Beispielsweise darf innerhalb des HTML-Markups <BODY> kein <TITLE> oder <HEAD>-Befehl auftauchen, statt dessen erwartet man dort vielleicht ein <H1>- oder <H2>-Tag.

Um anzugeben welche Tags beispielsweise innerhalb von <adresse> auftauchen dürfen - und in diesem Fall müssen - werden die einzelnen Elemente in Klammern nach dem übergeordneten Element angegeben:

<!ELEMENT vorname  (#PCDATA)>
<!ELEMENT nachname (#PCDATA)>
<!ELEMENT strasse  (#PCDATA)>
<!ELEMENT plz      (#PCDATA)>
<!ELEMENT ort      (#PCDATA)>
<!ELEMENT adresse (vorname, nachname, strasse, plz, ort)>

Auf das zugehörige XML-Dokument angewendet muss eine vollständige Angabe der Adresse also alle angegebenen Elemente enthalten:

<?xml version="1.0"?>
<adresse>
  <vorname></vorname>
  <nachname></nachname>
  <strasse></strasse>
  <plz></plz>
  <ort></ort>
</adresse>

Abb. 3.39: Die einzelnen Elemente als Baumstruktur dargestellt.

Die Angabe der Elemente des Inhalts durch Kommata getrennt, legt nicht nur fest welche Elemente sich innerhalb des Markups <adresse> befinden dürfen, sondern auch in welcher Reihenfolge diese erscheinen müssen.

Alternative Elemente

Um eine Unterscheidung zwischen Postfachadressen und Straßenadressen zu machen, könnte man entweder eine Angabe von <strasse> oder von <postfach> zulassen. Um diese Auswahlmöglichkeit zu bieten, gibt man beiden Alternativen in Klammern und mit einem Strich verbunden an. Es muss und darf also lediglich eins der beiden Elemente vorhanden sein.

<!ELEMENT adresse (vorname, nachname,
                  (strasse | postfach), plz, ort)>

Die Verbindung einzelner Elemente mit einem Balken (»|«) bedeutet eine restriktive logische ODER-Verknüpfung. Das heißt nur eins der Elemente darf ausgewählt werden.

Optionale Elemente

In den vorangegangenen Beispielen war es so, dass alle angegebenen Elemente zwingend erforderlich waren. In der Praxis ist es aber wahrscheinlicher, dass Sie nur vorgeben möchten welche Elemente optional enthalten sein können.

Bei der Definition von HTML-Befehlen mithilfe einer DTD beispielsweise sind die meisten Elemente nicht zwingend erforderlich, sondern optional anzuwenden. Nur in welchem Kontext sie stehen müssen, ist zwingend vorgegeben.

Um diese optionale Wahl zu kennzeichnen, wird dem entsprechend alternativen Element ein Fragezeichen angehängt. Das bedeutet, das Element kann entweder vorhanden sein oder darf genau einmal auftreten.

<!ELEMENT adresse
   (vorname?, nachname, strasse?, plz?, ort?)>

In unserem Beispiel sind bis auf den zwingend erforderlichen Nachnamen alle anderen Angaben optional und können alternativ weggelassen werden.

<?xml version="1.0"?>
<adresse>
  <nachname>
  <ort>
</adresse>

Listen

Ein XML-Dokument wird in der Regel nicht nur aus einer Adresse, sondern aus beliebig vielen Adressen bestehen. Um das umschließende Element, das die gesamte Adressenliste kennzeichnet, zu definieren, müssen wir angeben, welche Elemente sich in der Liste befinden dürfen.

<!ELEMENT liste (adresse)>
Beliebig viele Elemente

Wir greifen hier also auf die zuvor deklarierte Definition der Adresse zurück und setzen diese in die Definition der Liste ein. Mit dem Beispiel haben wir festgelegt, dass <liste> ein <adresse>-Element beinhalten muss. Allerdings bestehen die meisten Listen aus mehreren Adressen, dieses müssen wir noch festlegen.

<!ELEMENT liste (adresse)*>

Das Sternchen hinter der Klammer bedeutet, dass die Liste beliebig viele Elemente des Typs <adresse> enthalten darf. Die Liste darf sogar ganz leer sein.

<?xml version="1.0"?>
<liste>
  <adresse>
    ...
  </adresse>
  <adresse>
    ...
  </adresse>
</liste>
Mindestens ein Element

Möchten wir erzwingen, dass die Adresse beliebig viele, aber mindestens ein Element enthalten muss, kann das über ein angehängtes Pluszeichen erreicht werden.

<!ELEMENT liste (adresse)+>

In der Kombination der vorangegangenen Funktionen könnte man die Struktur eines Buches betrachten. Es besteht aus einer Reihe von Kapiteln, wobei es schon mindestens ein Kapitel sein sollte. Neben Kapiteln erfolgt eine weitere Untergliederung in beliebig viele Absätze:

<!ELEMENT buch (absaetze*, kapitel+)>

Um in unserem obigen Beispiel zuzulassen, dass eine Person aus dem Adressenregister mehrere Vornamen erhalten darf, können wir dieses Element mit einem Sternchen versehen.

<!ELEMENT adresse
   (vorname*, nachname, strasse?, plz?, ort?)>

Gemischter Inhalt

Der Inhalt eines Elements besteht nicht nur aus Text oder weiteren Elementen, sondern er kann auch aus beiden Bestandteilen zugleich bestehen. In diesem Fall spricht man von gemischtem Inhalt. Als Beispiel nehmen wir uns den HTML-Befehl <body> heran. Dieser kann sowohl direkte Texteingaben, aber auch eine Vielzahl von Elementen enthalten.

<!ELEMENT body (#PCDATA|(div|p|h1|h2|h3|h4|h5|h6))*>

Die Anzahl der möglichen Elemente haben wir hier aus verständlichen Gründen etwas verkürzt. Aber das Prinzip des gemischten Inhalt wird deutlich.

<body>
Hier steht Text ohne jede Formatierung
<h1>... und hier eine Überschrift 1. Ordung</h1>
</body>

Element-Deklarationen mit gemischtem Inhalt müssen grundsätzlich mit der Angabe des Schlüsselworts #PCDATA beginnen und erst dann dürfen die weiteren einzelnen Elemente aufgezählt werden. Außerdem müssen die einzelnen Elemente mit einer restriktiven ODER-Verknüpfung (»|«) verbunden sein und mit einem Sternchen geschlossen werden.

Falsche Deklarationen:

<!ELEMENT body (div, p, h1, h2, h3, h4, h5, h6))*>
<!ELEMENT body (div|p|h1|h2|h3|h4|h5|h6)|#PCDATA)*>

Die Unterscheidung des Inhalts nach Daten, Elementen und gemischtem Inhalt ist insbesondere deshalb wichtig, da für gemischte Inhalte eine Ausnahme gilt. Für Elemente gemischten Inhalts kann die Reihenfolge der untergeordneten Inhalte nicht festgelegt werden. Lediglich welche Elemente enthalten sein dürfen wird definiert.

Da diese Unterscheidung auch bei Elementen mit Textinhalt nicht festgelegt werden kann, wird die Bezeichnung gemischter Inhalt (mixed content) eigentlich (ganz korrekt) auch für diesen Datentyp angewendet.

<!ELEMENT vorname (#PCDATA)>

Eine kleine Übersicht über die Möglichkeiten die Elemente zu definieren, die innerhalb eines Elements als Inhalt auftauchen dürfen, gibt die folgende Tabelle:

Zeichen Bedeutung
() Ein oder mehrere Inhaltstypen werden immer in Klammern gesetzt. Auch innerhalb der Klammern lassen sich weitere Gruppen in Klammern setzen.
, Einzelne mit einem Komma verbundene Typen sind mit der logischen Vernüpfung UND verbunden und sind alle erforderlich.
| Einzelne mit einem Strich verbundene Typen, sind mit der logischen Verknüpfung ODER miteinander verbunden und sind optional einzusetzen.
? Das Fragezeichen hinter einer Elementbezeichnung definiert ein optionales Element. Alternativ kann auf das Element verzichtet werden.
* Ein Sternchen deutet an, dass beliebig viele Elemente, also auch Null, eingefügt werden dürfen.
+ Das Pluszeichen bedeutet, dass beliebig viele Elemente größer Null, eingefügt werden dürfen.

Zwei Schlüsselwörter erweitern die Möglichkeiten, die Inhalte eines Elements festzulegen. Mit ANY werden alle Inhalte innerhalb eines Elements, also sowohl Text als auch beliebige Elemente, zugelassen. Mit dem reservierten Namen EMPTY werden leere Elemente, also Elemente ohne Inhalt, gekennzeichnet.

Ein Beispiel für ein solches Element mit beliebigem Inhalt ist das Markup <p>, das einen Absatz markiert.

<!ELEMENT p   ANY>

Das <img>-Tag zum Einfügen von Grafiken in eine Website ist ein typisches Beispiel für ein leeres Element.

<!ELEMENT img EMPTY>
<!ELEMENT br  EMPTY>
<!ELEMENT hr  EMPTY>

Beachten Sie, dass leere Elemente in XML anders als in HTML besonders gekennzeichnet sind, um sie von einem einfachen Start-Tag zu unterscheiden.

<?xml version="1.0"?>
<dokument>
  </img>
  </br>
  </hr>
</dokument>

3.4.5 Attribut Definition

Elemente können durch Attribute weitere Optionen enthalten. So enthalten beispielsweise viele HTML-Tags Attribute, die die Ausrichtung des Elements bestimmen.

<img src="bild.gif" align="left">

Eine allgemeine Attribut-Deklaration besteht aus dem Schlüsselwort ATTLIST, dem Elementnamen, dem das Attribut zugeordnet werden soll, dem Namen des Attributs und dem Wertetyp.

<!ATTLIST elementname name Typ>
<!ATTLIST buch titel CDATA>

Man unterscheidet zwischen drei verschiedenen Attributtypen, die wir im folgenden Abschnitt erläutern werden:

Treten im Wert eines Attributs Entitiy-Abkürzungen auf, so ersetzt der Parser die Entities durch den deklarierten Ersetzungstext und gibt den kompletten Attributwert erst dann an die Anwendung weiter.

Required / Implied

Zusätzlich zum Datentyp lässt sich über den reservierten Namen #REQUIRED (erforderlich) noch ergänzen, ob die Angabe eines Attributs zwingend erforderlich ist. Wird #IMPLIED (impliziert) angegeben, dann muss ein Wert nicht unbedingt angegeben werden.

Eventuell wird das Anwendungsprogramm, sofern nicht angegeben, einen Wert für dieses Attribut ermitteln. Beispielsweise lassen sich bei einer übermittelten Grafik Breite und Höhe des Bildes aus den Bilddaten erkennen, sie können, müssen aber nicht zusätzlich angegeben werden.

Im Beispiel ist eine Angabe des Typs der Telefonnummer unbedingt erforderlich:

<!ATTLIST telefon
   typ (privat|dienstlich|mobil) #REQUIRED>

<?xml version="1.0"?>
<telefon typ="privat"></telefon>

Ein »empfohlenes« aber nicht unbedingt anzugebendes Attribut:

<!ATTLIST align (left|center|right) #IMPLIED>

In HTML ist die Benutzung von Anführungszeichen für die Kennzeichnung von Werten meist reine Nebensache. Man kann sie einsetzen, wenn nicht führt das aber auch zu keinen Problemen. XML verhält sich in diesem Punkt etwas strenger: Der Wert eines Attributs muss immer in Anführungszeichen stehen!

Vorgabewerte

Jedem Attribut kann per Definition ein Wert vorgegeben werden (default), den das Attribut annimmt, wenn kein anderer Wert angegeben ist.

<!ATTLIST align (left|center|right) "left">

Ein Vorgabewert kann auch mit dem Schlüsselwort #FIXED zu einem »festen« Vorgabewert gemacht werden. In diesem Fall kann das Attribut keinen anderen Wert annehmen. Wird ein Wert zugewiesen, so muss dieser mit dem Vorgabewert übereinstimmen.

<!ATTLIST align (left|center|right) #FIXED "left">

Aber auch in dem Fall, dass dem Attribut kein Wert zugewiesen wird, erhält es den Vorgabewert.

Zeichenketten (CDATA)

Wir kennen schon aus der Definition eines Elements den Datentype #PCDATA. Dieses reservierte Wort ist die Abkürzung für »parsed character data«, also vom Parser analysierte und weiterzuverarbeitende Daten. Das Gegenstück zu #PCDATA ist der CDATA-Typ (»character data«). Mit ihm werden Daten deklariert, die vom Parser nicht weiterverarbeitet werden, sondern direkt und ohne Änderung die Applikation erreichen. Parsed character data setzt man ein, wenn Daten Markup-Befehle enthalten, die vom Parser umgesetzt werden sollen.

Für die Werte von Attributen macht es wenig Sinn, diese mit Markups zu versehen und vom Parser bearbeiten zu lassen. Daher verwendet man zur Deklaration immer den Typ CDATA für Attribute, die eine beliebige Zeichenkette als Wert enthalten dürfen..

<!ATTLIST buch  titel CDATA #IMPLIED
                autor CDATA #IMPLIED>

<?xml version="1.0"?>
<liste>
<buch           titel="Kaizen"
                autor="Masaaki Imai">
</buch>
</liste>

Aufzählung

Neben der Eingabe von beliebigen Textdaten als Wert für ein Attribut, lassen sich auch eine Reihe von Werten (eine Aufzählung) vorgeben aus denen ein Wert auszuwählen ist. Typische Beispiele aus HTML sind die Angaben für die Ausrichtung: hier lässt sich zwischen "left", "middle" und "right" wählen.

In unserem Beispiel erstellen wir für eine Adresse ein Attribut, das aussagt, ob es sich um eine private Adresse handelt oder nicht.

<!ATTLIST adresse privat (ja|nein)>
<!ATTLIST adresse privat (j|n|ja|nein|Ja|Nein|JA|NEIN)>

Eingesetzt in das XML-Dokument, muss der Wert des Attributs natürlich in Anführungszeichen angegeben werden. In diesem Fall ist ein gültiger Wert für das Attribut nur "ja" oder "nein". Groß- und Kleinschreibung wird auch hier unterschieden.

<?xml version="1.0"?>
<adresse privat="ja">
</adresse>

Für den Fall, dass das Attribut in die XML-Datei gar nicht angegeben wird, kann man eine Voreinstellung (»default«-Wert) vornehmen. Die gewünschte Auswahl wird in Anführungszeichen an die Deklaration angefügt.

<!ATTLIST adresse privat (ja|nein) "nein">

Schlüsselwörter

Es existieren mehrere Attribut-Typen, die zusammengefasst als »tokenized types« bezeichnet werden. Diese Typen besitzen die reservierten Namen:

ENTITY   (ENTITIES)
ID
IDREF    (IDREFS)
NMTOKEN  (NMTOKENS)
NOTATION (NOTATIONS)

Bis auf das erste Schlüsselwort "ID" existiert also von allen weiteren Typen auch der Plural. Dieser findet immer dann Verwendung, wenn einem Attribut gleichzeitig mehrere Werte eines Typs übergeben werden sollen.

<!ATTLIST adresse id ID #REQUIRED>

Im Element adresse wird ein Attribut Namens id und mit dem Typ ID angelegt.

Über die Verknüpfungen zwischen verschiedenen Elementen könnte man im Beispiel die verwandtschaftlichen Beziehungen innerhalb einer Adressendatei speichern.

<!ATTLIST adresse id ID #REQUIRED>
<!ATTLIST adresse ref IDREF #REQUIRED>
<?xml version="1.0"?>
<liste>
   <adresse id="10" ref="20">
   </adresse>
   <adresse id="20" ref="30">
   </adresse>
   <adresse id="30" ref="10">
   </adresse>
   <adresse id="40" ref="10">
   </adresse>
</liste>

Über die Pluralform IDREFS kann gleichzeitig eine ganze Liste von Verknüpfungen in einem Wert übergeben werden. Die einzelnen Verknüpfungen werden durch Leerzeichen voneinander getrennt.

<!ATTLIST adresse ref IDREFS>

<?xml version="1.0"?>
<liste>
<adresse id="10" ref="20 30 40">
...
</liste>

<!ENTITY produkt_1 SYSTEM
   "images/produkt01.jpg"
   NDATA
   JPEG>
<!ATTLIST bild quelle ENTITY>

Zunächst wird das Entity und das Attribut quelle des Elements bild definiert. Das Entity wird dann im XML-Dokument dem Attribut als Wert übergeben.

<?xml version="1.0"?>
<bild quelle="produkt_1"></bild>

Auch in diesem Fall dient die Pluralform ENTITIES zur Übergabe mehrerer Entity-Namen getrennt durch Leerzeichen.

<!ATTLIST artikel kuerzel NMTOKEN>

Mithilfe der Pluralform NMTOKENS lassen sich mehrere Namen getrennt mit Leerzeichen als Wert übergeben.

<!ATTLIST bild typ NOTATION>

In der Notation definieren wir einen Typ "gif" und einen Pfad zur Anwendung, mit denen unser Bild angezeigt werden kann.

<!NOTATION gif
SYSTEM "http://www.domain.de/bin/viewer.exe">

Im XML Dokument wird dann dieser definierte Typ als Wert des Attributs übergeben:

<?xml version="1.0"?>
<bild typ="gif"></bild>

Beachten Sie, dass in unserem Beispiel die Bilddaten selbst noch nicht mit übergeben wurden. Diese Übergabe muss über ein weiteres Attribut erfolgen.

Auch die Pluralform ist in diesem Fall mit NOTATIONS definiert. Mehrere Notationen können mit Leerzeichen getrennt angegeben werden.

3.4.6 Datentyp Notation

In der Notation werden Datenformate definiert auf die bei der Anzeige oder Verarbeitung von binären Daten verwiesen werden kann. In der Notation ist festgelegt, mit welcher Anwendung externe Daten, die nicht zur Verarbeitung mit dem Parser bestimmt sind, behandelt werden sollen. Eine Notation könnte festlegen, was die Anwendung mit Daten beispielsweise der folgenden Formate anfangen soll:

Diese Formate werden in der Datentype Notation innerhalb der DTD deklariert. Hier einige Beispiele wie die Deklaration zu verwenden ist:

<!NOTATION pdf SYSTEM "http://www.domain.de/bin/viewer.exe">
<!NOTATION htm PUBLIC "-//W3C//DTD HTML 3.2//EN">
<!NOTATION gif87a SYSTEM "GIF">
<!NOTATION doc SYSTEM "winword.exe">
<!NOTATION xls SYSTEM "Microsoft Excel 9.0">

Neben der Option SYSTEM für Zugriffe auf Hilfsapplikationen, die über eine URL zugewiesen werden, kann für öffentlich zugängliche Definitionen auch PUBLIC als Schlüsselwort gewählt werden.

Das Problem bei der Verwendung von Notationen ist zurzeit noch, dass die Struktur des übergebenen Wertes noch nicht standardisiert ist. Sie können also vom Programmnamen bis zum URL-Pfad alle möglichen Informationen angeben. Was dann daraus gemacht wird und wie die Werte interpretiert werden ist einzig Sache der Anwendung. So lange diese wichtige Schnittstelle noch nicht genormt ist, ist die Verwendung der Notation immer abhängig von der zugehörigen Applikation.

3.4.7 Bedingte Abschnitte

Manchmal kann es notwendig sein bestimmte Abschnitte einer DTD vom Parsing auszuklammern. Für diesen Fall können so genannte bedingte Abschnitte (conditional sections) in eine DTD eingebaut werden. Allerdings lassen sich bedingte Abschnitte ausschließlich in externen und nicht in internen Document Type Definitions einrichten.

Wird ein Abschnitt mit dem Schlüsselwort IGNORE gekennzeichnet, so werden diese Zeilen einfach ignoriert und nicht vom Parser verarbeitet.

<![IGNORE[
  <!ELEMENT kommentar (#PCDATA)>
]]>

Das Gegenstück zu IGNORE lautet INCLUDE. Ein mit INCLUDE eingeleiteter Abschnitt wird bei der Verarbeitung berücksichtigt.

<![INCLUDE[
  <!ELEMENT kommentar (#PCDATA)>
]]>

Ein Beispiel für den Einsatz solcher bedingten Abschnitte, ist das Einfügen von Kommentaren in ein Dokument. In einem Fall möchten Sie diese vielleicht bei der Ausgabe mit berücksichtigen und später bei der endgültigen Präsentation der Daten sollen diese Kommentare wieder verschwinden.

Nun wäre es äußerst unpraktisch, wenn Sie jedesmal das gesamte Dokument durchgehen und alle INCLUDE-Abschnitte in INGNORE-Anweisungen umwandeln müssten. Für diesen Fall gibt es eine etwas elegantere Lösung indem man Parameter-Entities einsetzt.

Externe DTD »dokument.dtd«

In einer externen DTD werden die Abschnitte statt mit den Anweisungen mithilfe von zwei Parameter-Entities markiert. Diesen Entities werden dann die gewünschten Werte INCLUDE und IGNORE zugewiesen.

<!ENTITY % entwurf "INCLUDE">
<!ENTITY % fertig "IGNORE">

<![%entwurf;[
  <!ELEMENT dokument (daten*, kommentar*)>
]]>

<![%fertig;[
  <!ELEMENT dokument (daten*)>
]]>

Wird diese DTD angewendet, so wird der komplette Text inklusive der Kommentare ausgegeben. Der zweite Abschnitt, der dafür sorgt, dass die Kommentare wegfallen, wird aufgrund des Attributs IGNORE vom Parser übergangen.

Möchte man später zu dieser Ausgabemöglichkeit greifen, muss man keine Zeile der externen DTD ändern, sondern man führt diese Änderungen einfach in der internen DTD durch. Man tauscht also die Werte IGNORE und INCLUDE aus und erhält damit die gewünschte Ausgabeform.

Dabei macht man sich die Tatsache zunutze, dass Definitionen von Entities in einer internen DTD immer die gleichlautenden Definitionen in der externen DTD überschreiben.

<!DOCTYPE dokument SYSTEM "dokument.dtd">
<!DOCTYPE praesentation SYSTEM
[
   <!ENTITY % entwurf "IGNORE">
   <!ENTITY % fertig "INCLUDE">
]>

3.4.8 Besondere Attribute

Leerraum

Leerzeichen oder Leerraum (engl. White Space) ist sehr einfacher Inhalt eines Dokuments. Dennoch kann er gerade, wenn Sie mithilfe von Leerzeichen etwas »Übersicht« in Ihr Dokument gebracht haben, von nicht unerheblicher Bedeutung sein.

Zu Definition des Leerraums gehören insgesamt vier unsichtbare und unscheinbare, aber wichtige Zeichen:

Die Behandlung von Leerraum ist in XML genauso schonungslos wie in HTML. Jede Stelle, an der mehr als ein Leerzeichen vorkommt, wird von überschüssigen Leerzeichen befreit und erst dann vom Parser weitergegeben. Manchmal kann es notwendig sein wichtigen Leerraum so zu erhalten wie er eingegeben wurde. Diesen wichtigen Leerraum bezeichnet man als signifikant.

Um dem Parser mitzuteilen wann Leerraum signifikant und wann insignifikant ist, deklarieren Sie ein neues Attribut des Typs:

xml:space

Das Attribut kann die Werte »default« und »preserve« annehmen. Der voreingestellte Wert, also die oben beschriebene Vorgehensweise lässt sich über das Schlüsselwort »default« erreichen. Soll signifikanter White Space gerettet und erhalten werden, wählen Sie »preserved«.

<!ATTLIST absatz xml:space (default|preserve) "preserve">

Auf das folgende Beispiel angewandt, ergibt sich eine Ausgabe, in der Leerzeichen innerhalb des <text>-Markups erhalten bleiben.

<!ATTLIST text xml:space (default|preserve) "preserve">
<?xml version="1.0"?>
<text xml:space="preserve">
         Wort

   Wort
      Wort
         Wort
</text>

Identifikation der Sprache

Das Attribut xml:lang wird eingesetzt, um die verwendete Sprache eines Dokuments oder eines Abschnitts und der Attribute eines Elements zu definieren.

xml:lang

Ähnlich wie xml:space wird auch xml:lang als Attribut definiert. Gültige Werte für das Attribut enthält der NMTOKEN-Typ.

<!ATTLIST prosa xml:lang NMTOKEN "en">
<!ATTLIST p xml:lang NMTOKEN "en">

Die voreingestellten Werte können überschrieben werden und bei jedem Aufruf des Attributs verändert werden:

<?xml version="1.0"?>
<prosa xml:lang="de">
   <p xml:lang="en">      Englisch</p>
   <p xml:lang="en-US">   Englisch (USA)</p>
   <p xml:lang="en_UK">   Englisch (United Kingdom)</p>
   <p xml:lang="de">      Deutsch</p>
   <p xml:lang="de-DE">   Deutsch (Deutschland)</p>
   <p xml:lang="de-CH">   Deutsch (Schweiz)</p>
</prosa>

Eine Übersicht über die verwendeten Sprachencodes finden Sie im Anhang unter der Norm ISO 639.

3.5 XML Beschreibung

Nachdem Sie im vorangegangenen Abschnitt erfahren haben, wie man eine Document Type Definition deklariert, erläutern wir nun wie die definierten Markups in einem XML-Dokument eingesetzt werden können. Wir wenden uns jetzt also von der DTD ab zum eigentlichen XML-Dokument.

3.5.1 Entity-Referenzen

Wird innerhalb des XML-Dokuments auf in der DTD deklarierte Entities verwiesen, so spricht man von einer Entity-Referenz. Das Einfügen von analysierten Entities in den Quelltext haben wir schon erwähnt. Die Entity-Bezeichnung wird mit einem kaufmännischen Und ("&") eingeleitet und mit einem Semikolon (";")abgeschlossen.

Etwas aufwendiger ist das Einfügen von nicht-analysierten Entities in den Quelltext. Diese werden in der Regel eingesetzt, um beispielsweise Grafiken in das Dokument einzufügen. Eine Grafik in HTML lässt sich vergleichsweise einfach einfügen:

<IMG SRC="logo.gif">

Nicht-analysierte Entities dürfen nicht einfach in den Text eingefügt werden. Sie benötigen ein Element, dem sie als Wert eines Attribut mitgegeben werden Der Wertebereich des Attributs muss als ENTITY deklariert werden.

<!ELEMENT image>
<!ATTLIST image quelle ENTITY>
<!ELEMENT logo SYSTEM "logo.gif" NDATA GIF>

Für das Element <image> wurde das Attribut quelle vom Type ENTITY definiert. Im XML-Dokument wird das Entity logo als Wert übergeben. Dabei müssen nicht wie sonst üblich die Zeichen »&« und »;« angegeben werden.

<?xml version="1.0"?>
<dokument>
   <image quelle="logo">
</dokument>

3.5.2 Elemente

Dieser Abschnitt behandelt zunächst den Einsatz von Elementen innerhalb eines XML-Dokuments. Die benutzen Markups müssen aber vorher in einer zugehörigen DTD definiert werden, darüber klärt Sie dann der Abschnitt über die Erstellung einer eigenen Document Type Definition auf.

Abb. 3.40: Ein Element besteht aus Start- und End-Tag, die den Inhalt umschließen.

Die korrekte Definition eines Elements ist also das Zusammenspiel zwischen Start- und End-Tag und dem eingeschlossenen Inhalt. Die in HTML noch übliche Gleichsetzung von Tag und Element ist also nicht richtig und sollte gerade in XML auseinandergehalten werden. Als Ausnahme existieren auch Elemente ohne Inhalt.

Abb. 3.41: Korrekte Verschachtelung von Elementen

Falsche Verschachtelung von Elementen

Eine falsche Verschachtelung von Elementen liegt vor, wenn ein äußeres Tag noch vor dem inneren Tag geschlossen wird.

<?xml version="1.0"?>
<ADRESSE>
<NAME> </ADRESSE>
</NAME>

Korrekte Verschachtelung von Elementen

Bei richtiger Verschachtelung der Elemente ergibt sich eine hierarchische Baumstruktur der einzelnen Elemente. Zur richtigen Verschachtelung gehört auch, dass ein äußeres Wurzelelement existiert, dass alle inneren Elemente umschließt. Die richtige Verbindung der Elemente ist ein Kriterium für Wohlgeformtheit.

<?xml version="1.0"?>
<ADRESSE>
<NAME></NAME>
</ADRESSE>

Abb. 3.42: Die meisten XML-Editoren, wie das Microsoft XML Notepad erzeugen automatisch wohlgeformten Quellcode.

3.5.3 Attribute

Die Deklaration von Attributen in einer Document Type Definition haben wir in den vorangegangenen Abschnitten ausführlich erläutert. Jetzt geht es darum diese Attribute im XML-Dokument zu nutzen.

Welchen Wert ein Attribut überhaupt enthalten darf, bestimmt in erster Linie der definierte Typ des Attributs.

Attribut-Typ Wertebereich
CDATA Alle Zeichen
ID Eindeutige Bezeichnung des einzelnen Elements.
IDREF Verweis auf die ID eines Elements.
IDREFS Verweis auf die IDs mehrerer Elemente.
ENTITY Verweis auf ein Entity.
ENTITIES Verweis auf mehrere Entities.
NMTOKEN Gültige Namensbezeichnung.
NMTOKENS Mehrere gültige Namensbezeichnungen.

Beispiele:

   <adresse id="1">
   <image quelle="http://www.domain.de/bild.gif">
   <song titel="River Of Dreams">
   <daten ref="&referenz;">

3.5.4 Stylesheets referenzieren

Über eine Processing Instruction kann man dem Parser mitteilen, dass dem Dokument zusätzlich noch eine Stylesheet-Definition zugehört. Diese kann entweder vom Typ XSL oder CSS sein. Sie wird in jedem Fall innerhalb des Dokument referenziert:

<?xml:stylesheet type="text/xsl" href="style.xsl" ?>
<?xml:stylesheet type="text/css" href="style.css" ?>

In dem Sonderfall, dass gleichzeitig ein XSL- und CSS-Stylesheet im XML-Dokument referenziert ist, wird automatisch das XSL-Stylesheet bevorzugt behandelt.

3.6 XML Data Island

Dieser Abschnitt behandelt die Möglichkeiten, XML-Quellcode auch innerhalb eines HTML-Dokuments einzusetzen.

Es besteht die Möglichkeit innerhalb des HTML-Codes eine so genannte XML Dateninsel anzulegen. Diese Dateninsel wird durch zwei umschließende XML-Tag markiert. Innerhalb der Dateninsel muss sich ein wohlgeformtes XML-Dokument befinden. Alle aus XML bekannten Funktionen wie Processing Instructions oder DOCTYPE Deklarationen sind zugelassen.

<HTML>
<HEAD>
</HEAD>
<BODY>
<XML ID="XMLID">
<adresse>
   <name>      Meier </name>
   <telefon>   12345 </telefon>
</adresse>
</XML>
</BODY>
</HTML>

Alternativ muss der XML-Quellcode nicht intern im HTML-Dokument enthalten sein, sondern kann extern ausgelagert sein. In diesem Fall erfolgt lediglich ein Verweis auf das XML-Dokument:

<XML ID="XMLID" SRC="adressen.xml"></XML>

Wichtig ist in jedem der beiden Alternativen, dass man dem XML-Element eine eindeutige ID zuweist. Mithilfe dieser ID kann man auf den Inhalt der Dateninsel zugreifen:

adresse.documentNode.childNodes.item(1).nodeValue

Aus diesem Aufruf erhält man beispielsweise das Element "12345" als Ergebnis.

3.7 XML-Dokumente im Browser anzeigen

Der Zugriff auf XML-Datenquellen innerhalb eines HTML-Dokuments und der Anzeige im Browser erfolgt mithilfe von JavaScript-Befehlen. Der Browser muss dazu einen installierten Parser aufweisen. Von Microsoft wird ein XML-Parser als ActiveX-Objekt angeboten und lässt sich damit leicht in die Microsoft Internet Explorer 4.0 und 5.0 integrieren.

Um auf ein XML-Dokument zugreifen zu können, muss zunächst im HTML-Dokument ein XML Document Object eingerichtet werden. Dieses wird mithilfe eines neuen ActiveX Objekts mit der Programm ID "microsoft.xmldom" erreicht.

var xml = new ActiveXObject ("microsoft.xmldom");

Dem gesamten Dokument ist jetzt das Objekt xml zugewiesen worden. Die Variable xml, die als Inhalt das Dokumenten-Objekt enthält, ermöglicht uns erst den Zugriff auf die komplexe Datenstruktur des Dokuments.

Nachdem das neue Objekt erstellt ist, kann auf die Daten zugegriffen werden, aber es können auch Veränderungen am Objekt durchgeführt werden.

Dann muss als nächster Schritt das neue Objekt mit Inhalt gefüllt werden, dazu wird ein XML-Dokument geladen und gleich an das Objekt übergeben. Dabei sollte lediglich auf korrekte Schreibweise der URL geachtet werden.

xml.load("MeinDokument.xml");

Um das Wurzelelement des XML-Dokuments herauszubekommen, wird die Eigenschaft »dcoumentNode« in einer neuen Variable gespeichert.

var docRoot = xml.documentNode;

Das vollständige JavaScript-Programm:

<HTML>
<SCRIPT LANGUAGE="JSCRIPT" FOR="window" EVENT="onload">
var indent_array = new String (" ");
var str = "";

var xml = new ActiveXObject("microsoft.xmldom");
xml.load ("pdcxml.xml");

var docroot = xml.documentNode;
output_doc(docroot, 0);
function output_doc(node, intents)
   {
   var i;
   if (node.nodeType == 0) // 0 ist die Element-Wurzel
      {
      document.all(results").insertAdjacentText
      ("BeforeEnd",
      indent_array.substring(0,(4 * indents))
      + "<" + elem.tagName + ">" + "\n");

   if (node.childNodes != null)
      {
      for (i = 0 ; i < node.childNodes.length ; i++)
      output_doc(node.childNodes.item(i),
      (indents + 1));
      document.all ("results").insertAdjacenText
      ("BeforeEnd"),
      indent_array.substring(0,
      (4 * indents))
      + "</" + elem.tagName + ">" + "\n");
      }
   else if (node.nodeType == 1)
   {
   document.all("results").insertAdjacentText
   ("BeforeEnd", indent_array.substring(0, (4 * indents))
   + "\"" + elem.text + "\"\n");
   }
   else
   alert ("Unbekannter Element-Typ: " + node.node.Type);
}
</SCRIPT>
<BODY>
</BODY>
</HTML>

Bei der Verwendung solcher Skripte ist es wichtig, dass der Browser mindestens JavaScript in der Version 1.2 unterstützt. Der untenstehenden Tabelle können Sie die JavaScript-Fähigkeiten der einzelnen Versionen entnehmen:

Browser JavaScript 1.0 JavaScript 1.1 JavaScript 1.2 JavaScript 1.3
NS Navigator 2.0 x      
NS Navigator 3.0 x X    
NS Navigator 4.0 x X x  
NS Navigator 4.5 x X x x
MSI Explorer 3.0 x      
MSI Explorer 4.0 x X x  
MSI Explorer 5.0 x X x x

3.8 Erweiterte XML-Syntax

3.8.1 Hypertext Links

Eine der wesentlichen Eigenschaften von Hypertext ist die Möglichkeit Verknüpfungen mit anderen Dokumenten oder Textstellen zu erstellen. Dieser wichtige Abschnitt taucht erst jetzt in diesem Buch auf, da die Erstellung und Deklaration von Links sich in XML wesentlich umfangreicher und flexibler verhält als in HTML und gewisse Grundkenntnisse in XML notwendig sind.

In HTML lässt sich ein Hyperlink relativ schnell und unkompliziert einbinden:

<A HREF="http://www.domain.de">Link</A>

Bisher liegen diese Erweiterungen zu XML zwar erst im Entwurf vor. Aber die seit März 1998 im Umlauf befindlichen Vorschläge werden bestimmend für die Hyperlink-Fähigkeiten von XML sein. Die Hyperlink-Definition wird häufig auch als Extensible Linking Specification oder »XML Spezifikation Teil 2« benannt, da sie in Zukunft sicherlich voll in die XML-Definition einfließen wird. Allerdings kann man auch davon ausgehen, dass diese Entwürfe noch gewissen Änderungen unterliegen.

Der XML-Standard ist zwar offiziell verabschiedet, bis jedoch alle nachgelagerten technologischen Erweiterungen den Status der offiziellen Verabschiedung erlangen werden noch einige Monate vergehen.

Aktuelle Informationen über die Aktivitäten und Fortschritte der Linking-Sprache erhalten Sie im Internet unter:

http://www.sil.org/sgml/xll.html
http://www.w3.org/TR/WD-xml-link

Aufgrund des geringen Funktionsumfangs und der eingeschränkten Flexibilität der HTML Hyperlinkfunktionen hat man diese nicht einfach übernommen, sondern sich an den Fähigkeiten von SGML orientiert.

XML Linking Language (XLL)

Es existieren zwei parallele Linking-Entwürfe (»Working Drafts«) für XML:

An beide Entwürfe sind Eve Maler (von ArborText) und Steve DeRose (von der Inso Cooperation) maßgeblich beteiligt. Grundlagen für die Entwicklung der Funktionsvielfalt der Linking-Befehle waren:

Grundsätzlich sollte ein Hyperlink zumindest mit den folgenden Fähigkeiten oder Attributen ausgestattet sein:

Terminologie

Vorab einige Begriff, die in den offiziellen Vorschlägen zum Standard immer wieder auftauchen:

Begriff Bedeutung
element tree
Repräsentiert die Struktur eines Dokuments. Alle Objekte einer Seite lassen sich in diese Baumstruktur einordnen und ermöglichen so den Zugriff auf einzelne Elemente, Inhalte und Attribute.
Link
Eine deklarierte Beziehung oder Verbindung zwischen zwei oder mehr Objekten.
linking element
Das Element, das den Link beschreibt und damit den eigentlichen Hyperlink darstellt.
Locator
Ein Attribut des Links, das angibt auf welche Quelle oder Quellen der Link verweist (Definition des Sprungziels).
resource
Eine Datenquelle, auf die ein Link gelegt werden kann. Möglicher Wert eines Sprungziels.
sub-resource
Unterteilung der Datenquelle (resource) in weitere Gliederungen. Gibt sehr präzise das Ziel eines Link wieder.
multidirectional link
Ein Link, den man gleichzeitig von der Sprungmarke und vom Sprungziel in beide Richtungen verfolgen kann.
traversal
Die Aktion, die ausgelöst wird, sobald der Anwender den Link betätigt oder der Link automatisch ausgelöst wird. In der Regel erfolgt der direkte Zugriff auf die Datenquelle.
out-of-line link
Ein Link, dessen Inhalt sich nicht direkt in der im Attribut übergebenen Adresse befindet, sondern der beispielsweise den Browser anweist an anderer Stelle nach den Links zu suchen. In der Regel setzt man solche Links ein, wenn eine Verknüpfung nicht nur mit einem sondern mit mehreren Datenquellen stattfindet.

Interne Verknüpfungen

Eine erste Möglichkeit Elemente einer Seite miteinander zu verknüpfen haben Sie schon kennengelernt:

Der Verweis über das IDREF-Attribut auf eine eindeutig festgelegte ID.

<!ATTLIST adresse id  ID    #REQUIRED>
<!ATTLIST adresse ref IDREF #REQUIRED>

<?xml version="1.0"?>
<liste>
<adresse id="10" ref="20"></adresse>
<adresse id="20" ref="10"></adresse>
</liste>

Die Fähigkeiten dieser Funktion besteht allerdings eher daraus Beziehungen zwischen verschiedenen Objekten einer Seite herzustellen. Für eine vollständige Implementation eines Link fehlen noch wichtige Elemente.

Xlink

Einfache Links

Die Möglichkeiten der einfachen Link-Funktion entsprechen nahezu denen, die uns auch ein HTML-Link bietet. Zur Unterscheidung zwischen »einfachen« und »erweiterten« Links wird der Wert "simple" als Attribut übergeben.

Über das Attribut xlink:form wird angegeben, um welche Art von Link es sich handelt (erweitert oder einfach). Die Angabe eines Werts ist unbedingt erforderlich ("#REQUIRED").

<!ATTLIST a xlink:form CDATA #REQUIRED>

Wenn Sie nur »einfache« Links zulassen möchten, können Sie den Wert des Attributs als "simple" fixieren.

<!ATTLIST a xlink:form CDATA #FIXED "simple">

<?xml version="1.0"?>
<a xlink:form="simple" href="http://www.microsoft/xml">
Link auf die Microsoft Homepage
</a>

In einem weiteren Arbeitspapier zur XML-Linking Sprache wurde der Vorschlag aufgebracht, dass die Bezeichnung eines Links statt durch xml:link durch xlink:form zu erfolgen hat. Achten Sie also auf die aktuellen Veröffentlichungen des W3C. Wir verwenden hier die aktuelle Form, vielleicht taucht in dem einen oder anderen Dokument, das Sie im Internet finden, aber noch die alte Schreibweise auf.

Die Adressangabe erfolgt in XML parallel zu HTML nach RFC 1738 in der Schreibweise einer URI (Uniform Resource Identifier). Also:

http://www.domain.de/seite.htm

Sollte die Seite unter der gleichen Adresse zu erreichen sein, wie das Hauptdokument aus dem der Link aufgerufen wird, reicht natürlich auch die Angabe der Seite aus:

seite.htm

Ähnlich wie in HTML lassen sich auch Verknüpfungen auf Teile eines Dokuments legen. Diese Verweise werden nach dem Doppelkreuz (»#«) angegeben. Der Unterschied zu HTML liegt hier in der Angabe dieser präzisen sub-resource. Denn der Datentyp eines solchen Sprungziels muss ein Xpointer sein. Taucht eine Bezeichnung nach dem Doppelkreuz auf, die kein Xpointer ist, so wird automatisch angenommen, dass es sich um den Attributwert einer Element-ID handelt.

<a xlink:form="simple" href="http://www.microsoft/home.htm#10">
Link auf die Microsoft Homepage, Absatz 10
</a>

Die Möglichkeiten eines einfachen Link werden im Xlink Vorschlag kurz definiert:

Auch der einfache Xlink darf schon eine ganze Reihe von weiteren Attributen enthalten. Zunächst eine komplette Auflistung der möglichen Attribute und darauf folgend eine Erläuterung zu den einzelnen Attributen und deren Verwendung:

<!ELEMENT simple ANY>
<!ATTLIST simple
xlink:form          CDATA             #FIXED "simple"
href          CDATA            #REQUIRED

role          CDATA            #IMPLIED
title          CDATA            #IMPLIED
show          (embed|replace|new)            #IMPLIED
actuate          (auto|user)            #IMPLIED
behavior          CDATA            #IMPLIED

content-role          CDATA            #IMPLIED
content-title          CDATA            #IMPLIED

inline      (true|false)        "true"
>
Locator:
<!ENTITY href CDATA #REQUIRED>

Der Locator definiert über eine Zeichenkette eine Datenquelle als Sprungziel. Jeder Link muss mindestens eine solche Ressource definieren. Er enthält die Adressangabe des Link.

Link Semantics:
<!ENTITY inline (true|false) "true">

Das Attribut inline kann die Werte »wahr« (true) oder »falsch« (false) annehmen. Es gibt Auskunft darüber, ob es sich um einen inline-Link handelt (voreingestellter Wert) oder um einen »out-of-line«-Link. Ein inline-Link enthält die Spungadresse direkt im href-Attribut. Beim out-of-line-Link befindet sich die Adressangabe dagegen in einem im Linkelement eingeschlossenen Element.

Remote-Resources:

Die Informationen, die im Abschnitt Remote-Resources behandelt werden, sind in der Regel für die weiterverarbeitende Empfänger-Applikation gedacht. Beispielsweise könnte ein Browser diesen Wert verarbeiten und dem Anwender in Form von zusätzlichen Funktionen zur Verfügung stellen.

<!ENTITY role CDATA #IMPLIED>

Optional wird der Software-Anwendung die Bedeutung und Funktion des Link mitgeteilt. Links können verschiedene Beziehungsgeflechte zwischen Daten-Objekten widerspiegeln. Um die Rolle eines Link im Dokument zu speichern und beispielweise mitzuteilen, dass es sich um eine Hintergrundinformation zum Thema handelt, kann dieses Attribut angewendet werden.

Diese Option gilt allerdings nur für die erweiterten Links. Bei einfachen Links wird für das Attribut role automatisch ein Wert vorgegeben. Bei inline-Links ist dann Alternativ das Attribut content-role zu verwenden.

<!ENTITY title CDATA #IMPLIED>

Der Titel eines Link gibt dem Anwender Auskunft über die Bedeutung und den Inhalt der Verknüpfung. Eine Applikation sollte diese Daten auslesen und dem Anwender als sichtbare Bezeichnung des Link zur Verfügung stellen.

Diese Option gilt nur für erweiterte Links. Bei einfachen Links wird für das Attribut title automatisch ein Wert vorgegeben. Bei inline-Links ist dann alternativ das Attribut content-title zu verwenden.

<!ENTITY show (embed|replace|new) #IMPLIED>

Über das Attribut show kann die Anwendung veranlasst werden das neu geöffnete Dokument im Browser auf bestimmte Art und Weise zu behandeln:

embed Das Dokument wird in den Textkörper des vorhandenen XML-Dokuments eingefügt und zwar an der Stelle an der sich der Link befindet.

replace Die neue Datenquelle ersetzt in der Zeit in der ein Link aktiv ist das aktuelle Dokument und tritt an dessen Stelle. Die vorherige Datenquelle wird abgelöst.

new Eine neue Instanz der Applikation, beispielsweise ein neues Browserfenster, wird geöffnet. Die neue Datenquelle wird in diesem Fenster unabhängig vom vorherigen Kontext angezeigt.

<!ENTITY actuate (auto|user) #IMPLIED>

Bestimmt den Intervall der Aktualisierung der neuen Datenquelle.

auto Die Datenquelle wird automatisch aktualisiert. Also sobald ein Link aktiviert wird, startet der Übertragungsprozess. Alle automatisch angeforderten Datenquellen werden in der Reihenfolge des Aufrufs übertragen.

user Der Anwender muss die Datenquelle manuell aktualisieren. Das heißt die Applikation sollte den Benutzer darauf hinweisen, dass eine externe Datenquelle geöffnet wird. Nur mit ausdrücklicher Zustimmung, beispielsweise über ein eingeblendetes Dialogfenster, wird die Datenquelle tatsächlich angefordert und geöffnet.

<!ENTITY behavior CDATA #IMPLIED>

Neben den vorgegebenen Attributen zur Steuerung des Verhaltens der Anwendung mit der neu angeforderten Datenquelle, kann über behavior eine Zeichenkette übergeben werden, in der der Autor weitere nicht genormte Instruktionen zum Verhalten übermittelt.

Local-Resources:

Wurde der Link als inline-Link angelegt, so können weitere Angaben über die lokale Datenquelle gemacht werden. Einfache Links sind in der Regel immer als inline-Link definiert. Die beiden Attribute content-role und content-title ersetzen in inline-Links die Attribute role und title.

<!ENTITY content-role CDATA #IMPLIED>

Optional wird der Software-Anwendung die Bedeutung und Funktion des Link mitgeteilt.

<!ENTITY content-title CDATA #IMPLIED>

Der Titel eines Link gibt dem Anwender Auskunft über die Bedeutung und den Inhalt der Verknüpfung. Eine Applikation sollte diese Daten auslesen und dem Anwender als sichtbare Bezeichnung des Link zur Verfügung stellen.

Als Beispiel für die Verwendung eines einfachen Link folgt jetzt die Definition eines HTML-ähnlichen Link unter Einsatz einiger oben genannter Optionen.

<!ELEMENT   meinlink      (#PCDATA)>
<!ATTLIST   meinlink
            xlink:form    CDATA        #FIXED "simple"
            href          CDATA        #REQUIRED
            inline        (true|false) "true"
            content-role  CDATA        #IMPLIED
            content-title CDATA        #IMPLIED>

<?xml version="1.0"?>
<meinlink
   href="http://www.domain.de/lebenslauf.htm"
   content-title="Lebenslauf Bill Gates"
   content-role="Personeninfos">
   Infos über Bill Gates</meinlink>

Erweiterte Links

Die beeindruckendsten neuen Funktionen der erweiterten Links sind die Verbindung eines Link mit einer Vielzahl von Datenquellen, die alle gleichzeitig auf dem Bildschirm aktualisiert werden können.

Um einen Link zum erweiterten Link zu klassifizieren muss zumindest das Attribut xlink:form den Wert "extended" erhalten. Ob Sie diesen Wert fest zuweisen, als Voreinstellung übergeben oder erst im Element festlegen bleibt dabei Ihnen überlassen:

<!ATTLIST extended xlink:form CDATA #FIXED "extended">
<!ATTLIST extended xlink:form CDATA "extended">

<!ATTLIST extended xlink:form CDATA>
<extended xlink:form="extended">

Jedes Element, das ein Attribut mit der Bezeichnung xlink:form enthält, wird vom Parser automatisch als Link vom Typ Xlink erkannt. Bisher haben Sie zwei Werte kennengelernt, die dem Attribut übergeben werden können. In der folgenden Tabelle finden Sie noch weitere Optionen.

Wert Bedeutung
"simple" Einfacher Link.
"extended" Link mit erweitertem Funktionsumfang.
"locator" Das Kindelement eines erweiterten Link.
"group" Eine Gruppe von erweiterten Links.
"document" Ein Dokument, das eine »group« enthält.

Mithilfe des erweiterten Link ist es möglich eine Verknüpfung nicht nur mit einem Dokument, sondern mit mehreren Datenquellen zugleich aufzubauen. Gelöst wird dieses Feature indem ein Hauptelement (extended) und ein entsprechendes Kindelement (locator) definiert wird.

extended Dieses Element enthält die äußere Definition des Link. In das Element werden die Kindelemente eingesetzt.

locator In das Element extended werden beliebig viele Elemente des Typs locator eingesetzt. Diese Kindelemente enthalten die eigentlichen Links.

Zunächst die Definition des äußeren Links extended und seine Attribute:

<!ELEMENT extended ANY>
<!ATTLIST extended
          xlink:form      CDATA #FIXED "extended"
          inline          (true|false) "true"
          role            CDATA #IMPLIED
          content-role    CDATA #IMPLIED
          content-title   CDATA #IMPLIED
>

Jetzt wird das Kindelement locator definiert, dieses enthält als Einziges ein href-Attribut zur Angabe der Link-Ressource:

<!ELEMENT locator ANY>
<!ATTLIST locator
          xlink:form      CDATA #FIXED "locator"
          href            CDATA #REQUIRED
          role            CDATA #IMPLIED
>

Beide Elemente ineinander verschachtelt ergeben einen erweiterten Link:

<extended     xlink:form="extended"
              inline="false"
   <locator   href="http://www.domain.de/kapitel1.xml"
              role="Kapitel 1"
   <locator   href="http://www.domain.de/kapitel2.xml"
              role="Kapitel 2"
   <locator   href="http://www.domain.de/kapitel3.xml"
              role="Kapitel 3"
   <locator   href="http://www.domain.de/kapitel4.xml"
              role="Kapitel 4"
</extended>

Das Element extended muss jetzt mit dem Attribut inline="false" versehen werden, da die Definition der Links nicht direkt als Attribut, sondern über das Element locator realisiert ist. In obigem Listing besteht der Inhalt des übergeordneten Elements, (hier: extended) ausschließlich aus locator-Elementen. Trotzdem wurden in diesem Fall auch andere Inhalte zugelassen, da das Attribut ANY eingesetzt wurde. Die Kindelemente müssen immer in direkter Verbindung zum Vaterelement stehen, weitere und tiefere Verschachtelungen sind nicht zulässig.

Es hängt natürlich, wie so oft, vom Browser oder der umgebenden Applikation ab, ob und wie solche Links mit mehreren Sprungzielen realisiert werden. Der Browser muss dem Anwender Einfluss auf die Wahl des richtigen Link anbieten.

Links lassen sich auch zu Gruppen verbinden, man spricht dann von einer erweiterten Link-Gruppe.

<!ELEMENT  group (document*)>
<!ATTLIST  group
           xlink:form   CDATA #FIXED "group"
           steps        CDATA #IMPLIED
>

<!ELEMENT  document     EMPTY
<!ATTLIST  document
           xlink:form   CDATA #FIXED "document"
           href         CDATA #REQUIRED
>

<?xml version="1.0"?>
<group xlink:form="group">
   <document href="kapitel1.html"/>
   <document href="kapitel2.html "/>
   <document href="kapitel3.html "/>
   <document href="kapitel4.html "/>
</group>

XPointer

Xlink mit seinen einfachen und erweiterten Links bietet uns schon zahlreiche Möglichkeiten auf externe Dokumente zu verweisen und eine Website zu verknüpfen. Xpointer können aber noch präziser auf die Struktur des Dokuments reagieren und Verknüpfungen auf einzelne Elemente setzen.

Es existieren verschiedene Möglichkeiten auf Elemente einer Seite zuzugreifen: Absolute Verweisausdrücke, relative Verweise und Verweise auf Attribute, Zeichenketten und Bereiche.

Die Suche wird anhand von vier Schlüsselwörtern gesteuert.

3.8.2 Namensräume

Ein Problem mit Namensräumen folgt immer dann, wenn Dokumente zu erstellen sind, die Teile von anderen XML-Dokumenten einsetzen. In diesem Fall kann es dazu kommen, dass Namen doppelt vergeben sind, weil vielleicht mehrere Autoren an den Dokumenten gearbeitet haben.

Wenn diese nicht koordiniert miteinander arbeiten oder fremde Dokumente genutzt werden, kann es leicht zu solchen Überschneidungen kommen. Immer dann, wenn gleiche Namen für Elemente verschiedenen Typs vergeben wurden, treten Probleme auf. Gerade im Hinblick auf die größere Verbreitung von öffentlich zugänglichen Dokumenten-Definitionen wird eine Lösung dieses Konflikts immer drängender.

Zurzeit entsteht ein Entwurf des W3C, der diese Probleme lösen soll. Es geht dabei darum, für häufig vorkommende Elemente standardisierte Namen und Deklarationen zu vergeben. Beispielsweise könnte ein Element zur Preisauszeichnung in Online-Shops definiert werden und von weiteren Autoren weiterverwendet werden.

Gerade für den Austausch von Daten wären solche einheitlichen Auszeichnungen von Vorteil. Man könnte dann beispielsweise einer Suchmaschine den Auftrag erteilen, ein bestimmtes Produkt zu einem niedrigen Preis zu suchen. Sollten sich alle Online-Shops an die gleiche Dokumenttyp-Deklaration halten, würde das kein Problem darstellen. Die Suchmaschine durchsucht die Artikelbezeichnungen nach dem gewünschten Produkt und findet im Preiselement den passenden Verkaufspreis.

<artikel>
   <bezeichnung>            Palm Pilot III          </bezeichnung>
   <einzelpreis>            699          </einzelpreis>
   <waehrung>            DM          </waehrung>
   <versandkosten>            7,80          </versandkosten>
</artikel>

Ein anfänglicher Vorschlag zur Lösung des »Namenproblems« sah vor, ein Bezeichnungsschema über die Processing Instruction einzubinden. Im Folgenden wird erst eine interne Namensdefinition geladen und dann ein externes Schema hinzugezogen:

<?xml:namespace
    ns="http://www.domain.de/namespace"
    prefix="intern">
<?xml:namespace
    ns="http://www.shop.de/namspace"
    prefix="shop">

In der XML-Datei wird die Unterscheidung zwischen den Namen vorgenommen, indem der definierte Name für den Namespace mit einem Doppelpunkt dem Namen des Elements vorangestellt wird.

<shop:artikel>
<intern:artikel>
<intern:artikel intern:auslaufmodell="ja">

Eine komplettes XML-Dokument könnte dann wie folgt aussehen:

<shop:artikel>
    <shop:bezeichnung>Palm Pilot III</shop:bezeichnung>
    <intern:lieferant>3COM Deutschland</intern:lieferant>
    <shop:einzelpreis>699</shop:einzelpreis>
    <shop:waehrung>DM</shop:waehrung>
    <shop:versandkosten>7,80</shop:versandkosten>
</artikel>

Es gab allerdings bis heute noch keine Einigung auf einen einheitlichen Standard der Bezeichnung von Namensräumen. Man sollte aber mit Blick auf die Zukunft bei der Verwendung von Doppelpunkten in den eigenen Namensbezeichnern sparsam sein, sonst steht bei Verabschiedung des Standards eine größere Umstellung an.