Allgemeines Entity

[general entity; Gegenstück: Parameter-Entity]

Der Verfasser von DTDs 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.

Man unterscheidet zwischen allgemeinen Entities und Parameter-Entities. Parameter-Entities werden nur innerhalb von Dokumenttyp-Definitionen verwendet. Soll heißen: Die Ersetzung, die beim Parsen vorgenommen wird, betrifft nur die DTD. Der Ersetzungstext von allgemeinen Entities dagegen erscheint im Dokument selbst.
 

Attributlisten-Deklaration / Attribut-Deklaration

Bei der Deklaration von Attributen wird jedes Attribut einem Typ zugeordnet.
Es gibt drei Hauptgruppen von XML-Attribut-Typen:

• den Zeichenketten-Typ (Schlüsselwort CDATA)
• mehrere Attribut-Typen, die unter dem Oberbegriff  'Token-Typ' zusammengefaßt werden
  (Schlüsselwörter:  ID, IDREF, IDREFS, ENTITY, ENTITIES, NMTOKEN, NMTOKENS, NOTATION, NOTATIONS)
• den Aufzählungstyp (Für den Aufzählungstyp gibt es kein Schlüsselwort. Es muß kein Schlüsselwort gegeben werden. Man erkennt den Aufzählungstyp daran, daß eine Auflistung von möglichen Werten geliefert wird.)

<!ATTLIST termdef

          id      ID      #REQUIRED

          name    CDATA   #IMPLIED>

<!ATTLIST list

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

<!ATTLIST form

          method  CDATA   #FIXED "POST">

In Attribut-Deklarationen wird festgelegt, ob das Attribut immer erscheinen muß, wenn das entsprechende Element in das Dokument gesetzt wird. XML bietet dafür diese 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.

Attribut-Typ

• den Zeichenketten-Typ (Schlüsselwort #CDATA)
• mehrere Attribut-Typen, die unter dem Oberbegriff  'Token-Typ' zusammengefaßt werden
  (Schlüsselwörter:  ID, IDREF, IDREFS, ENTITY, ENTITIES, NMTOKEN, NMTOKENS, NOTATION, NOTATIONS)
• den Aufzählungstyp (Für den Aufzählungstyp gibt es kein Schlüsselwort. Es muß kein Schlüsselwort gegeben werden, denn man erkennt den Aufzählungstyp daran, daß eine Auflistung von möglichen Werten geliefert wird.)

<!ATTLIST termdef

          id      ID      #REQUIRED

          name    CDATA   #IMPLIED>

<!ATTLIST list

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

<!ATTLIST form

          method  CDATA   #FIXED "POST">

Einige Anmerkungen zu den Attributen, die unter dem Oberbegriff 'Token-Typ' zusammengefaßt werden:

ID

Der Wert des Attributs muß einzigartig sein.Wenn es in einem Dokument zwei Attribute vom Typ ID gibt, die beide denselben Wert haben, muß der Parser einen Fehler anzeigen.

IDREF

Der Wert des Attributs muß auf einen ID-Wert verweisen, der irgendwo in dem Dokument definiert wurde. Wenn der Wert des Attributs mit keiner ID im Dokument übereinstimmt, muß der Parser einen Fehler ausgeben.

ENTITY, ENTITIES

Der Wert des Attributs muß mit dem Namen eines externen binären Entity übereinstimmen, das in einer DTD deklariert wurde. ENTITIES verhält sich genauso, erlaubt aber, daß  mehrere Entity-Namen angeführt werden, die durch eine Leerstelle voneinander abgetrennt werden.

NMTOKEN, NMTOKENS

Der Wert des 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. NMTOKENS verhält sich genauso, erlaubt aber mehrere Werte, die durch ein Leerzeichen voneinander getrennt werden.

NOTATION

Der Wert des Attributs muß mit dem Namen einer Notation übereinstimmen, die irgendwo in der DTD definiert wurde.

NOTATION (mit Aufzählung)

Wenn ein Attribut in der Deklaration dem Typ NOTATION zugeteilt wird und außerdem eine Reihe von Namen in der Deklaration zur Auswahl gestellt werden, dann muß der Wert des Attributs mit einem der aufgezählten Namen übereinstimmen, und jeder der Namen muß mit dem Namen einer Notation übereinstimmen, die irgendwo in der DTD definiert wurde.

Aufzählungs-Typ

Bei der Deklaration von Attributen wird jedes Attribut einem Typ zugeordnet.
Es gibt drei Hauptgruppen von XML-Attribut-Typen:

• den Zeichenketten-Typ (Schlüsselwort #CDATA)
• mehrere Attribut-Typen, die unter dem Oberbegriff  'Token-Typ' zusammengefaßt werden
  (Schlüsselwörter:  ID, IDREF, IDREFS, ENTITY, ENTITIES, NMTOKEN, NMTOKENS)
• den Aufzählungstyp (kein Schlüsselwort)

<!ATTLIST list

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

Bedingter Abschnitt

Wenn Sie ein Dokument auf eine externe DTD ausrichten, dann 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.)
 

Beschreibendes Markup

Es gibt in XML-Dokumente drei Arten von Markup: Struktur-Markup (Tags für Überschriften, Tabellen, Listen und anderes), Formatierungs-Markup (Tags für Fettdruck, Kursivschrift und anderes) und beschreibenden Markup (wie zum Beispiel die Tags in <autor> Joseph Roth </autor>).

Die Tags die für beschreibendes Markup verwendet werden, werden häufig als semantische Tags bezeichnet.
 

CDATA

Beispiel für die Deklaration:
 

<!ATTLIST produkt name CDATA #REQUIRED>

Für das Element produkt wird hier das Attribut name deklariert. Das Attribut soll vom Typ CDATA sein, und es wird festgelegt, daß es immer angegeben werden muß, wenn das Element produkt im Dokument erscheint.

 
Attribute vom Typ CDATA können als Wert jede beliebige Zeichenfolge annehmen.
 

CDATA-Abschnitt

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ß.
 

CDF

Deklaration

Dokumenttyp-Definitionen (DTDs) enthalten in erster Linie Deklarationen. Man unterscheidet  folgende Arten von Deklarationen:

Dokumenttyp-Deklaration, Elementtyp-Deklaration, Attribut-Deklaration (=Attributlisten-Deklaration), Entity-Deklaration, Text-Deklaration, Notation-Deklaration.
 

Dokument-Element / Wurzel-Element

Ein Beispiel-Dokument:
 

<?xml version="1.0"?> <!DOCTYPE brief SYSTEM "brief.dtd"> <brief> <anrede>Hallo Leute!</anrede> <text>Alles paletti.</text> </brief>

Das <brief>-Element bildet hier das Wurzelelement. In der Dokumenttyp-Deklaration in Zeile 2 erscheint daher der Name brief.

 

Dokumenttyp-Definition (DTD)

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 es müssen die Vorgaben für die Verschachtelung der Elemente und für die Attribut-Werte eingehalten werden.

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

Wenn alle Dokumente eine größere Zahl von Dokumenten auf dieselbe DTD ausgerichtet wurden, dann ist es außerdem möglich, auf alle diese Dokumente dieselben Formatierungs-Richtlinien anzuwenden. Wer ein XML-Dokument verfaßt, muß sich häufig um die Formatierung keine Gedanken machen, da eine Dokument-übergreifenden Formatierungs-Vorlage zum Einsatz kommt.

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).
 

