document type definition (DTD)
Die dtd im Detail
Deklarierung einer externen dtd
Einen Teil der dtd extern,den anderen intern deklarieren
Entities
Externe Entity
Namensräume (namespaces)

document type definition (DTD)

nach oben

Eine document type definition (dtd) ermöglicht es, für eine bestimmte Gruppe von XML Dokumenten ein bestimmtes Format zu erzwingen. Man stelle sich folgendes Szenario vor. In einem Unternehmen sollen sich bestimmte Arbeitsgruppen darstellen. Jede Arbeitsgruppe erstellt also ein XML Dokument, in der die Projekte beschrieben werden, an denen gearbeitet wird, die Mitarbeiter, der Ansprechpartner der Gruppe, Adresse, Budget etc. Weiter stellen wir uns vor, dass diese XML Dokumente über ein XSLT Stylesheet in eine HTML Seite konvertiert wird und dann im Internet publiziert wird. Das kann nur funktionnieren, wenn alle Dokumente die gleiche Struktur haben. Es kann nicht sein, dass eine Gruppe ein Element projekte hat und die andere ein Element Projekte, da das XSLT Stylesheet die XML Seiten nur auslesen kann, wenn sie alle gleich strukturiert sind. In solch einem Zusammenhang macht es Sinn, die Einheitlichkeit der XML Dokumente über eine dtd zu erzwingen. Das bedeutet konkret, dass Dokumente, die dieser Vorgabe nicht entsprechen, schon im Vorfeld als falsch erkannt werden können und dann gar nicht weiter verarbeitet werden. Das Beispiel unten zeigt fast alle Möglichkeiten einer document type definition.

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Projekte
[
<!ELEMENT Projekte (Gruppe+)>
<!ELEMENT Gruppe (Gruppenname,Kollegen,Ansprechpartner,Adresse,(Budget|Kostenvoranschlag),Kommentar*)>
<!ELEMENT Gruppenname ANY>
<!ELEMENT Kollegen (Mitarbeiter+)>
<!ELEMENT Mitarbeiter (#PCDATA)>
<!ELEMENT Ansprechpartner (#PCDATA)>
<!ELEMENT Adresse (Strasse?,Ort?)>
<!ELEMENT Strasse (#PCDATA)>
<!ELEMENT Ort (#PCDATA)>
<!ELEMENT Budget (#PCDATA)>
<!ELEMENT Kostenvoranschlag (#PCDATA)>
<!ELEMENT Kommentar (#PCDATA)>
<!ATTLIST Mitarbeiter Firma CDATA "Arthur de Little">
<!ATTLIST Gruppenname stand CDATA "Wird bald abschiffen">
<!ATTLIST Ansprechpartner Telefon CDATA "030-453452344444" Ident ID #REQUIRED>
<!ATTLIST Strasse Gegend CDATA #IMPLIED>
<!ATTLIST Kommentar Sinn CDATA #FIXED "kurz und bündig">
<!ENTITY comment "Hauptsache die Kasse stimmt">
]>
<Projekte>
<Gruppe>
<Gruppenname stand="abgeschifft">Berliner Verwaltungsreform</Gruppenname>
<Kollegen>
<Mitarbeiter Firma="Price Waterhouse">Werner Lepinski</Mitarbeiter>
<Mitarbeiter>Erika Saufwech</Mitarbeiter>
<Mitarbeiter>Hans Geldfliech</Mitarbeiter>
</Kollegen>
<Ansprechpartner Telefon="030-435555" Ident="A_1">Otto Moltoimportante</Ansprechpartner>
<Adresse>
<Strasse Gegend="teures Pflaster">Kurfürstendamm 5</Strasse>
<Ort>13453 Berlin</Ort>
</Adresse>
<Budget>40 000000</Budget>
<Kommentar>&comment;</Kommentar>
</Gruppe>
<Gruppe>
<Gruppenname>Hamburger Verwaltungschaos </Gruppenname>
<Kollegen>
<Mitarbeiter Firma="Arthur de Little">Werner Nordflut</Mitarbeiter>
<Mitarbeiter>Marina Meimportauncarajo</Mitarbeiter>
<Mitarbeiter>Peter Wessnich</Mitarbeiter>
</Kollegen>
<Ansprechpartner Ident="A_2">Ludwig Noresponsable</Ansprechpartner>
<Adresse>
<Strasse>An der Waterkant 15</Strasse>
<Ort>45555 Hamburg</Ort>
</Adresse>
<Kostenvoranschlag>30 000000</Kostenvoranschlag>
</Gruppe>
</Projekte>

Betrachten wir das mit dem Internet Explorer, erhalten wir etwas in der Art.

Hierbei ist folgendes zu beachten. Die Tatsache, dass der Internet Explorer eine korrekt definierte dtd richtig darstellt, was er, wie obiges Beispiel zeigt, tatsächlich tut, heisst noch lange nicht, dass er falsche dtds erkennt. Er tut es nicht. Die Prüfung auf Gültigkeit erfolgte in diesem Falle nicht mit dem Internet Explorer sondern über http://www.stg.brown.edu/service/xmlvalid/. Hier hat man die Möglichkeit, ein XML Dokument auf Gültigkeit überprüfen zu lassen. Ein XML Dokument ist dann gültig, wenn es die Struktur des XML Teils nach Maßgabe der dtd Richtlinien richtig beschreibt. Wir erkennen an diesem Beispiel, dass man mit dtds mehr machen kann, als lediglich die Struktur eines XML Dokumentes zu beschreiben, obwohl dies der primäre Zweck einer dtd ist. Man kann mit entities auch Textblöcke definieren und diese in das XML Dokument einfügen. Man beachte den Satz "Hauptsache die Kasse stimmt". Wie unschwer zu erkennen, ist es weit schwieriger, ein gültiges XML Dokument zu schreiben als ein wohlgeformtes. Betrachten wir kurz die Bestandteile, wo XML die Möglichkeiten von XML erweitert und diskutieren dann die dtd im Detail. Schauen wir uns einmal diese drei Zeilen an.

Alle drei Zeilen definieren Attribute für unteschiedliche Elemente. 1) legt fest, dass der Ansprechpartner das Attribut Telefon und Ident hat, 2) dass Strasse das Attribut Gegend hat und 3), dass Kommentar das Attribut Sinn hat. Wir sehen also, dies zeigt 1), dass mehrere Attribute auf einmal deklariert werden. Wir sehen weiter, dass die Wirkung der Deklaration eines Attributs davon abhängt, ob die Vorgabedeklaration REQUIRED, IMPLIED oder FIXED ist. Telefon zum Beispiel hat gar keine Vorgabedeklaration. Was bewirkt das ? Das bewirkt, dass die Nummer "030-45345234444" immer dann eingesetzt wird, wenn das Element Ansprechpartner selbst dieses Attribut nicht hat. Wenn wir das Bild betrachten sehen wir, dass beim ersten Ansprechpartner 030-435555 erscheint, den hier haben wir einen Wert definiert. Beim zweiten Ansprechpartner haben wir keinen Wert definiert, folglich erscheint der Default "030-453452344444". Der Ident wiederum ist vom Typ ID, das heisst, der dazugehörige Attributwert darf nur einmal auftauchen, was er hier ja auch tut, der Wert des Attributs Ident bei Ansprechpartner hat einmal den Wert A_1 und einmal den Wert A_2. Würde A_1 zweimal auftauchen, wäre es kein gültiges Dokument. Weiter haben wir definiert, das ein Wert für dieses Atrribut required, dass heisst zwingend, ist. Gäbe es einen Ansprechpartner ohne Ident, wäre es kein gültiges Dokuement. Bei 2) deklarieren wir für die Strasse die Gegend. Als Vorgaberichtlinie geben wir implied an. Wird implied benutzt, dann wird kein Wert eingesetzt, wenn bei dem entsprechenden Element dieses Attribut nicht vorhanden ist, es muss also explizit angegeben werden, von implied (impliziert) ist eigentlich keine Rede. Wir sehen deutlich, dass bei der Strasse der zweiten Gruppe, kein Attribut vorhanden ist. Schluss endlich deklarieren wir noch bei Komentar das Attribut Sinn mit Fixed. Dies bewirkt, dass der Wert "kurz und bündig" überall eingefügt wird, wo das entsprechende Element auftaucht. Wir sehen also, dass sich hinsichtlich Attributen sehr präzise Vorgaben machen lassen. Weiter haben wir in unsere dtd noch eine Entity definiert.

<!ENTITY comment "Hauptsache die Kasse stimmt">

Auch Entities bieten uns Möglichkeiten, die wir mit normalem XML nicht haben. Wenn wir wollen, können wir eine Entity als eine Konstante ansehen, der wir einen Wert zuweisen und die wir dann immer wieder aufrufen. Im obigen Beispiel sehen wir, dass wir bei Kommentar die Entity wieder aufrufen.

<Kommentar>&comment;</Kommentar>

Im Browser sehen wir dann an der Stelle "Hauptsache die Kasse stimmt".

Die dtd im Detail

nach oben

Die Syntax einer dtd Deklaration ist gewöhnungsbedürftig, aber eigentlich klar.

Zwischen den eckigen Klammern steht die eigentliche Deklaration. Gehen wir die verschiedenen Deklarationen durch und machen uns klar, was passiert.

1) definiert das Wurzelelement. Dieses hat nur ein einziges Element, nämlich Gruppe. Wir müssen bedenken, dass wir nur die Hierarchiestufe direkt unterhalb von Projekte angeben. Alle anderen Elemente sind ja gekapselt in Gruppe, so dass sie hier nicht erscheinen, weil sie nicht unterhalb von Projekt stehen, sondern noch eine Hierarchiestufe tiefer. Wir legen fest, dass Gruppe mindestens einmal ( das Pluszeichen + zeigt das an) oder beliebig oft vorkommen kann. Würde man das Pluszeichen weg lassen, hiesse das, dass das Element Gruppe nur einmal auftaucht, was ja falsch wäre und folglich ein ungültiges XML Dokument darstellen würde. In 2) deklarieren wir die Elemente der Gruppe. Elemente der Gruppe sind Gruppenname, Kollegen, Ansprechpartner, Adresse, Budget, Kostenvoranschlag und Kommentar. Man beachte, dass die Elemente in der Reihenfolge auftauchen müssen, wie sie im XML Dokument auftauchen, sonst erhält man kein gültiges XML Dokument. Mach beachte auch, dass, aus den selben Gründen wie oben, die Elemente Strasse, Ort und Mitarbeiter hier nicht definiert werden dürfen. Strasse und Ort sind Elemente von Adresse und Mitarbeiter ist ein Element von Kollegen. Sie sind also eine Hierarchiestufe weiter unten. Jedes dieser Elemente muss einmal auftauchen. Wir setzen also weder ein + Zeichen (einmal oder mehr), noch einen * (null Mal oder mehr) noch ein ?, was diesselbe Bedeutung hätte wie der Stern, sich allerdings auf das Element unmittelbar davor bezieht. Nun haben wir noch eine runde Klammer und fragen uns nach deren Bedeutung. Wenn wir die zwei Gruppen in unserem XML Dokument genau betrachten, stellen wir fest, dass sie nicht identisch sind. Wo die erste Gruppe das Element Budget hat, hat die zweite Gruppe das Element Kostenvoranschlag. Wenn wir also unsere XML Datei korrekt durch eine document type definition beschreiben wollen, müssen wir festlegen, dass entweder das Element Budget oder das Element Kostenvoranschlag vorkommen darf. Die Pipe oder der Balken ( | ) steht hier für oder. Ähnlich verhält es sich mit dem Element Kommentar. In der ersten Gruppe ist es da, in der zweiten nicht. Folglich müssen wir festlegen, dass dieses Element auch null Mal vorkommen kann, was wir mit dem Stern machen. Anschliessend deklarieren wir das Element Gruppenname. Wenn wir wissen, dass hier immer Text steht (der wiederum konform sein muss zum deklarierten Zeichensatz, in unserem Falle ISO-8859-1, hätten wir auch schreiben können PCDATA. Wenn wir nicht wissen, was da so erscheinen kann, schreiben wir ANY. Wir tun aus didaktischen Gründen mal so, als ob wir das nicht wüssten. Als nächstes haben wir das Element Kollegen, das das Element Mitarbeiter enthält. Dann deklarieren wir das Element Mitarbeiter. Mitarbeiter darf jede Art von Text enthalten, der mit unserem Zeichensatz kompatibel ist, aber keine Markup Elemente, also Zeichen, die XML interpretieren würde, dafür bräuchten wir ja CDATA. Desgleichen Ansprechpartner. Das Element Adresse wiederum hat zwei Elemente, die null mal vorkommen können, was wir hier nicht haben, oder einmal. Der Rest geht dann nach dem gleichen Schema weiter.

Deklarierung einer externen dtd

nach oben

Die dtd kann auch ausserhalb des XML Dokumentes, also in einer separaten Datei gespeichert werden, wobei es hier wiederum zwei Möglichkeiten gibt. Entweder wird die gesamte dtd extern gehalten oder aber es gibt zusätzlich zur externen dtd noch eine interne. Im zuletzt genannten Fall, überschreibt die interne dtd die Teile, die in der externen anders lauten.
Wir machen für diesen Fall aus der externen dtd eine eigene Datei und speichern sie als beratungsunternehmen.dtd im gleichen Verzeichnis, wie die XML Datei. Natürlich hätte wir auch einen virtuellen Pfad, also sowas der Art http://www.irgendeine_domain.de/irgend_ein_Ordner/beratungsunternehmen.dtd verwenden können. (Nebenbemerkung: Eine Datei mit der Endung .dtd lässt sich nicht abspeichern, weil windows diese Endung nicht kennt, und folglich .txt dranhängt. Dass kann man verhindern, wenn man bei Abspeichern den Dateinnamen in Anführungszeichen setzt also "Unternehmensberatung.dtd" anstatt Unternehmensberatung.dtd. )

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

<!ELEMENT Projekte (Gruppe+)>
<!ELEMENT Gruppe (Gruppenname,Kollegen,Ansprechpartner,Adresse,(Budget|Kostenvoranschlag),Kommentar*)>
<!ELEMENT Gruppenname ANY>
<!ELEMENT Kollegen (Mitarbeiter+)>
<!ELEMENT Mitarbeiter (#PCDATA)>
<!ELEMENT Ansprechpartner (#PCDATA)>
<!ELEMENT Adresse (Strasse?,Ort?)>
<!ELEMENT Strasse (#PCDATA)>
<!ELEMENT Ort (#PCDATA)>
<!ELEMENT Budget (#PCDATA)>
<!ELEMENT Kostenvoranschlag (#PCDATA)>
<!ELEMENT Kommentar (#PCDATA)>
<!ATTLIST Mitarbeiter Firma CDATA "Arthur de Little">
<!ATTLIST Gruppenname stand CDATA "Wird bald abschiffen">
<!ATTLIST Ansprechpartner Telefon CDATA "030-453452344444" Ident ID #REQUIRED>
<!ATTLIST Strasse Gegend CDATA #IMPLIED>
<!ATTLIST Kommentar Sinn CDATA #FIXED "kurz und bündig">
<!ENTITY comment "Hauptsache die Kasse stimmt">

Die eigentliche XML Datei sieht dann so aus.

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Projekte SYSTEM "Unternehmensberatung.dtd">
<Projekte>
<Gruppe>
<Gruppenname stand="abgeschifft">Berliner Verwaltungsreform</Gruppenname>
<Kollegen>
<Mitarbeiter Firma="Price Waterhouse">Werner Lepinski</Mitarbeiter>
<Mitarbeiter>Erika Saufwech</Mitarbeiter>
<Mitarbeiter>Hans Geldfliech</Mitarbeiter>
</Kollegen>
<Ansprechpartner Telefon="030-435555" Ident="A_1">Otto Moltoimportante</Ansprechpartner>
<Adresse>
<Strasse Gegend="teures Pflaster">Kurfürstendamm 5</Strasse>
<Ort>13453 Berlin</Ort>
</Adresse>
<Budget>40 000000</Budget>
<Kommentar>&comment;</Kommentar>
</Gruppe>
<Gruppe>
<Gruppenname>Hamburger Verwaltungschaos </Gruppenname>
<Kollegen>
<Mitarbeiter Firma="Arthur de Little">Werner Nordflut</Mitarbeiter>
<Mitarbeiter>Marina Meimportauncarajo</Mitarbeiter>
<Mitarbeiter>Peter Wessnich</Mitarbeiter>
</Kollegen>
<Ansprechpartner Ident="A_2">Ludwig Noresponsable</Ansprechpartner>
<Adresse>
<Strasse>An der Waterkant 15</Strasse>
<Ort>45555 Hamburg</Ort>
</Adresse>
<Kostenvoranschlag>30 000000</Kostenvoranschlag>
</Gruppe>
</Projekte>

Auch das funktionniert mit dem Internet Explorer. Wir sehen also, dass der Internet Explorer bei einer dtd zwar lediglich die Syntax abprüft und nicht den Inhalt, so dass man mit dem Internet Explorer die Gültigkeit eines Dokumentes nicht überprüfen kann, aber er stellt trotzdem alles korrekt dar, das heisst, dass er z.B. entities erkennt und in das XML Dokument einbaut. Wir erhalten auch mit der externen dtd das gleiche Bild wie oben.

Einen Teil der dtd extern,den anderen intern deklarieren

nach oben

Wir könnten genauso gut auch nur einen Teil der dtd extern und den anderen Teil intern deklarieren. Das sieht dann so aus.

<?xml version="1.0" encoding="ISO-8859-1"?>
<!ELEMENT Kommentar (#PCDATA)>
<!ATTLIST Mitarbeiter Firma CDATA "Arthur de Little">
<!ATTLIST Gruppenname stand CDATA "Der Rubel rollt, wir diskutieren noch.">
<!ATTLIST Ansprechpartner Telefon CDATA "030-453452344444" Ident ID #REQUIRED>
<!ATTLIST Strasse Gegend CDATA #IMPLIED>
<!ATTLIST Kommentar Sinn CDATA #FIXED "Wenn du nicht mehr weiterweißt, bilde einen Arbeitskreis">
<!ENTITY comment "Hauptsache die Kasse stimmt">

Die XML Datei hat dann die andere Hälfte der dtd und sieht so aus.

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Projekte SYSTEM "Unternehmensberatung.dtd"
[
<!ELEMENT Projekte (Gruppe+)>
<!ELEMENT Gruppe (Gruppenname,Kollegen,Ansprechpartner,Adresse,(Budget|Kostenvoranschlag),Kommentar*)>
<!ELEMENT Gruppenname ANY>
<!ELEMENT Kollegen (Mitarbeiter+)>
<!ELEMENT Mitarbeiter (#PCDATA)>
<!ELEMENT Ansprechpartner (#PCDATA)>
<!ELEMENT Adresse (Strasse?,Ort?)>
<!ELEMENT Strasse (#PCDATA)>
<!ELEMENT Ort (#PCDATA)>
<!ELEMENT Budget (#PCDATA)>
<!ELEMENT Kostenvoranschlag (#PCDATA)>
]>
<Projekte>
<Gruppe>
<Gruppenname stand="abgeschifft">Berliner Verwaltungsreform</Gruppenname>
<Kollegen>
<Mitarbeiter Firma="Price Waterhouse">Werner Lepinski</Mitarbeiter>
<Mitarbeiter>Erika Saufwech</Mitarbeiter>
<Mitarbeiter>Hans Geldfliech</Mitarbeiter>
</Kollegen>
<Ansprechpartner Telefon="030-435555" Ident="A_1">Otto Moltoimportante</Ansprechpartner>
<Adresse>
<Strasse Gegend="teures Pflaster">Kurfürstendamm 5</Strasse>
<Ort>13453 Berlin</Ort>
</Adresse>
<Budget>40 000000</Budget>
<Kommentar>&comment;</Kommentar>
</Gruppe>
<Gruppe>
<Gruppenname>Hamburger Verwaltungschaos </Gruppenname>
<Kollegen>
<Mitarbeiter Firma="Arthur de Little">Werner Nordflut</Mitarbeiter>
<Mitarbeiter>Marina Meimportauncarajo</Mitarbeiter>
<Mitarbeiter>Peter Wessnich</Mitarbeiter>
</Kollegen>
<Ansprechpartner Ident="A_2">Ludwig Noresponsable</Ansprechpartner>
<Adresse>
<Strasse>An der Waterkant 15</Strasse>
<Ort>45555 Hamburg</Ort>
</Adresse>
<Kostenvoranschlag>30 000000</Kostenvoranschlag>
</Gruppe>
</Projekte>

Auch dies funktionniert mit dem Internet Explorer, das heisst er zeigt alles korrekt an, prüft aber nicht, ob das Dokument gültig ist. Mit dieser Methode wäre es also möglich, für alle XML Dokumente eines bestimmten Typs eine allgemeine dtd extern zu halten und Spezifikationen intern.

Entities

nach oben

Mit Entities kann man entweder komplette XML Dateien, Textblöcke oder Dateien in eine XML Seite einbinden. Hierbei können die Entities entweder intern, das heisst im Dokument selbst oder extern, in anderen Dokumenten gehalten werden. Bei Entities unterscheidet man zwischen geparsten und nicht geparsten. Die Diskussion ist in der Literatur immer etwas kompliziert, aber ich glaube man kann das abkürzen. Geparste Entities enthalten Inhalt, der vom XML Parser interpretiert werden kann und den er folglich auch interpretiert. Nicht geparste Entities enthalten Inhalt, wie zum Beispiel Bilder, die der XML Parser nicht interpretieren kann, was ihn dann veranlasst, es zu lassen. Das folgende Beispiel zeigt eine geparste und eine nicht geparste Entity.

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE TESTAT
[
<!ELEMENT TESTAT (TEST_EINS,TEST_ZWEI)>
<!ELEMENT TEST_EINS ANY>
<!ELEMENT TEST_ZWEI (#PCDATA)>
<!ELEMENT NAME (#PCDATA)>
<!ENTITY EINS "Der Name des Künstlers ist <NAME>Andrés Ehmann</NAME>">
<!ENTITY ZWEI "Das Wetter ist grau">
]>
<TESTAT>
<TEST_EINS>
&EINS;
</TEST_EINS>
<TEST_ZWEI>
&ZWEI;
</TEST_ZWEI>
</TESTAT>

Wir haben also die Entity EINS, die selber ein Element enthält, also etwas was der XML Parser parsen will. Da es gemischten Inhalt enthält, geben wir als Elementinhaltsspezifikation am besten ANY an, das heisst irgendwas. Würden wir hier PCDATA angeben, wäre es kein gültiges Dokument, weil das was nachher im XML Dokument aufgerufen wird, ja ein Misch ist aus XML Syntax und Text. Das Element TEST_EINS darf also nicht PCDATA sein, weil der Inhalt des Elementes geparst wird. Entity ZWEI wiederum darf PCDATA sein, weil die ENTITY ZWEI, die wir in das Element TEST_ZWEI reinziehen, nur reinen Text enthält.

Externe Entity

nach oben

Mit einer externen Entity kann man auf externe Ressourcen zugreifen, zum Beispiel komplette XML Seiten in die aktuelle XML Seite reinziehen. Nehmen wir an, wir hätten diese XML Datei.

<?xml version="1.0" encoding="ISO-8859-1"?>
<TEST_DREI>
Über die Heide
hallet mein Schritt
dumpf aus der Erde
wandert es mit
Herbst ist gekommen
Frühling ist weit
gab es denn einmal
selige Zeit
grau ist das Haus
und der Himmel so leer
warum nur bin ich hier gegangen im Mai
Leben und Liebe
wie flog es vorbei

Theodor Storm
</TEST_DREI>

Dann könnten wir mit dieser XML Datei die obige XML Datei reinziehen. Die obige XML Datei muss hierfür im selben Ordner liegen, wie die XML Datei unten. Sie muss unter dem Namen ausgelagert.xml abgespeichert werden (Nebenbemerkung: Natürlich kann man sich auch ins Netz schieben und sie dann über einen virtuellen Pfad aufrufen).

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE TESTAT
[
<!ELEMENT TESTAT (TEST_EINS,TEST_ZWEI,TEST_DREI)>
<!ELEMENT TEST_EINS ANY>
<!ELEMENT TEST_ZWEI (#PCDATA)>
<!ELEMENT TEST_DREI (#PCDATA)>
<!ELEMENT NAME (#PCDATA)>
<!ENTITY EINS "Der Name des Künstlers ist <NAME>Andrés Ehmann</NAME>">
<!ENTITY ZWEI "Das Wetter ist grau">
<!ENTITY DREI SYSTEM "ausgelagert.xml">
]>
<TESTAT>
<TEST_EINS>
&EINS;
</TEST_EINS>
<TEST_ZWEI>
&ZWEI;
</TEST_ZWEI>
&DREI;
</TESTAT>

Auch das funktionniert mit dem Internet Explorer, wenn er auch das Dokument nicht korrekt auf Gültigkeit prüft. Entscheidend ist hierbei diese Zeile.

<!ENTITY DREI SYSTEM "ausgelagert.xml">

Im Browser sehen wir dann sowas in der Art.

Namensräume (namespaces)

nach oben

Nehmen wir an, wir haben zwei XML Dokumente und diese enthalten gleichnamige Elemente. In diesem Fall muss es eine Möglichkeit geben, die Elemente aus dem einen Dokument von dem Element in dem anderen Dokument zu unterscheiden. Dies gelingt mit Hilfe von Namensräumen. Das Prinzip ist eigentlich easy and straighforward. Wir haben eine Element default mit dem Namen namen_des_elements und eines aus einem anderen Namensraum mit Präfix:namen_des_elementes. Ein XML Dokument mit verschiedenen Namensräumen sieht dann so aus.

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE obstundgemüse
[
<!ELEMENT obstundgemüse (obst,gemüse)>
<!ATTLIST obstundgemüse
xmlns CDATA #REQUIRED
xmlns:g CDATA #REQUIRED>

<!ELEMENT obst (fruchtsorte+)>
<!ELEMENT fruchtsorte (name,herkunftsland,Güteklasse)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT herkunftsland (#PCDATA)>
<!ELEMENT Güteklasse (#PCDATA)>
<!ELEMENT gemüse (gemüsesorte+)>
<!ELEMENT gemüsesorte (g:name,g:herkunftsland,g:Güteklasse)>
<!ELEMENT g:name (#PCDATA)>
<!ELEMENT g:herkunftsland (#PCDATA)>
<!ELEMENT g:Güteklasse (#PCDATA)>
]
>
<obstundgemüse
xmlns="http://www.interessiert_keine_Sau.de"
xmlns:g="http://www.interessiert_kein_Schwein.de">

<obst>
<fruchtsorte>
<name>Apfel</name>
<herkunftsland>Deutschland</herkunftsland>
<Güteklasse>A</Güteklasse>
</fruchtsorte>
<fruchtsorte>
<name>Birne</name>
<herkunftsland>Holland</herkunftsland>
<Güteklasse>AA</Güteklasse>
</fruchtsorte>
</obst>
<gemüse>
<gemüsesorte>
<g:name>Gurke</g:name>
<g:herkunftsland>Venezuela</g:herkunftsland>
<g:Güteklasse>BA</g:Güteklasse>
</gemüsesorte>
<gemüsesorte>
<g:name>Kartoffel</g:name>
<g:herkunftsland>Österreich</g:herkunftsland>
<g:Güteklasse>AB</g:Güteklasse>
</gemüsesorte>
</gemüse>
</obstundgemüse>

vorhergehendes Kapitel	nach oben	nächstes Kapitel