XML-Syntax

   
Haupttext 
Glossar 
Fragen und Antworten   
 
 
 
1. Zielpublikum
2. Einige Grundbegriffe
     2.1 Dokumenttyp-Definition (DTD)
     2.2 Elemente
     2.3 Attribute
     2.4 Entities
     2.5 Parser und Anwendung
     2.6 Zwei Arten, ein Dokument zu überprüfen
     2.7 Zwei unterschiedliche Arten, ein Dokument zu betrachten
     2.8 Erweiterbarkeit
3. Prolog / interne und externe Untermenge
     3.1 XML-Deklaration
     3.2 Dokumenttyp-Deklaration
4. Elemente
     4.1 Elementtyp-Deklaration
     4.2 Inhaltsmodelle mit EMPTY und ANY
     4.3 Element-Inhalt und Gemischter Inhalt
5. Attribute
     5.1 Attribut-Vorgaben
     5.2 Normalisierung von Attribut-Werten
6. Entities
     6.1 Allgemeine Entities versus Parameter-Entities
     6.2 Geparste versus nicht-geparste Entities
     6.3 Interne versus externe Entities
     6.4 Entities im Überblick
     6.5 Fünf Arten von Entities (Beispiele für die Deklaration)
     6.6 Entity-Referenzen
7. Notation-Deklarationen
8. Gültigkeit und Wohlgeformtheit / validierende und nicht-validierende Parser
     8.1 Gültigkeit
     8.2 Wohlgeformtheit
     8.3 Validierende und nicht-validierende Parser
9. Groß- und Kleinschreibung
10. Namen
11. Kommentare
12. CDATA-Abschnitte / Vordefinierte Entities
13. Processing Instructions
14. Bedingte Abschnitte
15. System Identifier und Public Identifier
16. Identifikation der Sprache
17. Behandlung von Leerraum
18. Zeichenkodierung / Unicode
     18.1 Zeichenkodierung in Entities: die Text-Deklaration
     18.2 Unicode
     18.3 Zeichen-Referenzen
 

1. Zielpublikum

Wer sollte sich mit der XML-Syntax beschäftigen?  

2. Einige Grundbegriffe

2.1 Dokumenttyp-Definitionen (DTDs)

Wer bisher als Web-Designer HTML-Dateien erstellt hat, bekam mit den Dokument-Typ-Definitionen (DTDs) selten zu tun. Größere Aufmerksamkeit erhalten die DTDs unter Web-Designern erst mit dem Aufkommen von XML.

In Dokumenttyp-Definitionen (DTDs) werden Regeln für den Aufbau von Dokumenten geliefert. In den HTML-DTDs zum Beispiel ist festgelegt, daß es <H1>-, <H2>-, <H3>-Tags geben kann und daß solch ein Tag ein align-Attribut enthalten kann, so daß ein Gebilde wie <H4 align="center"> möglich ist.

Für den Verfasser von XML-Dokumenten macht sich die Verwendung von DTDs in erster Linie als Einschränkung bemerkbar. Es können nur bestimmte Elemente verwendet werden, und die DTD legt auch fest, wie die Elemente verschachtelt werden müssen und von welcher Art die Werte der Attribute sein müssen.

Die Disziplin, die sich der Dokument-Verfasser auferlegt, bringt Vorteile mit sich: Dadurch, daß alle Dokumente gleichen Regeln folgen, ist es möglich, Anwendungen zu schaffen, die die Informationen aus den Dokumenten auslesen und automatisch verarbeiten.

Eine Dokumenttyp-Definition kann in einer separaten Datei untergebracht werden; man spricht dann von einer externen DTD (oder auch von einer externen DTD-Untermenge). Die Definitionen können aber auch an den Anfang von einem Dokument erscheinen. In diesem Fall spricht man von einer internen DTD (bzw. einer internen DTD-Untermenge).

Die XML-Spezifikation liefert zu all dem die übergeordneten Regeln. Das heißt, die Spezifikation liefert die Anleitung für das Erstellen von DTDs.

Ein fertiges XML-Dokument kann durch Abgleich mit einer DTD überprüft werden. Wer ein Dokument erstellt hat, wird diesen Abgleich selber durchführen, es kann zusätzlich ein Abgleich auf dem Server stattfinden und auch dann, wenn das Dokument über das Netz an den Empfänger geliefert wurde.
 

2.2 Elemente

Elemente sind sicherlich die am wenigsten geheimnisvollen Gegenstände der XML-Syntax.
Dies ist ein Beispiel für die Deklaration eines Elementtyps in der DTD:
 
<ELEMENT autor #PCDATA> 
Hier wird der Elementtyp autor deklariert. Das Schlüsselwort #PCDATA gibt an, daß der Inhalt des Elements aus jeder beliebigen Zeichenfolge bestehen kann.
 

Dies ist ein Beispiel für die Verwendung des Elementtyps autor im Dokument:
 
<autor>Joseph Roth</autor> 
 
Das Element setzt sich zusammen aus Start-Tag, Inhalt und End-Tag.

Es gibt die Möglichkeit komplexere Deklarationen für Elemente zu liefern.
 