Dokumenttyp-Deklaration

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.

 
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 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 einfach eine Zeile im Dokument, die angibt, in welcher Datei sich die Dokumenttyp-Definition befindet..

Es gilt die Konvention, daß der Name des öffnenden Tags (des Root-Tags) der Name des Dokuments ist (im Beispiel: 'chapter').
 

Element / Elementtyp

Beispiel für ein Element:
 

<autor>Joseph Roth</autor>

 
Die zugehörige Deklaration in der DTD sieht so aus:
 

<ELEMENT autor #PCDATA>

 
Da die XML-Spezifikation großen Wert auf sprachliche Präzision legt, wird zwischen Element und Elementtyp unterschieden. Dazu ein Beispiel:
 

<p>XML <em>bedeutet nichts.</em>XML ist einfach nur Syntax. Syntax jedoch kann <em> sehr </em> nützlich sein. </p>

 
In diesem Beispiel gibt es drei Elemente (p, em, em) aber nur zwei Elementtypen ( p und em).
 

Element-Inhalt

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 (3) 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.

Für Elemente mit gemischtem Inhalt gilt die Besonderheit, 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.
 

Elementtyp-Deklaration

<!ELEMENT br EMPTY>

<!ELEMENT p (#PCDATA|emph)* >

<!ELEMENT %name.para; %content.para; >

<!ELEMENT container ANY>

Die Inhaltsmodelle folgen dieser Syntax:

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 Element nullmal oder einmal auftreten kann.

Der Stern (*)

gibt an, daß ein Element 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, zum Beispiel so:
(titel, kapitel, (text|überschrift|kodierung)*)

EMPTY zeigt an, daß das Element keinen Inhalt hat.
ANY      zeigt an, daß jede Art von Inhalt erlaubt ist.
 

End-Tag

Entity

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 geparste von nicht-geparsten Entities. Außerdem teilt man in allgemeine und in Parameter-Entities ein, und zuletzt gibt es noch die Unterscheidung zwischen internen und externen Entities.

(1) geparste versus nicht-geparste Entities

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 jeder nicht-geparsten Entity gehört eine sogenannte Notation-Deklaration.
Geparste Entities sind entsprechend solche,  die geparst werden.

(2) allgemeine versus Parameter-Entities

Parameter-Entities haben die Besonderheit, daß das zugehörige Kürzel nur in eine DTD gesetzt werden kann und daß der Ersetzungstext daher in jedem Fall einen Bestandteil der DTD bilden wird.

Alle übrigen Entities (also jene, deren Ersetzungstext nicht in die DTD, sondern in das Dokument eingefügt wird) sind allgemeine Entities.

Beispiel für die Deklaration eines allgemeinen Entity:
 

<!ENTITY mwm "Motorenwerke Mannheim" >

 
Beispiel für die Deklaration eines Parameter-Entity:
 

<!ENTITY % mwm "Motorenwerke Mannheim" >

 
Die Deklaration eines Parameter-Entity unterscheidet sich von der Deklaration eines allgemeinen Entity durch das Prozentzeichen, das vor den Namen gesetzt wird.

Einen Unterschied gibt es auch beim Aufruf der Entities im Dokument:

Der Aufruf des allgemeinen Entity würde so aussehen: &mwm;

Der Aufruf de Parameter-Entity würde so aussehen: %mwm;
 
(3) interne versus externe Entities

Als interne werden alle Entities bezeichnet, deren Ersetzungstext durch die Entity-Deklaration geliefert wird. Bei den oben angeführten Deklarationen für eine allgemeine und für eine Paramter-Entity handelt es sich um interne Entities; der Ersetzungstext ("Mannheimer Motorenwerke") wird in der Deklaration angeführt.

Hier ein Beispiel für die Deklaration eines externen Entity:
 

<!ENTITY boilerplate SYSTEM "/standard/legalnotice.xml">

 
Externe Entities sind solche, deren Ersetzungstext der Parser nur ermitteln kann, indem er eine zusätzliche Datei hinzuzieht. Hier ist es die Datei legalnotice.xml, auf die verwiesen wird.

Interne Entities können Referenzen auf andere interne Entities enthalten, man kann sie allerdings nicht rekursiv verwenden. (Ein Entity kann nicht sich selbst aufrufen.)

Beispiel für die Verwendung einer Entity-Referenz innerhalb einer Entity-Deklaration:
 

<!ENTITY AC "Das &W3C; Advisory Council">  <!ENTITY W3C "WWW Consortium">

 
In einem Dokument, für das die obigen Deklarationen gelten, würde die Referenz &AC; dazu führen, daß in dem Dokument diese Zeichenfolge erscheinen würde:
Das WWW Consortium Advisory Council .

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.
 

Entity-Deklaration

Dies ist ein Beispiel für die Deklaration eines allgemeinen Entity:
 

<!ENTITY mwm "Motorenwerke Mannheim" >

 
Dies ist ein Beispiel für die Deklaration eines Parameter-Entity:
 

<!ENTITY % mwm "Motorenwerke Mannheim" >

 
Dies ist ein Beispiel für die Deklaration eines externen Entity:
 

<!ENTITY ATIlogo  SYSTEM "/standard/logo.gif"  NDATA  GIF87A>

Hier wird ein externes nicht-geparstes Entity deklariert. Das Schlüsselwort NDATA gibt für den Parser den Hinweis, daß in der Datei nicht nach Markup gesucht werden muß.

 
 

Entity-Referenz

Wenn ein Entity im Dokument verwendet werden soll, muß man sie einfach nur mit ihrem 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.

Es gibt eine spezielle Form von Entity-Referenz, die Zeichen-Referenz genannt wird und dazu dient, beliebige Unicode-Zeichen in einen Text einzufügen. Man verwendet Zeichen-Referenzen, um Zeichen einzufügen, die nicht direkt eingetippt werden können.
 

Erweiterbarkeit

Es könnte sich sogar herausstellen, daß sich nur die DTDs, die vom W3C abgesegnet werden, 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.
 

Externes Entity

<!ENTITY Pub-Status "Dies ist Version 1.1 dieses Dokuments">

Im vorherigen Beispiel wurde ein geparstes externes Entity  deklariert. Dies ist die Deklaration für ein nicht-geparstes externes Entity:
 

<!ENTITY Xlogo  SYSTEM "/standard/logo.gif"  NDATA  GIF87A>

 
Das Schlüsselwort NDATA zeigt dem Parser, daß er in der Datei nicht nach Markup suchen muß. Hinter NDATA wird der Name einer Notation angegeben. Es muß daher eine Notation-Deklaratioin geben, in der der Name deklariert wurde. Die Notation-Deklaration wird üblicherweise Angaben dazu enthalten, wie mit dem Entity zu verfahren ist.

Die Entity-Referenz &Xlogo; kann nur als Wert eines Attributs auftreten.
Dazu ein Beispiel: Wenn ein Element brief deklariert wurde, dann kann es für das Element diese Attributlisten-Deklaration geben:
 

<!ATTLIST brief logo ENTITY >

 
Wenn in einem <brief>-Element auf das Xlogo-Entity verwiesen werden soll, dann wird das nach diesen Deklarationen so aussehen:
 

<brief logo='Xlogo'>

 
Der Parser wird die entsprechende Information an eine Anwendung weiterreichen und wird nicht versuchen, den Inhalt von /standard/logo.gif zu verarbeiten.

Externe nicht-geparste Entities sind nötig, damit auf Bilder und auf andere Nicht-XML-Inhalte verwiesen werden kann.
 

Externe Untermenge

Die Deklarationen, die in einer Dokumenttyp-Definition gegeben werden, können sich in einer externen Datei befinden, können aber auch im XML-Dokument erscheinen. (Auch die Möglichkeiten "nur Deklarationen in externer Datei" und "nur Deklarationen innerhalb vom Dokument" sind gegeben). Der Parser wird immer alle diese Deklarationen zusammenfassen und als eine gesamte Dokumenttyp-Definition behandeln.
 

Gemischter Inhalt

Der Inhalt eines Elements - das ist all das, was zwischen dem Start-Tag und dem End-Tag eines Elements erscheint. Man unterscheidet drei verschiedene Arten von Inhalt:

1. Inhalt, der ausschließlich aus Daten besteht.
2. Inhalt, der ausschließlich aus Elementen besteht.
3. Inhalt, der sowohl aus Daten als auch aus Elementen besteht.

Dies ist ein Beispiel für die Deklaration eines Element-Typs 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.

 
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.

Die Unterscheidung zwischen den drei Arten von Inhalten von Elementen ist wichtig, weil es bei gemischtem Inhalt eine Besonderheit gibt: Bei der Deklaration von Elementen mit gemischtem Inhalt können die Typen der Kindelemente beschränkt werden, nicht jedoch ihre Reihenfolge oder die Anzahl der insgesamt enthaltenen Elemente.

Man kann sich dies anhand von dem <DL>-Element und dem <P>-Element von HTML klar machen:

Das <DL>-Element kann nur <DT>- und <DD>-Elemente enthalten. Der Inhalt eines <DL>-Elements ist somit ein Beispiel für ein Element, das ausschließlich Elemente als Inhalt enthält.
Das <P>-Element dagegen 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.

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

Generic Identifier

Geparstes 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 ihr Ersetzungstext tritt, und der Ersetzungstext wird zu einem Bestandteil des Dokuments bzw. der DTD. Da der Parser im Ersetzungstext nach Markup suchen wird, spricht man von geparsten Entities (bzw. von zu parsenden Entities).

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ß.
 

Groß- und Kleinschreibung

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) .
 

Gültiges Dokument

Ein XML-Dokument ist gültig, wenn es auf eine Dokumenttyp-Definition (DTD) ausgerichtet wurde. Auf die DTD muß in einer Dokumenttyp-Deklaration am Anfang des Dokuments (hinter der optionalen XML-Deklaration) verwiesen werden, und das Dokument muß die Festlegungen der DTD einhalten.
 

HTML

Die DTD zu schreiben, war jeweils allenfalls die halbe Arbeit. Es mußten zusätzlich HTML-Spezifikationen verfaßt werden, in denen für alle vorgesehenen Tags festgelegt wurde, wie sich Browser zu verhalten haben, wenn sie die Tags zu verarbeiten haben.

Es wird daran gearbeitet, HTML auf die Grundlage von XML zu stellen. HTML wird dann eine Auszeichnungssprache sein, die neben anderen im Web zum Einsatz kommt. Die aktuelle Planung beim W3C sieht vor, daß  HTML in mehrere auf XML basierende Module untergliedert wird.
Das neue HTML wird abwärtskompatibel sein. (Browser, die auf das neue HTML ausgerichtet sind, werden alte HTML-Dateien verarbeiten können, die alten Browser werden aber mit den neuen HTML-Dokumenten nicht umgehen können.)
 

ID-Attribut