<!ELEMENT z (#PCDATA|a|ul|b|i|em)*>
Hier wird festgelegt, daß in <z>-Elementen normaler Text und die Elemente a, ul, b, i, em abwechselnd auftreten können. Mit dem Balken ( | )werden 'oder'-Verknüpfungen erstellt.
 
 

2.3 Attribute

Man kennt Attribute von HTML her. Man denke zum Beispiel an das align-Attribut, das in vielen Elementen auftreten kann, so daß Start-Tags wie diese entstehen: <h4 align="center">.

In einer DTD werden zu Elementen Attributlisten gegeben. Dies ist ein Beispiel für die Deklaration einer Attributliste:
 
<!ATTLIST autor  
    raucher (ja|nein) #IMPLIED > 
 
Hier wird für den Elementtyp autor das Attribut raucher deklariert. Es wird festgelegt, daß es für den Wert des Attributs zwei mögliche Werte (ja oder nein) geben soll. Das Schlüsselwort #IMPLIED gibt an, daß das Attribut optional ist. (Wer ein <autor>-Element in ein Dokument setzt, kann das Attribut angeben, kann es aber auch weglassen.)
 
 

2.4 Entities

'Entity' ist der Oberbegriff für eine größere Zahl von verschiedenartigen Gegenständen. Dateien können Entities sein, aber auch Teile von Dateien und sogar einzelne Zeichen können Entities sein.

Wenn in einer DTD Entities deklariert werden, dann gibt es dafür in erster Linie diesen
Grund: Man will Kürzel zur Verfügung stellen, mit denen sich Tipp-Arbeit vermeiden läßt.

Dies ist ein Beispiel für die Deklaration eines Entity:
 
<!ENTITY mwm "Motorenwerke Mannheim" > 
 
Das Entity bekommt den Namen mwm. Als Wert bekommt das Entity die Zeichenfolge "Motorenwerke Mannheim" zugeordnet. 
 
Wenn man ein Dokument auf eine DTD ausrichtet, in der es die obige Deklaration gibt, dann kann man im Dokument das Kürzel &mwm; verwenden, und der Parser wird an die Stelle des Kürzels die Zeichenfolge "Motorenwerke Mannheim" setzen.

Enities werden auch dann deklariert, wenn auf ganze Dateien verwiesen werden soll. Wenn zum Beispiel in ein Dokument eine Sound-Datei eingebunden werden soll, dann wird man die Datei als Entity deklarieren und kann dann über den Entity-Namen auf die Datei verweisen.
 

2.5 Parser und Anwendung

Wenn es um die Verarbeitung von XML-Dokumenten geht, unterscheidet die XML-Spezifikation zwei Instanzen: den Parser und die Anwendung. Der Parser verrichtet seine Arbeit im Dienste einer Anwendung.

Die Aufgaben des Parsers bei der Verarbeitung eines Dokuments:

Die XML-Spezifikation gibt vor, wie sich der Parser beim Umgang mit Dokumenten zu verhalten hat. Es werden jedoch keinerlei Vorgaben für das Verhalten der Anwendung geliefert.

Man unterscheidet zwischen validierenden und nicht-validierenden Parsern. Validierende Parser prüfen auf Gültigkeit. Nicht-validierende Parser prüfen lediglich auf Wohlgeformtheit  (wobei Verstöße gegen die Wohlgeformtheit die schwerwiegenderen Verstöße sind).
 

2.6 Zwei Arten, ein Dokument zu überprüfen

Wenn ein Dokument auf Gültigkeit überprüft wird, bedeutet das, daß ein Abgleich zwischen Dokument und DTD durchgeführt wird.

Die Prüfung auf Gültigkeit kann eine umfangreiche Angelegenheit sein. Es wäre nicht sinnvoll, ein Dokument, das oft über das Netz verschickt wird, immer wieder von neuem zu prüfen. Deswegen wurde das Konzept der Wohlgeformtheit eingeführt.
 
Eine Prüfung auf Wohlgeformtheit bedeutet, daß einfach nur sichergestellt wird, daß ermittelt werden kann, wie das Dokuments aufgebaut ist und daß ein sogenannter Dokument-Baum erstellt werden kann. Ein Abgleich mit einer DTD findet nicht statt - auch dann nicht, wenn in dem Dokument ausdrücklich auf eine DTD verwiesen wird.

Lediglich auf Wohlgeformtheit zu prüfen erfordert den geringeren Zeitaufwand. Wer auf Wohlgeformtheit prüft, setzt voraus, daß der Abgleich mit einer DTD früher schon stattgefunden hat.
 

2.7 Zwei unterschiedliche Arten, ein Dokument zu betrachten

Man unterscheidet zwischen der logischen Struktur eines Dokuments und der physischen Struktur des Dokuments.

Wenn die logische Struktur bestimmt wird, dann schaut man darauf, welche Element es in dem Dokument gibt. Da die Elemente ineinander verschachtelt sind, kann man in einer Baumstruktur den Aufbau des Dokuments darstellen.

XML-Dokumente können sich aus Bestandteilen zusammensetzen, die aus unterschiedlichen Dateien stammen. Und die Unter-Bestandteile können ihrerseits Unter-Bestandteile enthalten. Auch die Abhängigkeit der Bestandteile untereinander läßt sich in einer Baum-Struktur darstellen. Diese Baum-Struktur zeigt dann die physische Struktur des Dokuments.
 

2.8 Erweiterbarkeit

Die Extensible Markup Language (XML) trägt die Erweiterbarkeit im Namen. Und es dürfte wohl auch die am meisten verbreitete Idee zum Thema XML sein, daß XML im Gegensatz zu HTML erweiterbar ist. Sicherlich ist es aber auch sinnvoll zu fragen "Erweiterbar durch wen?" Im Prinzip hat jeder Verfasser von XML-Dokumenten die Möglichkeit, eigene DTDs zu liefern. Durch das Schreiben einer DTD ist jedoch noch nicht viel gewonnen. Es muß auch Anwendungen geben, die Dokumente des entsprechenden Typs verarbeiten können. Da nur wenige die Möglichkeit haben, solche Anwendungen zu liefern und in Browser zu integrieren, dürfte sich unter den Anwendern von XML nur eine kleine Minderheit für Erweiterungen zuständig fühlen.

Es könnte sich sogar herausstellen, daß sich nur die DTDs, die vom W3C abgesegnet werden, im Web als tragfähig erweisen. In dem Fall wären für die Erweiterung dieselben Gremien zuständig, die sich früher um die Erweiterung von HTML gekümmert haben.
 

3. Prolog / interne und externe Untermenge

Der Teil eines XML-Dokuments, der vor dem Start-Tag des ersten Elements erscheint, wird als Prolog bezeichnet. Der Prolog kann leer sein (aus null Zeilen bestehen), sollte aber zumindest eine XML-Deklaration enthalten. Neben der XML-Deklaration kann der Prolog eine Dokumenttyp-Deklaration sowie Kommentare und Processing Instructions enthalten.

Dies ist ein kleines Beispiel-Dokument mit einer XML-Deklaration (Zeile 1) und einer Dokumenttyp-Deklaration (Zeile 2):
 
<?xml version="1.0"?>

<!DOCTYPE brief SYSTEM "brief.dtd">

<brief>Hallo Leute!</brief>
 
Warum gibt es die Regel, daß ein wohlgeformtes Dokument keinen Prolog enthalten muß? Man hat sich auf diese Regelung geeinigt, weil man für die Umstellung von HTML-Dokumenten auf XML keine unnötigen Hürden schaffen wollte. In HTML-Dokumenten gibt es keine XML-Deklaration und meistens auch keine Dokumenttyp-Deklaration.
 

3.1 XML-Deklaration

Die XML-Deklaration ist Bestandteil des Prologs. Wenn sie vorhanden ist, bildet sie die erste Zeile eines Dokuments.

Dies ist ein zweites Beispiel für eine XML-Deklaration:
 
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 
Neben der Versionsangabe kann die Deklaration eine Kodierungs-Deklaration enthalten und eine Standalone-Deklaration.

Standalone-Deklaration

Eine Standalone-Deklaration, die den Wert 'yes' liefert, teilt dem Parser mit, daß es nicht nötig ist, außerhalb des Dokuments nach einer DTD-Untermenge zu suchen. "standalone='yes'" bedeutet weiterhin auch, daß es keine externen Parameter-Entities gibt, die berücksichtigt werden müssen.

Der Wert »no« würde demgegenüber zeigen, daß möglicherweise externe Markup-Deklarationen vorhanden sind. ('Markup-Deklaration' ist der Oberbegriff für alle Deklarationen, die in DTDs vorgenommen werden.)
 

Kodierungs-Deklaration

Eine Kodierungs-Deklaration zeigt an, welche Zeichenkodierung verwendet wird.
 

Nebenbei: Dieselben Angaben, die von einer XML-Deklaration geliefert werden,  können auch an den Anfang von einem sogenannten externen geparsten Entity gesetzt werden. Wenn sie in einem sogenannten externen geparsten Entity erscheinen, spricht man allerdings nicht mehr von einer XML-Deklaration, sondern bezeichnet das Ganze dann als Text-Deklaration.
 

3.2 Dokumenttyp-Deklaration

Eine Dokumenttyp-Deklaration ist Teil des Prologs. Sie gibt an, in welcher Datei sich die externe DTD-Untermenge befindet.

Beispiel:
 
<?xml version="1.0" encoding="UTF-8"?>  
<!DOCTYPE gruss SYSTEM "hello.dtd">  
<gruss> Hallo XML!</gruss> 
Die Dokumenttyp-Deklaration in Zeile 2 gibt an, daß das Dokument auf die DTD hello.dtd ausgerichtet wurde.
 

Interne DTD-Untermenge

Wenn von einer DTD die Rede ist, dann wird damit im allgemeinen eine separate Datei gemeint, die Markup-Deklarationen enthält. Es gibt aber beim Verfassen von Dokumenten zusätzlich die Möglichkeit, Deklarationen zu liefern, die innerhalb des Dokuments erscheinen. Die Gesamtheit von Deklarationen innerhalb des Dokuments wird als interne DTD-Untermenge bezeichnet. Der Parser wird die interne und die externe Untermenge zusammenfassen und als eine Gesamt-DTD behandeln. Allerdings gilt die Regel, daß zuerst die interne Untermenge eingelesen wird. Weiterhin gilt die Regel, daß bei Mehrfach-Deklarationen immer jene gültig sind, die als erste eingelesen wurden. Somit hat der Dokument-Verfasser die Möglichkeit, Deklarationen zu liefern, mit denen die Deklarationen der externen Untermenge überschrieben werden.

Wenn es in einem Dokument eine interne DTD-Untermenge gibt, erscheint sie als Bestandteil der Dokumenttyp-Deklaration:
 
<?XML version="1.0" standalone="no"?>  
<!DOCTYPE chapter SYSTEM "dbook.dtd"  [  
<!ELEMENT ulink (#PCDATA)*>  
 <!ATTLIST ulink  
       xml-link            CDATA   #FIXED   "SIMPLE"  
       xml-attributes      CDATA   #FIXED   "HREF URL"  
       URL                 CDATA   #REQUIRED  
]>  
<chapter> ... </chapter>  
 
In diesem Dokument verweist die Dokumenttyp-Deklaration (beginnend in Zeile 2) auf die DTD dbook.dtd. Das Dokument enthält außerdem in eckigen Klammern ( [ und ] ) als Bestandteil der Dokumenttyp-Deklaration eine internen DTD-Untermenge. Die Untermenge  besteht aus einer Elementtyp-Deklaration und einer Attributlisten-Deklarationen.
 

Nebenbei: Man kann leicht die Begriffe Dokumenttyp-Definition und Dokumenttyp-Deklaration verwechseln. Deswegen noch einmal explizit: Die Dokumenttyp-Definition (DTD) enthält die Regeln für den Dokumenttyp. Die Dokumenttyp-Deklaration dagegen ist meistens einfach eine Zeile im Dokument, die angibt, in welcher Datei sich die Dokumenttyp-Definition befindet.
 

Wurzel-Element / Dokument-Element

In jedem wohlgeformten XML-Dokument muß es ein Element geben, das den Container für alle anderen Elemente bildet. Dieses Element wird als Wurzel-Element oder als Dokument-Element bezeichnet.

Für HTML galt bereits die Regel, daß alle Angaben von einem <HTML>- und einem </HTML>-Tag eingeschlossen sein sollen, so daß die Regel, die von XML vorgegeben wird, von HTML-Dokumenten meistens eingehalten wird. Die HTML-Browser haben diese Regel allerdings tolerant gehandhabt. XML-Parser werden an diesem Punkt im allgemeinen strenger vorgehen. (Generell kann man allerdings davon ausgeen, daß für die alten HTML-Dokumente Sonderregelungen geschaffen werden.)

Es gilt die Regel, daß der Name des Dokument-Elements mit dem Namen, der in der Dokumenttyp-Deklaration erscheint, übereinstimmen muß. In diesem Beispiel erscheint in der Dokumenttyp-Deklaration und im Start-Tag des ersten Tags der Name gruss:
 
<?xml version="1.0" encoding="UTF-8"?>  
<!DOCTYPE gruss SYSTEM "hello.dtd">  
<gruss> Hallo XML!</gruss> 
 
Dies ist ein Hinweis für Fortgeschrittene:
Für die interne Untermenge gibt es gegenüber der externen Untermenge Besonderheiten:

 

4. Elemente

Ein Element setzt sich im allgemeinen zusammen aus einem Start-Tag, einem End-Tag und dem Inhalt des Elements.

Ein Beispiel für einen Start-Tag:
 
<h4 align="center">
 
Ein Beispiel für einen End-Tag:
 
</termdef>
 
 

4.1 Elementtyp-Deklaration

Dies sind Beispiele für Elementtyp-Deklarationen:
 
<!ELEMENT spec (front, body, back?)>

<!ELEMENT div1 (head, (p | list | note)*, div2*)>

<!ELEMENT dictionary-body (%div.mix; | %dict.mix;)*>
 
Eine Elementtyp-Deklaration beginnt mit <!ELEMENT. Es folgt der Name des Elementtyps, und was sich daran anschließt, wird als Inhaltsmodell bezeichnet.

Die Möglichkeiten für die Verschachtelung von Elementen, die in Elementtyp-Deklarationen festgelegt werden, kennt man von HTML her. Für numerierte Listen verwendet man das <OL>-Element, und das <OL>-Element kann <LI>-Elemente enthalten. Der Zusammenhang zwischen dem <OL>-Element und dem <LI>-Element wird in der HTML-DTD über eine Elementtyp-Deklaration geregelt. Die Elementtyp-Deklaration liefert ein Inhaltsmodell, in dem festgelegt ist, daß <OL>-Elemente beliebig viele <LI>-Elemente enthalten können.
 
Dies ist eine Auflistung der Syntax-Zeichen, die in Inhaltsmodellen verwendet werden können.
Das Komma 
( , )
wird verwendet, wenn eine Abfolge der Elemente festgelegt wird.
Der Balken 
( | )
wird als Trennzeichen verwendet, wenn eine Reihe von Alternativen angegeben wird.
Das Fragezeichen 
( ? )
gibt an, daß ein Zeichen nullmal oder einmal auftreten kann.
Der Stern 
( * )
gibt an, daß ein Element (oder eine Abfolge von Elementen, die durch runde Klammern eingeschlossen ist) nullmal oder mehrere Male auftreten kann.
Das Pluszeichen 
( + )
gibt an, daß ein Zeichen einmal oder mehrere Male auftreten kann.
Klammern können verwendet werden, um Einbettungen darzustellen. 
Beispiel: (titel, kapitel,(text|überschrift|kodierung)*) 
 

Die folgenden Beispiele veranschaulichen die Verwendung dieser Syntax-Zeichen. Es handelt sich um Beispiele, die aus dem Themenbereich "DTD für eine Kontaktdatenbank" stammen. (Die Datenbank soll dazu dienen, daß die Vertriebs-Mitarbeiter einer Firma Informationen über Kundenkontakte festhalten können.)

Die einfachste Form einer Elementtyp-Deklaration besteht in einer Auflistung von Elementen:
 
<!ELEMENT kunde (name,telefon,email,firma,kontakt,termin)>
Hier wird das Element kunde deklariert. Für die Abfolge der Unter-Elemente wird eine feste Ordnung vorgegeben.
 
Eine Auflistung von Elementen, bei der als Trennzeichen ein Komma verwendet wird, führt zu einer sehr restriktiven Form von Deklaration. Jedes der Elemente im Inhaltsmodell muß genau einmal im Dokument erscheinen, und es muß genau die Reihenfolge  eingehalten werden, die in der Deklaration vorgegeben wurde.

Auch diese Variante wirkt restriktiv:
 
<!ELEMENT kunde (name|telefon|email|firma|kontakt|termin)>
Eine Deklaration, die in der Praxis nicht viel Sinn machen würde, weil sie zu viel Einschränkung mit sich bringt.
 
Ein Balken ( | ) schafft Oder-Verknüpfungen. (Es handelt sich um das sogenannte "ausschließende Oder".) Nur eines der Elemente des Inhaltsmodells kann als Unter-Element auftreten. Das obige Beispiel wäre daher in der tatsächlichen DTD nicht geeignet.

Ein Stern hinter der Auflistung der Elemente würde bedeuten, daß die Elemente in jeder beliebigen Reihenfolge auftreten können:
 
<!ELEMENT kunde (name|telefon|email|firma|kontakt|termin)*>
Eine Deklaration, die in der Praxis nicht viel Sinn machen würde, weil sie zu wenig Einschränkung mit sich bringt.
 
Wenn der Parser im Dokument ein <kunde>-Element findet, dann wird er einen Abgleich zwischen den Unter-Elementen des Elements und den Angaben im Inhaltsmodell der Elementtyp-Deklaration durchführen.

Wenn der Parser im Inhaltsmodell an einen Stern gerät, bedeutet das für ihn, daß bestimmte Abläufe wiederholt werden können. In bezug auf das obige Beispiel sind dies die Abläufe, die wiederholt werden: Der Parser nimmt ein Unter-Element und schaut, ob es mit einem der Elemente im Inhaltsmodell übereinstimmt. Dann nimmt er das nächste Unter-Element und sucht wieder nach einer Übereinstimmung und so weiter.

In der Deklaration für die Kontaktdatenbank wäre es sinnvoll, die Telefonnummer mit einem Stern zu versehen:
 
<!ELEMENT kunde (name,telefon*,email,firma,kontakt,termin)>
Mit dem Stern wird festgelegt, daß ein <telefon>-Element nullmal oder mehrere Male als Unter-Element eines <kunde>-Elements auftreten kann.
 
Ein telefon-Element mit Stern wird den Gegebenheiten in der Welt gerecht: Es kann passieren, daß ein Vertriebs-Mitarbeiter nur die E-Mail-Adresse des Kunden hat, nicht aber die Telefonnummer. Zugleich ist es aber auch möglich, daß mehrere Telefonnummern des Kunden bekannt sind.

Es kann sinnvoll sein, das firma-Element im Inhaltsmodell mit einem Fragezeichen zu versehen.
 
<!ELEMENT kunde (name,telefon*,email,firma?,kontakt,termin)>
Mit dem Fragezeichen wird festgelegt, daß ein <firma>-Element in einem <kunde>-Element nullmal oder einmal vorkommen kann.
 
Wird ein firma-Element mit Fragezeichen den Gegebenheiten in der Welt gerecht? Das hängt von den Vorstellungen der leute ab, die mit der Datenbank arbeiten werden. Vielleicht will man Verwirrungen vermeiden und beschließt daher, jeden Kundennamen nur mit jeweils einer Firma zu verbinden. Die Möglichkeit, daß zu einem Kundennamen kein Firmenname bekannt ist, wird berücksichtigt.

In den bisher angeführten Inhaltsmodellen gibt es ein <kontakt>-Element. Dieses Element  soll das Datum von dem Tag aufnehmen, an dem es den Kunden-Kontakt gegeben hat. Es kann sinnvoll sein, das Element mit einem Pluszeichen zu versehen.
 
<!ELEMENT kunde (name,telefon*,email,firma?,kontakt+,termin)>
Mit dem Pluszeichen wird festgelegt, daß ein <kontakt>-Element in einem <kunde>-Element  einmal oder mehrere Male vorkommen kann.
 
Man wird ein Kunde-Element nur dann in das Dokument setzen, wenn es einen Kontakt gegeben hat. Zugleich ist es vorstellbar, daß es eine längere Reihe von Kontakten geben wird. Das Pluszeichen in der obigen Deklaration trägt dem Rechnung.
 

In den bisher angeführten Inhaltsmodellen gibt es ein <termin>-Element. Das <termin>-Element soll das Datum von bevorstehenden Kontakten aufnehmen. Wenn vorausgesetzt wird, daß bloße Terminabsprachen keine Kontakte sind, dann könnte sich zuletzt eine Deklaration wie diese ergeben.
 
<!ELEMENT kunde (name,telefon*,email*,firma?,(kontakt|termin)+)> 
 
Hier wird festgelegt, daß ein <kunde>-Element immer genau einen Namen enthalten muß. Die Angabe von Telefonnummer und E-Mail-Adresse ist nicht vorgeschrieben. Es können allerdings mehrere Telefonnummern und E-Mail-Adressen notiert werden. Es soll immer nur ein Firmenname notiert werden (nicht mehrere), und es soll entweder das datum von einem Kontakt aufgezeichnet werden, der bereits stattgefunden hat oder aber das Datum von einem vereinbarten Kontakt.
 
 

4.2 Inhaltsmodelle mit EMPTY und ANY

Bisher ging es um Elemente, die Inhalt haben. Es gibt aber auch die leeren Elemente.
Leere Elemente haben keinen Inhalt.

Dies sind Beispiele für die Verwendung von leeren Elementen im Dokument:
 
<IMG align="left" src="http://www.w3.org/Icons/WWW/w3c_home" />

<br></br>

<br />
 
Hier gibt es eine Abweichung von dem, was man von HTML her kennt. In XML-Dokumenten muß ein leeres Element wie <br> einen End-Tag haben (</br>) oder es muß wie in <br /> einen abschließenden Schrägstrich enthalten.
 
Bei der Deklaration für ein leeres Element wird das Schlüsselwort EMPTY verwendet:
 
<!ELEMENT br EMPTY>
 
Man kann für leere Elemente Attribute deklarieren. Leere Elemente erfüllen häufig ihre Funktion in erster Linie über die Attribute.

Dies ist ein Beispiel für ein Inhaltsmodelle, das durch das Schlüsselwort ANY gebildet wird:
 
<!ELEMENT kunde ANY>
 
Eine Deklaration mit ANY bedeutet, daß jedes Element, das in der DTD deklariert wurde,  als Unterelement auftreten kann (außerdem auch einfacher Text) und daß es keine vorgeschriebene Reihenfolge gibt.
 

4.3 Element-Inhalt und Gemischter Inhalt

Der Inhalt eines Elements - das ist all das, was zwischen dem Start-Tag und dem End-Tag eines Elements erscheint. Es gibt für die Zusammensetzung des Inhalts diese drei Möglichkeiten:
  1. Der Inhalt kann ausschließlich aus Daten bestehen.
  2. Der Inhalt kann ausschließlich aus Elementen bestehen.
  3. Der Inhalt kann sowohl aus Daten als auch aus Elementen bestehen.
Bei Möglichkeit (2) spricht man von Element-Inhalt. Der Begriff 'Element-Inhalt' ist also nicht zu lesen als 'Inhalt eines Elements', sondern als 'Inhalt, der ausschließlich durch Elemente gebildet wird'.
Ein Beispiel für ein Element mit Element-Inhalt ist das <DL>-Element von HTML. Dieses Element kann  nur <DT>- und <DD>-Elemente enthalten. (Die Unter-Elemente <DT> und <DD> können natürlich Text als Inhalt haben, außerhalb der Grenzen dieser Elemente erscheint aber kein Text.)

Beispiele für Inhaltsmodelle, mit denen Element-Inhalt deklariert wird:
 
<!ELEMENT spec (front, body, back?)>

<!ELEMENT div1 (head, (p | list | note)*, div2*)>

<!ELEMENT dictionary-body (%div.mix; | %dict.mix;)*>
 

Bei Möglichkeit 3 (Der Inhalt besteht sowohl aus Daten als auch aus Elementen.) spricht man von Gemischtem Inhalt.

Ein Beispiel für ein Element mit Gemischtem Inhalt ist das <P>-Element von HTML. Dieses Element kann normalen Text enthalten, der mit allen möglichen Arten von anderen Elementen durchmischt sein kann, zum Beispiel A, B, I und IMG - in jeder beliebigen Abfolge.

Dies ist ein Beispiel für die Deklaration eines Elementtyps mit gemischtem Inhalt:
 
<!ELEMENT z (#PCDATA|a|ul|b|i|em)*>
Diese Element-Typ-Deklaration legt fest, daß in z-Elementen normaler Text und die Elemente a, ul, b, i, em abwechselnd auftreten können. 
 
Die Unterscheidung zwischen den drei Arten von Inhalten von Elementen ist wichtig, weil es bei gemischtem Inhalt eine Besonderheit gibt: Für Elemente mit gemischtem Inhalt gilt, daß zwar festgelegt werden kann, welche Elemente als untergeordnete Elemente auftreten können, es kann aber nicht festgelegt werden, in welcher Reihenfolge die Elemente auftreten und wieviele es höchstens sein können.
 
Alle Inhalts-Modelle, die PCDATA mit einschließen, müssen diese Form haben: PCDATA muß an der ersten Stelle stehen, und alle Elemente müssen durch den vertikalen Strich getrennt werden, und die gesamte Gruppe muß optional sein.

Der Regelung, daß bei gemischtem Inhalt nicht bestimmt werden kann, in welcher Ordnung die in den Text eingestreuten Kind-Elemente erscheinen, liegen viele Jahre Erfahrung mit SGML zugrunde. (In SGML kann die Abfolge festgelegt werden, es wird allerdings davon abgeraten, von dieser Möglichkeit Gebrauch zu machen).
 

5. Attribute

Attribute werden verwendet, um Elemente genauer zu spezifizieren. Man kennt Attribute von HTML her, etwa das Align-Attribut, das in vielen Tags auftauchen kann. Beispiel: <H4 align="center">.

Bei der Deklaration von Attributen wird jedes Attribut einem Typ zugeordnet. Man kann sagen, daß es elf Typen von Attributen gibt. Üblicherweise werden aber neun dieser Attributtypen zu einer Gruppe zusammengefaßt, während die anderen beiden alleine je eine Gruppe bilden. Auf diese Weise entstehen drei Gruppen von Attributtypen:

Beispiele für Attributdeklarationen:
 
<!ATTLIST termdef

          id      ID      #REQUIRED

          name    CDATA   #IMPLIED>

<!ATTLIST list

          type    (bullets|ordered|glossary)  "ordered">

<!ATTLIST form

          method  CDATA   #FIXED "POST">
Hier werden zu den Elementen termdef, list und form Attribute definiert. Jedes Attribut wird einem Attribut-Typ zugeordnet (name wird zum Beispiel dem Typ CDATA zugeordnet.) 
 

Zeichenketten-Typ

Mit dem Schlüsselwort CDATA ordnet man ein Attribut dem Zeichenketten-Typ zu.
CDATA ist das Gegenstück zu #PCDATA.

Das Schlüsselwort #PCDATA (für 'parsed character data') wird bei der Deklaration von Elementen angegeben (Beispiele siehe oben). Es zeigt an, daß der Parser innerhalb der Daten nach Markup suchen muß. CDATA dagegen wird bei der Deklaration von Attributen verwendet und zeigt an, daß der Parser in den Daten nicht fündig werden wird. Wenn ein Attribut dem Typ CDATA zugeordnet wird, bedeutet das für den Verfasser eines Dokuments, daß jede beliebige Zeichenfolge als Attributwert auftreten kann.
 
Beispiele für die Deklaration eines Attributs vom Typ CDATA:
 
<!ATTLIST termdef

          name    CDATA   #IMPLIED>
Hier wird für das Element termdef das Attribut name deklariert. Es wird festgelegt, daß das Attribut vom Typ CDATA sein soll. Im Dokument kann somit ein Element wie dieses auftreten: <termdef name="ab%cdef">
 
 

Aufzählungs-Typ

Wenn ein Attribut dem Aufzählungstyp zugeordnet wird, sieht das so aus:
 
<!ATTLIST list

          type    (bullets|ordered|glossary)  "ordered">
Für das Element list wird hier das Attribut type deklariert. Es wird festgelegt, daß 'type' immer einen der drei vorgegebenen Werte annehmen muß. Wenn das Element list ohne das type-Attribut im Dokument erscheint, soll es automatisch den Wert 'ordered' zugewiesen bekommen. 
 
Für den Aufzählungstyp gibt es kein Schlüsselwort. Daß es sich um den Aufzählungstyp handelt, erkennt man daran, daß eine Auflistung von möglichen Werten geliefert wird.

Ein guter XML-Editor sorgt dafür, daß die Vorgaben der DTD eingehalten werden. Das heißt, wenn in das Dokument ein <list>-Element gesetzt wird, dann wird der Editor für den Attributwert die Auswahl zwischen den drei zulässigen Werten anbieten.
 

ID-Attribute

ID-Attribute werden angegeben, damit Elemente identifiziert werden können.
Dies ist ein Beispiel für die Deklaration eines ID-Attributs:
 
<!ATTLIST artikel

          id      ID      #REQUIRED>
Hier wird für das Element artikel ein Attribut deklariert, das den Namen id hat und vom Typ ID ist. Mit #REQUIRED wird festgelegt, daß das id-Attribut immer angegeben werden muß, wenn das <artikel>-Element im Dokument erscheint. 
 
Alle ID-Werte, die in einem Dokument verwendet werden, müssen unterschiedlich sein, so daß über den Wert des ID-Attributs das jeweilige Element identifiziert werden kann. Wenn es in einem Dokument zwei Attribute vom Typ ID gibt, die beide denselben Wert haben, muß der Parser einen Fehler anzeigen.

IDREF-Attribute

Der Wert eines IDREF-Attributs muß auf eine Zeichenfolge verweisen, die irgendwo in dem Dokument als Wert eines ID-Attributs angegeben wurde. Wenn der Wert des Attributs mit keiner ID im Dokument übereinstimmt, muß der Parser einen Fehler anzeigen.

Die ID-Attribute und die IDREF-Attribute bieten zusammen einen kleinen Mechanismus zur Schaffung von Links innerhalb von Dokumenten. Dazu ein Beispiel: Oben wurde zu dem Elementtyp artikel ein ID-Attribut mit dem Namen id deklariert. Wenn es für ein <verpackung>-Element die Möglichkeit geben soll, auf bestimmte <artikel>-Elemente zu verweisen, dann ist eine Deklaration wie diese nötig:
 
<!ATTLIST verpackung

          referenz   IDREF      #REQUIRED>
 
Im Dokument kann es nun diese Elemente geben:
 
<artikel id="1234"> ... </artikel>

.

.

<verpackung referenz="1234"> ... </verpackung> 
 

Damit man von einem Link-Mechanismus sprechen kann, sind allerdings Regelungen nötig, die über die Festlegungen der DTD hinausgehen. Soll heißen: Der Browser muß wissen, was zu tun ist, wenn er an ein Element mit IDREF-Attribut gerät. Es sind Browser vorstellbar, die als Reaktion auf ein IDREF-Attribut eine Schaltfläche anzeigen. Klicken auf die Schaltfläche könnte dann dazu führen, daß das zugehörige <artikel>-Element angezeigt wird.

ID-Attribute sind allerdings auch unabhängig von IDREF-Attributen von Bedeutung, denn sie geben Elementen unverwechselbare Adressen. In der Zukunft werden sie eine wichtige Rolle spielen, da sie die Ziele (targets) für Links bilden, die von außen auf das Dokument verweisen.

Nebenbei: Für IDREF gibt es die Pluralform IDREFS. Während ein IDREF-Attribut sich auf ein einzelnes ID-Attribut eines Elements des Dokuments beziehen muß, kann der Wert eines IDREFS-Attributs auf mehrere IDREF-Werte verweisen. Die Einzel-Werte werden durch Leerstellen voneinander getrennt.
 

ENTITY-Attribute

Der Wert des Attributs muß mit dem Namen eines externen binären Entity übereinstimmen, das in einer DTD deklariert wurde. (Als externe binäre Entities können zum Beispiel Sounddateien auftreten.)

Die Pluralform ENTITIES verhält sich genauso, erlaubt aber, daß  mehrere Entity-Namen angeführt werden, die durch eine Leerstelle voneinander abgetrennt werden.
 

NMTOKEN-Attribute

Der Wert eines NMTOKEN-Attributs ist ähnlich aufgebaut wie der Wert eines CDATA-Attributs. Während allerdings CDATA-Attribute jede beliebige Zeichenfolge als Wert annehmen können, gelten für die Werte von NMTOKEN-Attributen die Beschränkungen, die auch für Namen gelten.

Dies ist ein Beispiel für eine Attribut-Deklaration, bei der das Attribut dem Attributtyp NMTOKEN zugeordnet wird:
 
<!ATTLIST produkt code NMTOKEN> 
 
 

Zu NMTOKEN gibt es die Pluralform NMTOKENS. Während ein NMTOKEN-Attribut nur einen einzelnen Namen als Wert haben kann, kann der Wert eines  NMTOKENS-Attributs mehrere NMTOKEN-Werte umfassen, zwischen denen ein Leerzeichen das Trennzeichen bildet.
 

NOTATION-Attribute

Dies ist ein Beispiel für die Deklaration eines Attributs vom Typ NOTATION:
 
<!ATTLIST bild typ NOTATION>    
 
 
Als Wert eines Attributs vom Typ NOTATION wird der Name einer Notation angesetzt. Wenn es also eine Notation-Deklaration wie diese gibt:
 
<!NOTATION eps SYSTEM "http://www.abc-comp.com/programs/epsview.exe">    
 
 
... dann kann der Name der Notation ('eps')  als Wert des typ-Attributs auftreten:
 
<bild typ="eps"> ... </bild>    
 
 
Wenn mit einem zusätzlichen Attribut angegeben wird,  unter welcher Adresse das Bild zu finden ist, dann wird die Notation-Deklaration die Information darüber bieten, wie mit dem Bild zu verfahren ist. All dies sind aber Angelegenheiten, um die sich der Parser nicht kümmern muß. Der Parser wird einfach die Informationen an die Anwendung weitergeben.
 

5.1 Attribut-Vorgaben

Beim Verfassen von Dokumenten gibt es Attribute, die gesetzt werde müssen, und es gibt andere, für die das nicht gilt. Eine Attribut-Deklaration beantwortet daher die Frage "Muß das Attribut gesetzt werden, wenn das entsprechende Element in ein Dokument gesetzt wird, oder muß es nicht gesetzt werden?  Falls festgelegt wird, daß es nicht vorkommen muß, kann die Deklaration angeben, wie ein XML-Parser sich verhalten soll, wenn das Attribut tasächlich nicht gesetzt wurde.

XML bietet für diese Vorgaben die folgenden Schlüsselwörter:

#REQUIRED
Wann immer das Element im Dokument erscheint, muß das Attribut angegeben werden.
#IMPLIED
Dem Verfasser des Dokuments wird es freigestellt, das Attribut anzugeben.
"wert"
Das Attribut kann weggelassen werden. Bei nicht-gesetztem Attribut wird der angegebene Wert als Attribut-Wert genommen
#FIXED "wert"
Wenn das Schlüsselwort #FIXED gesetzt wurde, bedeutet das, daß das Attribut stets den Vorgabewert haben muß, wenn es gesetzt wird. Den angegebenen Wert bekommt das Attribut allerdings auch, wenn es nicht gesetzt wird.
 

5.2 Normalisierung von Attribut-Werten

Innerhalb von Attribut-Werten können Referenzen auf Entities auftreten. Bevor der Parser den Attributwert an die Anwendung weitergeben kann, müssen die Entity-Referenzen durch ihren Ersetzungstext ersetzt werden.

Die XML-Spezifikation gibt Anweisungen dafür, wie der Ersetzungsprozeß vonstatten gehen soll.
Zum Beispiel wurde festgelegt, daß eine Folge von Leerzeichen, die über eine Entity in den Attributwert gelangt, durch ein einzelnes Leerzeichen ersetzt wird.
 
 

6. Entities

'Entity' ist der Oberbegriff für eine größere Zahl von verschiedenartigen Gegenständen. Dateien können Entities sein, aber auch Teile von Dateien und sogar einzelne Zeichen können Entities sein.

Gemeinsam ist allen Entities, daß es für sie einen Namen gibt und daß sie einen Inhalt haben. Die zugrundeliegende Idee sieht so aus: Es muß möglich sein, im Dokument den Namen des Entity anzuführen und dadurch den Parser dazu zu bringen, daß er den Inhalt des Entity in das Dokument (oder in die DTD) einfügt.

Die meisten Entities müssen in einer Deklaration einen Namen zugewiesen bekommen, bevor auf sie in einem Dokument verwiesen werden kann. Wenn ein Entity deklariert wurde, kann der Entity-Name als ein Kürzel verwendet werden, und der Parser wird dafür sorgen, daß an die Stelle des Entity der Ersetzungstext gesetzt wird.

Für Entities gibt es drei Einteilungskriterien: Man unterscheidet allgemeine Entities und Parameter-Entities. Außerdem teilt man ein in geparste und nicht-geparste Entities. Und zuletzt gibt es noch die Unterscheidung zwischen internen und externen Entities.
 

6.1 Allgemeine Entities versus Parameter-Entities

Der Verfasser eines Dokuments hat die Möglichkeit, Kürzel zu definieren.
Dies ist ein Beispiel für die Deklaration eines Kürzels:
 
<!ENTITY mwm "Motorenwerke Mannheim" > 
 
Wer sein Dokument auf eine DTD ausrichtet, in der diese Deklaration enthalten ist, kann im Dokument das Kürzel &mwm; verwenden. Der Parser wird an die Stelle des Kürzels den Ersetzungstext setzen.

Der wichtigste Unterschied zwischen allgemeinen Entities und Parameter-Entities liegt in der Verwendung der Kürzel: Auf allgemeine Entities wird in Dokumenten verwiesen, auf Parameter-Entities dagegen in DTDs.

Im obigen Beispiel wurde ein allgemeines Entity deklariert. Die Deklaration für das entsprechende  Parameter-Entity würde so aussehen:
 
<!ENTITY % mwm "Motorenwerke Mannheim" > 
 
Der syntaktische Unterschied besteht in dem Prozentzeichen. Ein '%' kennzeichnet eine Entity-Deklaration als Parameter-Entity-Deklaration.

Und auch das Aussehen der Kürzel unterscheidet sich:
Auf das oben deklarierte allgemeine Entity verweist man mit &mwm;
Auf das Parameter-Entity dagegen verweist man mit %mwm;

Es ist fraglich, ob die Zeichenfolge "Motorenwerke Mannheim" in einer DTD wirklich Sinn machen kann. Bei diesem Beispiel ging es darum, die Unterschiede in der Syntax herauszustellen.
Näher dran an der Praxis ist dieses Beispiel:

In der HTML-DTD wird die folgende Auflistung von Elementtyp-Namen häufig als Gruppe angesprochen:
H1 | H2 | H3 | H4 | H5 | H6

Dasselbe gilt für diese Abfolge von Elementtyp-Namen:
UL | OL | DIR | MENU

Da die beiden Abfolgen häufig auftreten, liegt es nahe, für jede der beiden Gruppen von Elementtyp-Namen ein Entity zu deklarieren. Die Deklarationen sehen so aus:
 
<!ENTITY % headings "H1|H2|H3|H4|H5|H6"> 
<!ENTITY % list "UL|OL|DIR|MENU">     
 
Hier werden die Parameter-Enties headings und list deklariert. Headings bekommt den Wert "H1|H2|H3|H4|H5|H6" zugewiesen und list den Wert "UL|OL|DIR|MENU".
 
Nachdem die Parameter-Entities definiert wurden, kann in der DTD mit einem Kürzel auf sie verwiesen werden.
Es muß nicht mehr eine lange Auflistung wie diese gegeben werden:
 
<!ELEMENT BODY (H1|H2|H3|H4|H5|H6|P|UL|OL|DIR|MENU|PRE|HR|IMG)*>
 
Es kann diese verkürzte Schreibung verwendet werden.
 
<!ELEMENT BODY (%headings;|P|%list;|PRE|HR|IMG)*>
Hier wird das Element BODY deklariert. Im Inhaltsmodell werden die Parameter-Entity-Referenzen %headings; und %list; verwendet. 
 
Eine Parameter-Entity-Referenz (das ist die Zeichenfolge, mit der auf ein Parameter-Entity verwiesen wird) beginnt immer mit dem Prozentzeichen (%) und endet mit einem Semikolon (;).

Außerhalb der DTD hat das Prozentzeichen keine besondere Bedeutung. Folglich wird das, was in der DTD eine Parameter-Entity-Referenz wäre, im Inhalt nicht als Markup erkannt.
 

6.2 Geparste versus nicht-geparste Entities

Bei den obigen Beispielen für allgemeine und für Parameter-Enties handelte es sich um geparste Entities. (Der Ausdruck 'geparstes Entity' kann gelesen werden als 'zu parsendes Entity'). Geparste Entities sind im Bereich der Entities der Normalfall. Der Prozessor sorgt beim Aufbereiten eines Dokuments dafür, daß an die Stelle einer  Entity-Referenz der Ersetzungstext tritt, und der Ersetzungstext wird zu einem Bestandteil des Dokuments bzw. der DTD. Der Parser wird im Ersetzungstext nach Markup suchen (er wird das Dokument mitsamt den Ersetzungstexten parsen).

Deklarationen für nicht-geparste Entities haben diese Form:
 
<!ENTITY logo  SYSTEM "/standard/logo.gif"  NDATA  GIF87A>  
 
 
Hier zeigt das Schlüsselwort NDATA, daß es sich um ein Entity handelt, das der Parser nicht analysieren muß.
 
Nicht-geparste (genauer: nicht zu parsende) Entities sind solche, in denen der Parser nicht nach Markup suchen muß (zum Beispiel Sounddateien, die in ein Dokument eingebunden werden). Zu jedem nicht-geparsten Entity gehört eine sogenannte Notation-Deklaration.
 

6.3 Interne versus externe Entities

Als internes Entity wird jedes Entity bezeichnet, dessen Wert in der Entity-Deklaration geliefert wird.

Externe Entities sind demgegenüber solche, deren Inhalt der Parser nur ermitteln kann, indem auf eine zusätzliche Datei zugegriffen wird.

Dies ist ein Beispiel für die Deklaration eines internen Entity:
 
<!ENTITY Pub-Status "Dies ist Version 1.1 dieses Dokuments">
Hier wird das Entity Pub-Status (kurz für: Publikations-Status) deklariert. Das Entity bekommt den Wert "Dies ist Version 1.1 dieses Dokuments" zugeteilt. Der Wert des Entity bildet den Ersetzungstext des Kürzels. Das Kürzel wird so aussehen: &Pub-Status;
 
Wenn es standardisierte Zeichenfolgen gibt, die sich häufig ändern (zum Beispiel die Angabe über den Publikations-Status eines Dokuments), dann ist zu empfehlen, ein Entity zu deklarieren. Nachdem das Entity deklariert wurde, kann man das zugehörige Kürzel beliebig oft in die Dokumente setzen. Es ist sichergestellt, daß der Ersetzungstext für das Kürzel sehr einfach geändert werden kann. Man muß lediglich die Deklaration des Entity ändern.

Bei der Deklaration eines externen Entity wird kein Ersetzungstext angegeben, in der Deklaration  erscheint stattdessen eine URL:
 
<!ENTITY boilerplate    SYSTEM "/standard/legalnotice.xml">  
 
Hier wird das Entity boilerplate deklariert. Wenn anschließend im Dokument das Kürzel &boilerplate; erscheint, wird der Parser das Kürzel durch den Inhalt der Datei legalnotice.xml ersetzen. 
 
Alle internen Entities sind geparste Entities. Das heißt,  daß der Ersetzungstext zu einem Teil des Dokuments bzw. der DTD wird.
 
Zu den internen Entities zählen auch die fünf vordefinierten Entities:

Während alle internen Entities geparste Entities sind, muß man bei den externen Entities die beiden Untergruppen der geparsten und der nicht-geparsten externen Entities unterscheiden.
Der Unterschied ist einfach zu erklären: Es geht darum, daß es einerseits Dateien gibt, mit denen der Parser was anfangen kann und andererseits Dateien, für die das nicht gilt. Das heißt, daß der Parser in der einen Sorte von Dateien Markup finden kann, in den Dateien der anderen Sorte (zum Beispiel Soundateien) dagegen nicht.

Die beiden Arten von Dateien werden auf unterschiedliche Weise in die Dokumente eingebunden.  Das Einbinden läuft bei den geparsten Entities (den Dateien, mit denen der Parser etwas anfangen kann) einfach. Komplizierter wird es bei den nicht-geparsten Entities (den Dateien, mit denen der Parser nichts anfangen kann).
 
Hier noch einmal das Beispiel für die Deklaration eines externen Entity, das oben angeführt wurde. (Es handelt sich um ein Beispiel für ein geparstes externes Entity):
 
<!ENTITY boilerplate SYSTEM "/standard/legalnotice.xml">
Das Entity boilerplate wird deklariert. Wenn später das Kürzel &boilerplate; in ein Dokument gesetzt wird, führt das dazu, daß der Parser das Kürzel durch den Inhalt der Datei legalnotice.xml ersetzt. 
 
Die Deklaration eines nicht-geparsten externen Entity folgt einer anderen Syntax.
 
<!ENTITY BMWlogo  SYSTEM "http://www.abc-comp/logo.gif"  NDATA  GIF87A>  
 
Hier wird das externe nicht-geparstes Entity BMWlogo deklariert. Das Schlüsselwort NDATA gibt für den Parser den Hinweis, daß in der Datei nicht nach Markup gesucht werden muß.
 
Die Syntax, die XML  für das Einbinden von Bilddateien (und anderen Dateien mit binären Daten)  mitbringt, sieht anders aus als in HTML. Wie die obige Deklaration zeigt, werden für Dateien mit binären Daten Entities deklariert. Es wird das Schlüsselwort NDATA verwendet, gefolgt von dem Namen einer sogenannten Notation-Deklaration (im Beispiel: GIF87A). Der Parser muß die Notation-Deklaration für GIF87A aufrufen und findet dort Hinweise darauf, wie mit dem Bild zu verfahren ist.

In HTML läßt sich das Einbinden von HTML-Dateien einfacher bewerkstelligen:
 
<img src="http://www.abc-comp/logo.gif"> 
 
 
Man kann erwarten, daß die einfache Variante für das Einbinden von Bilddateien auch in den zukünftigen Versionen von HTML erhalten bleibt.
 

Hier noch einige zusätzliche Hinweise zu internen Entities:

Interne Entities können Referenzen auf andere interne Entities enthalten, man kann sie allerdings nicht rekursiv verwenden. (Ein Entity kann nicht sich selbst aufrufen, und ein Entity darf auch dann nicht aufgerufen werden, wenn in der Deklaration für das Entity das aufrufende Entity verwendet wurde.)

Beispiel für die Verwendung einer Entity-Referenz innerhalb einer Entity-Deklaration:
 
<!ENTITY AC "Das %W3C; Advisory Council"> 
<!ENTITY % W3C "WWW Consortium"> 
 
Hier werden die Entities AC und W3C deklariert. Die Deklaration für AC verwendet die Entity-Referenz &W3C; Wenn im Dokument das Kürzel &AC; verwendet wird, wird der Parser das Kürzel durch die Zeichenfolge  "Das WWW Consortium Advisory Council" ersetzt.
 
Und noch ein Hinweis: Start-Tags, End-Tags, Leeres-Element-Tags, Elemente, Kommentare, Processing Instructions, Zeichen- oder Entityreferenzen können nicht in einem Entity beginnen und in einem anderen enden.
 

6.4 Entities im Überblick

Dies sind die Begriffe, die in den Einteilungskriterien für Entities auftauchen:
Allgemeine Entities
sind solche Entities, die deklariert werden, damit in Dokumenten auf sie verwiesen wird.
Parameter-Entities
sind solche Entities, die deklariert werden, damit in DTDs auf sie verwiesen wird.
Interne Entities
sind alle Entities, deren Ersetzungstext bei der Deklaration geliefert wird.
Externe Entities
sind Entities, bei deren Deklaration kein Ersetzungstext geliefert wird; statt einem Ersetzungstext wird eine URL geliefert.
Geparste Entities (zu parsende Entities)
sind solche, in denen der Parser nach Markup suchen wird.
Nicht-geparste Entities (nicht zu parsende Entities)
sind solche, die vom Parser nicht analysiert werden.
Da es die drei Einteilungskriterien gibt (allgemeine versus Parameter-, interne versus externe, geparste versus nicht-geparste Entities) gibt es theoretisch acht verschiedene Arten von Entities.
Tatsächlich gibt es jedoch diese fünf Arten von Entities:
1. Interne geparste allgemeine
Der Ersetzungstext wird in der Deklaration geliefert. Das zugehörige Kürzel wird in Dokumente gesetzt.
2. Interne geparste Parameter
Der Ersetzungstext wird in der Deklaration geliefert. Das zugehörige Kürzel wird in DTDs gesetzt.
3. Externe geparste allgemeine
Der Inhalt des Entity befindet sich in einer anderen Datei. Das zugehörige Kürzel wird in Dokumente gesetzt.
4. Externe geparste Parameter
Der Inhalt des Entity befindet sich in einer anderen Datei. Das zugehörige Kürzel wird in DTDs gesetzt.
5. Externe nicht-geparste allgemeine
Der Inhalt des Entity befindet sich in einer anderen Datei. Der Parser wird in der Datei nicht nach Markup suchen. Das zugehörige Kürzel wird in Dokumente gesetzt.
Entities der Art (4) schaffen Freiheit bei der Erstellung von DTDs. Es ist jederzeit möglich, eine beliebige DTD als Entity zu deklarieren und dann per Entity-Referenz in die eigene DTD einzubeziehen. Das folgende Beispiel verdeutlicht dieses Verfahren:
 
<?xml version="1.0"?> 
<!DOCTYPE person  [ 
<!ELEMENT person (name,adresse)> 
<!ELEMENT name (#PCDATA)> 

<!ENTITY % adresse SYSTEM "http://www.abc-comp.de/adresse.dtd"> 
%adresse; 

]> 
<person> 
<name>Kuno Dünhölter</name> 
<adresse>Mannheim, Deutschland</adresse> 
</person> 
 

Hier wird innerhalb einer internen Untermenge ein Entity deklariert, dessen Inhalt durch eine Datei namens adresse.dtd gebildet wird. Direkt hinter der Entity-Deklaration erscheint eine Referenz auf das Entity. Durch die Referenz wird der Inhalt von adresse.dtd zu einem Bestandteil der internen DTD-Untermenge. 

Innerhalb der internen Untermenge werden außerdem die Elemente person und name deklariert. Bei der Deklaration von person wird das Element adresse angeführt. Da die Deklaration für adresse sich zunächst nicht in der internen Untermenge befindet, kann man erwarten, daß sie sich in adresse.dtd befinden. Die Datei adresse.dtd sollte daher mindestens diese Angabe enthalten:

<!ELEMENT adresse  (#PCDATA)> 
 
 
 

6.5 Fünf Arten von Entities (Beispiele für die Deklaration)

1. Deklaration eines internen allgemeinen Entity:
 
<!ENTITY mwm "Motorenwerke Mannheim" >  
 
 
2. Deklaration eines internen Parameter-Entity:
 
<!ENTITY % mwm "Motorenwerke Mannheim" > 
 
 
3. Deklaration eines externen allgemeinen Entity:
 
<!ENTITY kap1  SYSTEM "http://www.abc-comp.de/kap1.xml">  
 
 
4. Deklaration eines externen Parameter-Entity:
 
<!ENTITY % adresse SYSTEM "http://www.abc-comp.de/adresse.dtd"> 
 
 
5. Deklaration eines nicht-geparsten Entity:
 
<!ENTITY BMWlogo  SYSTEM "/standard/logo.gif"  NDATA  GIF87A>  
 
 
 

6.6 Entity-Referenzen

Als Entity-Referenz bezeichnet man die Zeichenfolge, mit der auf ein Entity verwiesen wird.

Wenn ein Entity im Dokument verwendet werden soll, muß man es einfach nur mit seinem Namen ansprechen. Parameter-Entity-Referenzen beginnen mit dem Prozentzeichen (%) und enden mit einem Semikolon (;).  Entity-Referenzen beginnen mit dem 'Kaufmanns-Und' (&) und enden ebenfalls mit einem Semikolon.
 

Referenzen auf nicht-geparste Entities

Für Referenzen auf nicht-geparste Entities gilt eine Besonderheit: Das zugehörige Kürzel kann nicht frei in den Text gesetzt werden, sondern muß als Wert eines Attributs erscheinen. Das Attribut muß vom Typ ENTITY sein.
 
Dies ist ein Beispiel  für die Deklaration eines Attributs vom Typ ENTITY:
 
<!ATTLIST brief logo ENTITY >  
 
Hier wird für das Element brief das Attribut logo deklariert. Es wird festgelegt, daß ein Wert des Attributs immer aus dem Namen eines Entity bestehen muß.
 
 Wir setzen voraus, daß es weiterhin diese Entity-Deklaration gibt:
 
<!ENTITY Xlogo  SYSTEM "/standard/logo.gif"  NDATA  GIF87A>  
 
 
Jetzt kann in einem <brief>-Element ein logo-Attribut auf das Xlogo-Entity verweisen:
 
<brief logo='Xlogo'>  
 
 
In HTML ist es einfacher, auf Bilddateien zu verweisen:
<img src="/standard/logo.gif> .
Man kann darauf rechnen, daß die einfachere Möglichkeit in zukünftigen Versionen von HTML erhalten bleibt.
 

7. Notation-Deklarationen

Notation-Deklarationen werden benötigt, damit auf konsistente Weise auf externe Informationen zugegriffen werden kann. In den meisten Fällen werden Notation-Deklarationen eingesetzt, um Anwendungen zu identifizieren, an die nicht-geparste Entities übergeben werden können.

Dies ist ein Beispiel für eine Notation-Deklaration:
 
<!NOTATION eps SYSTEM "http://www.abc-comp.com/programs/epsview.exe">    
 
Hier wird per Deklaration der Name eps mit der Anwendung epsview verbunden. Es wird eine Adresse angegeben, unter der die Anwendung im Netz zu finden ist.
 
Nachdem in einer Notation-Deklaration ein Name mit einer Anwendung verbunden wurde, kann ein Attribut vom Typ NOTATION deklariert werden. Das kann so aussehen:
 
<!ATTLIST bild typ NOTATION>    
 
 
Nachdem festgelegt wurde, daß das Element bild ein Attribut vom Typ NOTATION haben kann, kann im Dokument eine Angabe wie diese erscheinen:
 
<bild typ="eps"> ... </bild>    
 
 
Der Parser wird von dem Attributwert eps zu der EXE-Datei gelangen. Er wird die EXE-Datei nicht überprüfen, sondern wird lediglich die URL als eine Information an die Anwendung weiterreichen.

Nebenbei: Wenn es einen Start-Tag wie  <bild typ="eps"> gibt, dann läßt sich damit nicht ermitteln, wo das Bild zu finden ist. Man kann aber ein zusätzliches Attribut deklarieren (etwa ein Attribut 'source', das dem Attributtyp CDATA zugeteilt wird) und kann diesem Atribut die Adresse als Wert zuteilen.

Die Namen von Notationen werden in unterschiedlichen Zusammenhängen verwendet:

- in Entity-Deklarationen
- in Attributlisten-Deklarationen
- in Processing Instructions
- Verwendung als Attributwerte
 

8. Gültigkeit und Wohlgeformtheit / validierende und nicht-validierende Parser

Wenn es um die Verarbeitung von XML-Dokumenten geht, unterscheidet die XML-Spezifikation zwei Instanzen: den Parser und die Anwendung. Der Parser verrichtet seine Arbeit üblicherweise im Dienste einer Anwendung - in den meisten Fällen wird das ein Browser sein.

Die sind die Aufgaben des Parsers bei der Verarbeitung eines Dokuments:

Die XML-Spezifikation gibt vor, wie sich der Prozessor beim Umgang mit Dokumenten zu verhalten hat. Es werden jedoch keinerlei Vorgaben für das Verhalten der Anwendung geliefert.
 

8.1 Gültigkeit

Wenn ein Dokument auf Gültigkeit überprüft wird, bedeutet das, daß ein Abgleich zwischen Dokument und DTD durchgeführt wird.

Die Prüfung auf Gültigkeit kann eine umfangreiche Angelegenheit sein. Es wäre nicht sinnvoll, ein Dokument, das oft über das Netz verschickt wird, wieder und wieder zu prüfen. Deswegen wurde das Konzept der Wohlgeformtheit eingeführt.
 

8.2 Wohlgeformtheit

Eine Prüfung auf Wohlgeformtheit bedeutet, daß einfach nur sichergestellt wird, daß der Dokument-Baum erstellt werden kann. Ein Abgleich mit einer DTD findet nicht statt - auch dann nicht, wenn in der Dokumenttyp-Deklaration ausdrücklich auf eine DTD verwiesen wird.

Lediglich auf Wohlgeformtheit zu prüfen erfordert den geringeren Zeitaufwand. Wer auf Wohlgeformtheit prüft, setzt voraus, daß der Abgleich mit einer DTD früher schon stattgefunden hat.

Wenn HTML-Dokumente an XML angepaßt werden sollen, sind vor allem diese Regeln wichtig:

(1) Alle Attribut-Werte müssen in Anführungszeichen stehen.

(2) Leere Elemente (das sind Elemente wie <IMG>, <HR>, und <BR>, also solche, die keinen Inhalt und daher auch kein End-Tag haben) müssen entweder mit '/>' enden, oder man muß einen regulären End-Tag hinzufügen.
 
    Beispiel: Das aus HTML bekannte <BR> wird entweder zu <BR /> oder zu <BR></BR>.
 
(3) Elemente müssen sauber ineinander eingebettet werden (keine überlappenden Auszeichnungen).

Dies ist ein Beispiel für ein sehr einfaches wohlgeformtes Dokument:
 
<gruss>Hallo Welt!</gruss>
 
Verstöße gegen Wohlgeformtheitsbeschränkungen sind gegenüber Verstößen gegen Gültigkeitsbeschränkungen die ernsteren Verstöße. Ein Parser, der an einenVerstoß der ersten Art gerät, wird einen 'fatal error' feststellen und wird die Aufbereitung des Dokuments abbrechen.
 

8.3 Validierende und nicht-validierende Parser

Ein validierender Parser prüft auf Gültigkeit, und ein nicht-validierender Parser prüft auf Wohlgeformtheit. Das Prüfen auf Gültigkeit schließt das Prüfen auf Wohlgeformtheit mit ein.

Ein validierender Parser muß die gesamte DTD und alle externen geparsten Entities, die im Dokument referenziert werden, einlesen und verarbeiten.

Nicht-validierende Parser müssen lediglich das Dokument-Entity, einschließlich der gesamten internen DTD-Untermenge, auf Wohlgeformtheit prüfen. (Das Dokument-Entity, das ist das Start-Dokument, also das Dokument, mit dessen Verarbeitung der Parser seine Arbeit beginnt.)

Ein nicht-validierender Parser liest und verarbeitet alle Deklarationen, die er in der internen DTD-Untermenge findet, ebenso alle Parameter-Entities. Diese Verarbeitung endet, sobald er an ein Parameter-Entity gerät, das nach "draußen" verweist.
 

Die XML-Spezifikation sagt nichts darüber, wann welche Art der Prüfung stattfinden muß. Es ist somit Sache der Softwarehäuser, zu bestimmen, welche Parser verwendet werden sollen und welche Art der Prüfung in welchen Situationen stattfinden sollen. Das Wahrscheinlichste dürfte sein, daß durchgängig validierende Parser eingesetzt werden und daß man den Parsern die Fähigkeit gibt, zwischen den beiden Arten der Prüfung zu wechseln.
 

9. Groß- und Kleinschreibung

Die XML-Spezifikation legt fest, daß der Parser den Unterschied zwischen großen und kleinen Buchstaben beachten muß.

Als Konsequenz daraus ergibt sich, daß es keine Flexibilität bei der Schreibung der Schlüsselwörter gibt. Sie müssen immer in Großbuchstaben erscheinen. Man muß also <!DOCTYPE und <!ELEMENT und <!ATTLIST und <!NOTATION schreiben. Dasselbe gilt für Schlüsselwörter wie SYSTEM und PUBLIC, und für die Schlüsselwörter, die in Attribut-Deklarationen auftreten (ID, CDATA, NMTOKEN und andere) .
 
 

10. Namen

Namen gibt es in XML für Elementtypen, Attribute, Entities (und andere). Für die Bildung von Namen gelten in allen Fällen dieselben Regeln:
 
Ein Name muß mit einem Buchstaben beginnen (a-z, A-Z) oder mit einem Unterstrich (_). Danach können Buchstaben, die Zahlen 0-9, das Komma (,), der Punkt (.), der Unterstrich (_) oder der Bindestrich (-) folgen. Leerraum ist nicht zulässig, ebenso wenig wie anderer Markup.

Der Doppelpunkt (:) wird für experimentelle Zwecke reserviert. Man darf den Doppelpunkt verwenden, sollte das aber nicht tun, da er später möglicherweise noch eine spezielle Bedeutung zugeteilt bekommen wird.

XML beachtet Groß- und Kleinschreibung. Die Namen <Ein_Tag> <ein_Tag> und <EIN_TAG> wird der Parser daher klar unterscheiden.

Namen können nicht-lateinische (zum Beispiel hebräische oder koreanische) Zeichen enthalten.
Aber sie können nicht mit den drei Buchstaben "X", "M" und "L" beginnen.

Dies sind Beispiele für zulässige Namen:
     Tim
     société
     w3-c:Parsed_Entity

Die folgenden Namen sind nicht zulässig:
     xmlu
     2pac
     P=NP
 
 

11. Kommentare

Kommentare haben in XML-Dokumenten die Form, die von HTML her bekannt ist:
 
<!--Dies ist ein Kommentar.-->
 
Ein Kommentar darf innerhalb des Dokuments an beliebiger Stelle außerhalb des übrigen Markup stehen.

Kommentare sind kein Bestandteil der Zeichendaten eines Dokumentes und werden daher in der Regel nicht an die Anwendung weitergegeben. Ein Parser kann aber der Anwendung eine Möglichkeit einräumen, den Text eines Kommentares zu lesen, die XML-Spezifikation schreibt dazu nichts vor.

Aus Gründen der Kompatibilität mit SGML darf die Zeichenfolge »--« (zwei Trennstriche) in einem Kommentar nicht erscheinen.
 

12. CDATA-Abschnitte / Vordefinierte Entities

CDATA-Abschnitte sind Teile von XML-Dokumenten, die nicht geparst werden. Wenn in einem CDATA-Abschnitt also Markup erscheint, wird es vom Parser nicht berücksichtigt.

Beispiel:
 
<![CDATA[<gruss>Hallo Welt!</gruss>]]>
Die Zeichenfolgen <gruss> und </gruss> erscheinen hier in einem CDATA-Abschnitt. Der Parser wird sie daher nicht als Markup ansehen. 
 
CDATA-Abschnitte bedeuten nichts. Sie bieten einfach eine Möglichkeit, wie sich die Autoren von XML-Dokumenten das Leben vereinfachen können.

Den Effekt, den man im obigen Beispiel durch einen CDATA-Abschnitt erreicht, kann man auch erreichen, indem man die Sonderzeichen ersetzt. Das sieht dann im Quelltext des XML-Dokuments so aus:

&lt;tag>Hello, world!&lt;/tag>

Die CDATA-Technik zu verwenden wird in den meisten Fällen für den Web-Autor die bequemere Möglichkeit sein, denn es lassen sich XML-Daten aus anderen Dokumenten herausnehmen und können direkt in den CDATA-Abschnitt übernommen werden - ohne daß jedes Sonderzeichen (<,& usw.) durch ein anderes Zeichen ersetzt werden muß.
 

Vordefinierte Entities

Die öffnende spitze Klammer (<) dient als Erkennungszeichen für den Beginn eines Tags, und das Kaufmanns-Und (&) als Erkennungszeichen für eine Entity-Referenz. Wenn diese beiden Zeichen abseits von ihrer Funktion als Erkennungszeichen verwendet werden sollen, müssen sie besonders geschützt werden. XML hält daher für einige Zeichen-Entities bereit. Dies sind die zugehörigen Zeichen-Entity-Referenzen:

&lt;       steht für die linke spitze Klammer hervor (<).
&gt;      steht für die rechte spitze Klammer (>).
&amp;  steht für das Kaufmanns-Und (&).
&apos; steht für das Hochkomma ( ' ).
&quot;  steht für ein Anführungszeichen ( " ).
 

13. Processing Instructions

Wenn von einem Dokument her Informationen an eine Anwendung gegeben werden sollen, werden dazu Processing Instructions (PIs, deutsch: Verarbeitungs-Anweisungen) verwendet. Beispielsweise kann ein Dokument die Aufforderung enthalten, einen Midi-Player zu starten und eine bestimmte Hintergrundmusik zu spielen. Für diesen Zweck würde man eine PI in den Text setzen.

Die allgemeine Form von PIs sieht so aus:
<?name vadaten?>

Als Name kann der Name einer Anwendung erscheinen. Alle Daten, die auf den Namen folgen, sind optional. Es handelt sich um Daten, um die sich der Parser nicht kümmert. Sie werden einfach an die Anwendung weitergereicht.

Ebenso wie für Kommentare gilt auch für Processing Instructions, daß sie nicht Teil des Inhalts des XML-Dokuments sind. Während aber Kommentare im allgemeinen nicht an die Anwendung weitergegeben werden, wird eine PI in jedem Fall weitergegeben.

Als Namen, die in die PIs gesetzt werden, können Namen verwendet werden, die in Notation-Deklarationen festgelegt wurden.
 

14. Bedingte Abschnitte

Wenn Sie ein Dokument auf eine externe DTD ausrichten, können Sie festlegen, daß bestimmte Abschnitte der DTD eingelesen werden, andere dagegen nicht.

Voraussetzung ist allerdings, daß der Verfasser der DTD entsprechende Vorkehrungen getroffen hat. Konkret: Der Verfasser der DTD muß in die DTD sogenannte bedingte Abschnitte gesetzt haben.

XML stellt für bedingte Abschnitte die Schlüsselwörter INCLUDE und IGNORE zur Verfügung.
Wenn ein Abschnitt mit INCLUDE eingeleitet wird, bedeutet das, daß der Abschnitt berücksichtigt werden soll, wenn der Abschnitt mit IGNORE eingeleitet wird, bedeutet das, daß er übergangen werden soll.
 
<![INCLUDE[ 
  <!ELEMENT buch (titel, rumpf, anhaenge?)> 
]]> 
 
Die Deklaration für den Elementtyp buch befindet sich hier in einem bedingten Abschnitt, der mit INCLUDE eingeleitet wird und wird deswegen beim Einlesen der DTD berücksichtigt.
 
An die Stelle des Schlüsselworts können Parameter-Entities treten.
Das folgende Beispiel zeigt die Deklaration von zwei Parameter-Entities. In den nachfolgenden Zeilen erscheinen zwei bedingte Abschnitte, in denen jeweils das Schlüsselwort durch eine Paramter-Entity-Referenz ersetzt wurde:
 
<!ENTITY % entwurf 'INCLUDE' >

<!ENTITY % fertig  'IGNORE' >
<![%entwurf;[

<!ELEMENT buch (kommentare*, titel, rumpf, anhaenge?)>

]]>

<![%fertig;[

<!ELEMENT buch (titel, rumpf, anhaenge?)>

]]>
 
Der Verfasser des Dokuments kann nun in einer internen DTD-Untermenge die beiden Parameter-Entities so deklarieren, daß die Werte vertauscht werden: %entwurf; bekommt den Wert IGNORE, und %fertig; bekommt den Wert INCLUDE. (Die Deklaration in der internen Untermenge wird die Deklaration in der externen Untermenge überschreiben.)
 

15. System Identifier und Public Identifier

Es gibt drei Arten von Deklarationen, in denen Web-Adressen angegeben werden: Für die Angabe von Adressen gibt es zwei Möglichkeiten: Man kann einen System Identifier oder einen Public Identifier verwenden. Daneben gibt es auch die Möglichkeit, eine Kombination aus beiden zu liefern.

Manche DTDs sind standadisiert worden und sind in der standardisierten Form für die Öffentlichkeit zugreifbar (Beispiele sind die HTML-DTDs). Andere DTDs dagegen haben nur eine lokal begrenzte Bedeutung (DTDs, die nur für eine Web-Site benötigt werden oder nur von bestimmten Institutionen genutzt werden).

Für den ersten Typus von DTDs kann man Public Identifier verwenden.

Public Identifier haben auch schon im Zusammenhang mit HTML eine Rolle gespielt. Man hatte die Möglichkeit, an den Anfang von jedem Dokument eine Deklaration wie diese zu setzen.
 
<!DOCTYPE html PUBLIC "-//IETF//DTD HTML 3.2//EN"> 
 
 
Bedeutung der einzelnen Angaben in der Deklaration: Das Minus-Zeichen (-) gibt an, daß es sich nicht um einen Standard der International Standards Organization (ISO) handelt. 'IETF' gibt den Besitzer der DTD an. Danach folgt die Angabe, um was für eine Art von Dokument es sich handelt (eine DTD). Dann folgt der Name des Dokuments (HTML 3.2). Zuletzt folgt noch eine Angabe über die Sprache, die verwendet wurde ('EN' für 'English').

Public Identifier können nur verwendet werden, wenn es Kataloge gibt, mit denen sich zum Public Identifier eine konkrete Adresse ermitteln läßt.

Für XML gibt es solche Kataloge bisher nicht. Public Identifier haben daher bisher einfach den Status einer guten Idee, die allgemein gutgeheißen wird, aber bisher nicht umgesetzt wurde.

Die Vorteile von Public Identifiern liegen auf der Hand: Wenn es eine DTD bereits auf einem PC (oder in einem Intranet) gibt, dann muß es einen Katalog geben, der auf diese Kopie der DTD verweist, und es wird nicht mehr nötig sein, die DTD immer wieder von neuem aus dem Netz zu holen.

Man kann in XML-Dokumenten Public Identifier verwenden. Bisher ist es jedoch in jedem Fall nötig, daß zusätzlich ein System Identifier angegeben wird, der eine konkrete Adresse nennt. Anders gesagt: Es spricht nichts dagegen, wenn beim Datenaustausch innerhalb einer Firma Public Identifier verwendet werden. Wenn die Dokumente jedoch im Internet angeboten werden, dann muß eine Adresse angegeben werden, die für jeden Internet-Nutzer zugänglich ist, und diese Adresse wird mit einem System Identifier geliefert.

Wenn eine Kombination aus Public Identifier und System Identifier geliefert wird, erscheint der Public Identifier an der ersten Stelle. Die folgende Dokumenttyp-Deklaration könnte am Anfang eines HTML-Dokuments erscheinen:
 
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"  
"http://www.w3.org/TR/REC-html40/loose.dtd" >  
 
 
Es können in System Identifiern relative Adressen angegeben werden wie in diesem Beispiel:
 
<!ENTITY kap1  SYSTEM "buch/kap1.xml">  
 
 
Wenn in einem Sytem Identifier eine relative Adresse angegeben wird, dann bezieht sie sich auf die Adresse der Datei, in der die Entity-Deklaration steht.

Angenommen, die obige Deklaration befindet sich in einer Datei, für die diese URL gilt:
http://www.abc-comp.de/text.dtd ,
dann wird für die Datei kap1.xml diese Adresse gelten:
http://www.abc-comp.de/buch/kap1.xml .
 

16. Identifikation der Sprache

Das Standard-Attribut xml:lang kann verwendet werden, um anzugeben, welche Sprache für den Inhalt und die Atributwerte verwendet wurde.

In gültigen Dokumenten muß dieses Attribut, wie jedes andere, deklariert werden. Die Werte dieses Attributs sind Sprachencodes gemäß Definition in der Spezifikation [IETF RFC 1766]:

Ein Beispiel für die Deklaration:
 
<!ATTLIST gedicht xml:lang NMTOKEN 'en'>
Hier wird festgelegt, daß das Attribut xml:lang im Zusammenhang mit dem Element gedicht den Vorgabewert 'en' haben soll.
 
Der Vorgabwert kann im Dokument überschrieben werden:
 
<gedicht xml:lang='en'> 
<titel>Indian Serenade</titel> 
<p>I arise from dreams of thee  
In the first sweet sleep of night, 
When the winds are breathing low, 
And the stars are shining bright.</p>
 
Es können auch Subcodes angegeben werden. Beispielsweise kann der Code für Deutsch unterteilt werden in de-DE und in de-CH (für die Sprache der Deutschen und die Sprache der deutschsprachigen Schweizer).

Wenn das Attribut deklariert wurde und dann im Dokument verwendet wird, gilt es auch für alle eingebetteten Elemente. Es ist allerdings möglich, für eingebette Elemente das Attribut erneut zu setzen und die ursprüngliche Angabe dadurch zu überschreiben.
 

17. Behandlung von Leerraum

Unter dem Oberbegriff Leerraum werden Leerzeichen, Tabulator-Zeichen, Zeilenende-Markierungen und Leerzeilen zusammengefaßt.

Es gilt die Regel, daß Leerraum bewahrt werden muß. Auch wenn es sich um Leerraum handelt, der lediglich in den Quellcode des XML-Dokuments eingefügt wurde, damit ein menschlicher Betrachter sich besser darin orientieren kann, wird dieser Leerraum an die Anwendung weitergegeben.

Es gibt ein Standard-Attribut, mit dem besonders darauf hingewiesen werden kann, daß der Leerraum erhalten bleiben soll. Wenn dieses Attribut in einer Deklaration einem Element  zugeordnet wird, sieht das so aus:
 
<!ATTLIST gedicht xml:space (default|preserve) 'preserve'>
 
Wenn das Attribut deklariert wurde, kann es im Dokument in den Start-Tag von Elementen des betreffenden Elementtyps gesetzt werden:
 
<gedicht xml:space="preserve">
 
Da allerdings ohnehin die Regel gilt, daß Leerraum erhalten bleibt, kann der Wert von xml:space allenfalls für die Anwendung eine Information darstellen.

18. Zeichenkodierung / Unicode

Eine Kodierungs-Deklaration zeigt an, welche Zeichenkodierung verwendet wird.
Dies ist ein Beispiel für eine XML-Deklaration, die eine Kodierungsdeklaration enthält:
 
<?xml version="1.0" encoding='EUC-JP'?>
Hier wird innerhalb einer XML-Deklaration eine Versions-Deklaration und eine Kodierungs-Deklaration gegeben.
 
Die XML-Deklaration erscheint am Anfang von einem XML-Dokument. Dieselbe Abfolge von Angaben kann auch an den Anfang von einem externen geparsten Entity gesetzt werden. Man nennt das Gebilde dann nicht mehr XML-Deklaration, sondern Text-Deklaration.
 
 
 

18.1 Zeichenkodierung in Entities: die Text-Deklaration

Was für XML-Dokumente die XML-Deklaration ist, das ist für externe geparste Entities die Text-Deklaration. Der Aufbau der Deklarationen ist in beiden Fällen gleich.

Dies ist ein Beispiel für eine Text-Deklaration. (Die Zeile kann in dieser Form den Anfang von einem externen geparsten Entity bilden.)
 
<?xml version="1.0" encoding="UTF-8"?>
Diese Text-Deklaration enthält eine Versions-Deklaration und eine Kodierungs-Deklaration.
 
Warum sieht die XML-Spezifikation diese Text-Deklarationen vor? Es gibt sie, weil sie die Möglichkeit bieten, externe Entities mit einer Kodierungs-Deklaration zu versehen. Jedes geparste externe Entity kann einer eigenen Zeichen-Kodierung folgen, muß allerdings dem Parser mit einer Text-Deklaration einen Hinweis auf die Kodierung liefern.
 

18.2 Unicode

Für die ursprüngliche ASCII-Zeichenmenge wurde ein 7-Bit-Schema verwendet. Damit konnten 128 unterschiedliche Zeichen dargestellt werden. Später ist man zu einem 8-Bit-Schema übergegangen. Damit ließen sich 256 Zeichen darstellen. Unicode verwendet ein 16-Bit-Muster und bietet die Möglichkeit, 65.000 Zeichen darzustellen. XML unterstützt den Unicode-Standard.
 

18.3 Zeichen-Referenzen

Zeichenreferenzen dienen dazu, Zeichen darzustellen, die mittels Tastatur nicht eingefügt werden können.

Man kann Zeichen-Referenzen auf zweierlei Weise darstellen:
Dezimale Referenzen beginnen mit &# .
Hexadezimale Referenzen beginnen mit &#x .
 
 
 
 
 
http://members.aol.com/xmldoku, Version 2.0 (vom 1.9.98)
E-Mail an: mailto:duenhoelter@t-online.de
© Copyright 1998, Kuno Dünhölter