<!ATTLIST termdef

          id      ID      #REQUIRED>

Identifier

IDREF- und IDREFS-Attribut

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.

Der Wert eines IDREF-Attributs muß sich auf ein einzelnes ID-Attribut eines Elements des Dokuments beziehen. Der Wert eines IDREFS-Attributs kann demgegenüber mehrere IDREF-Werte umfassen, die durch eine Leerstelle getrennt werden.
 

Inhalt

Inhaltsmodell

<!ELEMENT spec (front, body, back?)>

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

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

Die Inhaltsmodelle folgen dieser Syntax:

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 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,zum Beispiel so:
(titel, kapitel, (text|überschrift|kodierung)*)

EMPTY zeigt an, daß das Element keinen Inhalt hat (und somit auch keinen End-Tag).

ANY zeigt an, daß jede Art von Inhalt erlaubt ist.
 

Internes Entity

Als internes Entity wird jedes Entity bezeichnet, dessen Wert in der Entity-Deklaration geliefert 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. Der Wert des Entity, der hier angegeben wird, bildet den Ersetzungstext des Kürzels. Das zu dem Entity gehörige Kürzel wird so aussehen: &Pub-Status;

 
Bei der Deklaration eines externen Entity wird demgegenüber eine URL angegeben:
 

<!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:

• &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 ( " ).

Interne Untermenge

Die Deklarationen, die in einer Dokumenttyp-Definition gegeben werden, können sich in einer externen Datei befinden, können aber auch in das XML-Dokument gesetzt werden. (Auch die Möglichkeiten "nur Deklarationen in externer Datei" und "nur Deklarationen innerhalb vom Dokument" sind gegeben). Der Parser wird immer alle diese Deklarationen zusammenfassen und als eine gesamte Dokumenttyp-Definition behandeln.
 
Es gilt die Regel, daß die zuerst eingelesenen Deklarationen gegenüber den nachfolgenden Deklarationen Vorrang haben. Da immer zuerst die interne Untermenge eingelesen wird, kann man die interne DTD dazu nutzen, die Angaben in der externen Untermenge zu überschreiben.

Dies ist ein Beispiel für ein Dokument mit einer internen Untermenge:
 

<?xml version="1.0"? encoding="UTF-8">   <!DOCTYPE gruss [   <!ELEMENT gruss (#PCDATA)>   ]>   <gruss> Hallo XML!</gruss>

In der zweiten Zeile beginnt die Dokumenttyp-Deklaration. Die Dokumenttyp-Deklaration enthält in eckigen Klammern ( [und ] ) eine DTD-Untermenge. In diesem Fall besteht die interne Untermenge aus einer einzelnen Elementtyp-Deklaration.

 
Für die interne Untermenge gibt es gegenüber den externen Untermengen Besonderheiten:

• In der externen Untermenge und in externen Parameter-Entities dürfen Parameter-Entity-Referenzen innerhalb von Markup-Deklarationen stehen, in der internen Untermenge nicht.
• Jedes Parameter-Entity muß aus einer Folge von vollständigen Markup-Deklarationen bestehen.
• In der internen Untermenge darf es keine bedingten Abschnitte geben.

Kodierungs-Deklaration

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.
 

Kommentar

<!--Dies ist ein Kommentar.-->

Die Zeichenkette »--« (zwei Trennstriche) darf in einem Kommentar nicht erscheinen.
 

Leeres Element

Beispiel für die Deklaration eines leeren Elements in der DTD:
 

<!ELEMENT br EMPTY>

 
Wenn dieses Element im Dokument verwendet wird, dann kann das so aussehen: <br />
oder auch so: <br></br>
 

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 interessant sein.
 

Logische Struktur

Es gibt zwei unterschiedliche Arten, die Struktur eines Dokuments zu beschreiben. Zum einen hat ein Dokument eine logische Struktur. Wer die logische Struktur eines Dokuments betrachtet, sieht hierarchisch angeordnete Informationen, wobei die Informationseinheiten durch Elemente gebildet werden. Da die Elemente ineinander verschachtelt sind, ist es möglich, ihre Abhängigkeit voneinander in einer Baumstruktur darzustellen. Die Spitze des Baumes wird dabei durch das sogenannte Dokument-Element gebildet.

Wenn man demgegenüber die physische Struktur eines Dokuments beschreibt, stellt man dar, aus welchen Entities sich das Dokument zusammensetzt.
 

Lokale DTD

Markup

Als Markup werden alle Zeichen betrachtet, die nicht für den menschlichen Betrachter in den Text gesetzt werden, sondern für die Auswertung durch Programme vorgesehen sind.

In XML gibt es diese Arten von Markup:

Start-Tags, End-Tags, Tags von leeren Elementen, Entity-Referenzen, Zeichen-Referenzen, Kommentare, Begrenzungen für CDATA-Abschnitte, Dokumenttyp-Deklarationen, Processing Instructions.
 

Markup-Deklaration

Markup-Deklarationen können den Inhalt eines Dokumentes beeinflussen, so daß er verändert vom Parser an die Anwendung weitergereicht wird. Beispiele sind Vorgaben für Attributwerte sowie Entity-Deklarationen.
 

Mime-Typ

Für XML sind die Mime-Tpen  text/xml und application/xml vorgesehen.
Gültige Definitionen für diese Mime-Typen stehen noch aus.
 

Name

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
 

Namensraum

Wenn über Namensraum-Probleme diskutiert wird, dann kommt immer wieder die Verwendung von  Doppelpunkten ( : ) als Lösungsmöglichkeit ins Spiel. Das Problem mit der Doppeldeutigkeit von 'Schloß' würde man lösen, indem man zwischen <Gebäude:Schloß> und <Schließvorrichtung:Schloß> unterscheidet.
 

NDATA

Hinter das Schlüsselwort wird der Name einer Notation gesetzt. Eine Notation ist eine besondere Art von Deklaration. (Die Ausdrücke Notation und Notation-Deklaration bedeuten letztlich Ähnliches.) In einer Notation-Deklaration wird ein Name mit einem sogenannten Public Identifier verbunden, und wenn die Sache gut läuft, dann sagt der Public Identifier etwas darüber, wie mit dem externen Entity zu verfahren ist  - etwa indem der Public Identifier auf eine Anwendung verweist, an die das externe Entity übergeben werden kann.
 

Nicht-geparstes Entity

Beim Parsen wird im allgemeinen der Ersetzungstext einer Entity-Referenz in das Dokument bzw. in die DTD übernommen. Einen Sonderfall bilden Referenzen auf binäre Entities.

Dies ist ein Beispiel für die Deklaration eines nicht-geparsten Entity:
 

<!ENTITY logo  SYSTEM "/standard/logo.gif"  NDATA  GIF87A>

 
Das Schlüsselwort NDATA liefert für den Parser den Hinweis, daß dieses Entity nicht geparst werden muß.

Geparste Entities werden durch Entity-Referenzen aufgerufen. Nicht-geparste Entities haben dagegen die Besonderheit, daß ihr Name nur als Attribut-Wert auftreten kann - und zwar als Wert von Attributen des Typs ENTITY oder ENTITIES.
 

Nicht-validierender Parser

Ein Parser, der imstande ist, Dokumente auf Gültigkeit zu prüfen, wird als validierender Parser bezeichnet.

Nicht-validierende Parser führen keinen Abgleich zwischen dem Dokument und einer DTD durch - auch dann, wenn es im Dokument eine Dokumenttyp-Deklaration gibt, die auf eine DTD verweist.
Sie überprüfen ausschließlich, ob alle Wohlgeformtheitsbeschränkungen eingehalten wurden.

Der nicht-validierende Prozessor muß außerdem lediglich den Inhalt des Dokument-Elements einlesen und muß sich um möglicherweise enthaltene externe Entitiy-Referenzen nicht kümmern.
 

NMTOKEN-Attribut

Unterschied zwischen NMTOKEN und NMTOKENS: Während der Wert eines NMTOKEN-Attributs 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 / Notation-Deklaration

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
 

NOTATION (Attributtyp)

Parameter-Entity

Entities werden definiert, damit es für häufig genutzte Texte oder auch für Dateien Kürzel gibt. Sobald solch ein Kürzel definiert wurde, hat jeder Verfasser eines Dokuments die Möglichkeit, das Kürzel zu setzen, und der Prozessor wird dafür sorgen, daß an seiner Stelle der Ersetzungstext erscheint - sofern das Dokument auf die DTD ausrichtet wurde, die die Entity-Deklaration enthält.

Parameter-Entities haben gegenüber allgemeinen Entities die Besonderheit, daß sie nur in DTDs verwendet werden können. Die Deklaration und die Verwendung von Parameter-Entities wird durch dieses Beispiel anschaulich:

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".

 
Bei der Deklaration von Parameter-Entities wird vor den Entity-Namen das Prozentzeichen (%) gesetzt.

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 eine Paramater-Entity verwiesen wird) beginnt immer mit dem Prozentzeichen (%) und endet mit einem Semikolon (;).

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

Parser

PCDATA

Physische Struktur

Die XML-Spezifikation unterscheidet zwischen der physischen Struktur eines Dokuments und der logischen Struktur.

Ein XML-Dokument kann sich aus Bestandteilen von vielen Dateien zusammensetzen. Wenn die logische Struktur eines Dokuments beschrieben wird, dann wird beschrieben, welche Bestandteile beteiligt sind.

Dies ist ein Beispiel für ein XML-Dokument, das sich aus mehreren Entities zusammensetzt:
 

<!DOCTYPE handbuch [  <!ENTITY kapitel1 SYSTEM "kap1.xml">  <!ENTITY kapitel2 SYSTEM "kap2.xml">  <!ELEMENT handbuch (kapitel+)>  ]>  <handbuch>  &kapitel1;  &kapitel2;  </handbuch>

Hier wird in den eckigen Klammern ([ und ]) eine interne DTD-Untermenge angegeben. In der Untermenge werden die Entities kapitel1 und kapitel2 deklariert, außerdem das Element handbuch. Der Inhalt eines <handbuch>-Elements soll sich aus einem oder mehreren <kapitel>-Elementen zusammensetzen. Das Dokument-Element (= Root-Element) reicht von <handbuch bis </handbuch>. Innerhalb des Dokument-Elements wird auf die Entities kapitel1 und kapitel2 verwiesen. (Da sich ein <handbuch>-Element aus <kapitel>-Elementen zusammensetzen soll,  müssen die Teildokumente kapitel1 und kapitel2 ein <kapitel>-Element als Root-Element haben.)

 
Jedes geparste Entity kann Referenzen auf andere Entities enthalten. Es ist daher möglich, die physische Struktur eines Dokuments - ebenso wie die logische Struktur - als eine Baumstruktur darzustellen.
 

Processing Instruction

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 Verarbeitungs-Anweisungen, 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.
 

Prolog

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>

 

Public Identifier

Es gibt drei Arten von Deklarationen, in denen Web-Adressen angegeben werden:

• In einer Dokumenttyp-Deklarationen wird die Adresse angegeben, unter der die DTD zu finden ist.
• Bei der Deklaration von externen Entities wird angegeben, wo die Entity zu finden ist.
• In einer Notation-Deklaration wird die Adresse angegeben, unter der eine Anwendung zu finden ist.

Manche DTDs sind standadisiert worden und sind in der standardisierten Form 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, in denen sich zu den jeweiligen Angaben ermitteln läßt, unter welcher Adresse das Dokument oder die DTD zu finden ist.

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 vermieden, daß die DTD wieder und wieder aus dem Netz geholt wird.

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:
 

<!ENTITY HTML.Version PUBLIC "-//W3C//DTD HTML 4.0//EN"   "http://www.w3.org/TR/REC-html40/loose.dtd" >

 
Die gängigen Browser haben sich bisher um diese Deklarationen nicht gekümmert. Die Browser sind auf eine bestimmte DTD festgelegt worden; die Möglichkeit, zwischen den DTDs zu wechseln, gab es bisher nicht. Für XML gehört jedoch die Wahlmöglichkeit zwischen den DTDs zu den Grundvoraussetzungen für das Funktionieren.
 

RDF

RDF soll den Entwicklern eine standardisierte Möglichkeit bieten, wie sie eine große Menge von Elementen und die Beziehungen, die sie untereinander haben, notieren können. Daten, die mit RDF erfaßt wurden, sollen Dokument-übergreifende Suchläufe vereinfachen.
 

Referenz

RMD

Root-Element

SGML

SGML wird dazu genutzt, Tausende von unterschiedlichen DTDs zu definieren. DTDs gibt es für die unterschiedlichsten Arbeitsgebiete - von der Übertragung alter sumerischer Schriftrollen bis zu der technischen Dokumentation eines Stealth-Bombers, von Patientendaten im Krankenhaus bis zum Aufzeichnen der Noten von Musikstücken.
 
XML ist eine verkürzte Version von SGML. XML wurde geschaffen, indem man die komplexeren und weniger genutzten Teile von SGML weggelassen hat. Von der SGML-Gemeinde wurde der XML-Standard einhellig begrüßt. Firmen, die sich bisher um SGML-Projekte gekümmert haben, fühlen sich heute auch für XML zuständig.
 

Speicherungseinheit

Standalone-Deklaration

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

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.)
 

Style Sheet

Man kann allerdings erwarten, daß die Browser auch zukünftig Standard-Vorlagen für die am meisten verbreiteten Elemente bereithalten werden.

Der Einsatz von Cascading Style Sheets (CSS) ist zusammen mit XML problemlos möglich.
Es wird jedoch an einer Formatierungssprache namens XLS gearbeitet, die zusätzliche Möglichkeiten bieten wird.
 

System Identifier

Es gibt drei verschiedene Arten von Deklarationen, in denen Web-Adressen angegeben werden:

• In Dokumenttyp-Deklarationen wird die Adresse angegeben, unter der die DTD zu finden ist.
• Bei der Deklaration von externen Entities wird angegeben, wo die Entity zu finden ist.
• In einer Notation-Deklaration wird die Adresse angegeben, unter der eine Anwendung zu finden ist.

Die System Identifier sind bisher die gebräuchlichste Form für die Angabe von Adressen.
Beispiel für die Verwendung eines System Identifiers bei der Deklaration eines Parameter-Entity:
 

<!ENTITY logo SYSTEM "http://www.abc-comp/standard/logo.gif"  NDATA  GIF87A>

 
Ein System Identifier wird eingeleitet durch das Schlüsselwort SYSTEM. In Anführungsstrichen folgt dahinter die URL.
 

Text-Deklaration

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.
 

Unicode

Validierender Parser

Im Rahmen von XML wird zwischen gültigen und wohlgeformten Dokumenten unterschieden. Gültig ist ein Dokument, wenn es auf eine DTD ausgerichtet wurde und die Vorgaben der DTD einhält. Ein Dokument, das nicht auf eine DTD ausgerichtet wurde, kann den Status der Wohlgeformtheit erreichen. Voraussetzung ist, daß das Dokument eine Reihe von Wohlgeformtheitsregeln einhält.

Sowohl validierende als auch nicht-validierende Prozessoren müssen Verletzungen der  Wohlgeformtheitsbeschränkungen, die sie lesen, melden. Solche Verstöße werden als 'critical errors' betrachtet und führen dazu, daß der Parser seine Arbeit abbricht.
 

Vordefiniertes Entity

&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 ( " ).

Wenn diese Entity-Referenzen im Text erscheinen, wird der Parser davon absehen, die entsprechenden Zeichen als Syntax-Zeichen zu betrachten.
 

W3C

Das W3C ist neben der IETF eine der beiden Organisationen, die Standards für das Internet entwickeln. Das W3C hat den XML-Standard festgelegt.
 

Wohlgeformtes Dokument

(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.
 

Wurzel-Element / Dokument-Element

Beispiel für ein Dokument mit Wurzelement:
 

<?xml version="1.0"?> <!DOCTYPE brief SYSTEM "brief.dtd"> <brief> <anrede>Hallo Leute!</anrede> <text>Alles paletti.</text> </brief>

 
Das <brief>-Element bildet hier das Wurzelelement. In der Dokumenttyp-Deklaration in Zeile 2 erscheint daher der Name 'brief'.
 

XML

XML-Deklaration

Dies ist ein 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.

Die XML-Deklaration liefert allgemeine Angaben über ein Dokument. Dieselben Angaben können auch an den Anfang von einem externen geparsten Entity gesetzt werden. Wenn sie in einer externen geparsten Entity erscheinen, spricht man allerdings nicht mehr von einer XML-Deklaration, sondern bezeichnet das Ganze dann als Text-Deklaration.
 

XML-Dokument

Jedes XML-Dokument hat sowohl eine »logische« als auch eine »physische Struktur«.
Physisch besteht das Dokument aus einer Reihe von Einheiten, die als Entities bezeichnet werden.
Aus logischer Sicht besteht das Dokument aus all den Bestandteilen, die durch explizites Markup ausgezeichnet sind, also aus Elementen, Entity-Referenzen, Kommentaren, Verarbeitungs-Anweisungen, bedingten Abschnitten und der Dokumenttyp-Deklaration.

Beachten Sie, daß HTML und XML einander nicht ausschließen. Sobald HTML-DTDs zur Verfügung stehen, die auf XML basieren, kann ein Dokument, das ein HTML-Dokument ist, zugleich auch ein XML-Dokument sein.
 

xml:lang

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>

 
Die Sprachencodes stammen aus dem Standard ISO639.
Es sind auch Sub-Klassifizierungen möglich. So steht de-CH für das Deutsch der Schweizer und de-DE für das Deutsch der Deutschen.
 

xml:space

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 interessant sein.
 

XML-Parser / XML-Prozessor

Die Aufgaben des Parsers bei der Verarbeitung eines Dokuments:

• Er bestimmt, ob das Dokument wohlgeformt ist, und gibt eventuell Fehlermeldungen aus.
• Wenn sich das Dokument aus Bestandteilen zusammensetzt, die sich in unterschiedlichen Dateien befinden, führt er die Bestandteile zusammen.
• Der Parser erstellt einen Baum, durch den die Inhalte der Elemente für die Anwendung zugreifbar werden.

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

XML-Spezifikation

Extended Backus Naur Form

Der gesamten Spezifikation liegt eine Sprache namens Extended Backus Naur Form (EBNF) zugrunde.

DTD-Syntax

Was die Spezifikation in erster Linie leistet: Es wird festgelegt, welche Regeln eingehalten werden müssen, wenn Dokument-Typ-Definitionen (DTDs) geschrieben werden. Zum Beispiel wird festgelegt, daß jede Elementtyp-Definition mit '<!ELEMENT '  beginnen muß.

Dokument-Syntax

Die Spezifikation legt fest, welche Syntax die DTDs einhalten müssen. Indirekt sagt die Spezifikation damit auch allerhand darüber, wie Dokumente aufgebaut werden müssen. Es gibt in der Spezifikation daneben aber auch explizite Angaben darüber, wie die Dokumente aufgebaut sein sollen. Beispielsweise ist dort festgelegt, daß alle Dokumente  mit einer XML-Deklaration beginnen sollen.

XSL

XSL ist eine Sprache für Formatvorlagen (Stylesheets). Zwar können für die Formatierung von XML-Dokumenten auch Cascading Style Sheets (CSS) verwendet werden,  XSL soll jedoch Möglichkeiten bieten, die über die der CSS hinausgehen. So soll es mit XSL möglich sein, in XML-Dokumenten automatisch erzeugten Text einzufügen, zum Beispiel Seitennummern, die automatisch hochgezählt werden.

Die Zeitplanung des W3C in Sachen XSL sieht so aus:

Second Working Draft:          November 1998
Third Working Draft:              Februar 1999
Proposed Recommendation:   Mai 1999
 

Zeichen-Referenz

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: Duenhoelter@t-online.de
© Copyright 1998, Kuno Dünhölter