Glossar

   
Haupttext 
XML-Syntax 
Fragen und Antworten   
 
 
 
Allgemeines Entity / Attributlisten-Deklaration / Attribut-Typ / Aufzählungs-Typ / Bedingter Abschnitt / Beschreibendes Markup / CDATA / CDATA-Abschnitt / CDF / Deklaration / Dokument-Element / Dokumenttyp-Definition (DTD) / Dokumenttyp-Deklaration / Element / Element-Inhalt / Elementtyp-Deklaration / End-Tag / Entity / Entity-Deklaration / Entity-Referenz / Erweiterbarkeit / Externes Entity / Externe Untermenge / Gemischter Inhalt / Generic Identifier / Geparstes Entity / Groß- und Kleinschreibung / Gültiges Dokument / HTML / ID-AttributIDREF-Attribut / Inhalt / Inhaltsmodell / Internes Entity / Interne Untermenge / Kodierungs-Deklaration / Kommentar / Leeres Element / Leerraum / Logische Struktur / Markup / Markup-Deklaration / Mime-Typ / Name / Namensraum / NDATA / Nicht-geparstes Entity / Nicht-validierender Parser / NMTOKEN-Attribut / Notation / NOTATION-Attribut / Parameter-Entity / PCDATA / Physische Struktur / Processing Instruction / Prolog / Public Identifier / RDF / Referenz / RMD / Root-Element / SGML / Speicherungseinheit / Standalone-Deklaration / Style Sheet / System Identifier / Text-Deklaration / Unicode / Validierender Parser / Vordefiniertes Entity / W3C / Wohlgeformtes Dokument / Wurzel-Element / XML / XML-Deklaration / XML-Dokument / xml:lang / xml:space / XML-Parser / XML-Spezifikation / XSL / Zeichen-Referenz
 

 
 

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

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.
Es gibt drei Hauptgruppen von XML-Attribut-Typen:

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

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

Bei der Deklaration von Attributen wird jedes Attribut einem Typ zugeordnet.
Es gibt drei Hauptgruppen von XML-Attribut-Typen: Beispiele für die Deklaration von Attributen:
 
<!ATTLIST termdef

          id      ID      #REQUIRED

          name    CDATA   #IMPLIED>

<!ATTLIST list

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

<!ATTLIST form

          method  CDATA   #FIXED "POST">
Das Attribut 'id' wird dem Attribut-Typ 'ID' zugeordnet. 
Die Attribute 'name' und 'method werden dem Attribut-Typ 'CDATA' zugeteilt. 
Das Attribut 'type' wird dem Aufzählungstyp zugeordnet.
 

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

[enumerated type]

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

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. 
 
 


Bedingter Abschnitt

[conditional section]

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

[descriptive 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

Bei der Deklaration eines Attributs wird es einem Attributtyp zugeordnet. Der am häufigsten angegebene Attributtyp ist 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 section]

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

Das Channel Definition Format ist ein von Microsoft geschaffenes Datei-Format, das auf XML basiert. CDF-Dateien werden im Zusammenhang mit der Push-Technologie eingesetzt.
 

Deklaration

[deklarieren = den Inhalt, Wert von etwas angeben ]

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

In jedem XML-Dokument gibt es ein Element, das den Container für alle anderen Elemente bildet. Man nennt dieses Element Dokument-Element. Der Name des Dokument-Elements erscheint in der Dokumenttyp-Deklaration.

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)

In einer Dokumenttyp-Definition werden die Regeln festgelegt, die für Dokumente eines bestimmten Typs gelten sollen.

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

Die Dokumenttyp-Deklaration befindet sich am Anfang von einem Dokument. 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.
 
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

Ein Element setzt sich im allgemeinen zusammen aus einem Start-Tag, einem End-Tag und dem Inhalt des Elements. Es gibt aber auch leere Elemente. Leere Elemente haben keinen Inhalt.

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

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

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

Elementtyp-Deklarationen legen die Namen der Elemente fest, die in den Dokumenten des betreffenden Typs möglich sein sollen. Es wird angegeben, von welcher Art ihre Inhalte sind und welche Attribute es geben soll. Dies sind Beispiele für Elementtyp-Deklarationen:
 
<!ELEMENT br EMPTY>

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

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

<!ELEMENT container ANY>
 
Eine Elementtyp-Deklaration beginnt mit <!ELEMENT. Es folgt der Name des Elements, und was sich daran anschließt, wird als Inhaltsmodell bezeichnet.

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)*)
Es gibt zwei Schlüsselwörter, die Inhaltsmodelle besonderer Art kennzeichnen:

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

End-Tag

Während in HTML die End-Tags in vielen Fällen weggelassen werden können, gelten für XML-Dokumente strengere Regeln. Auf jedes Start-Tag muß ein End-Tag folgen. Zum Beispiel muß auf jedes <P> ein </P> folgen, und ein leeres Element wie <IMG SRC="datei.jpg"> muß durch ein </IMG> abgeschlossen werden. Alternative: Man setzt einen abschließenden Slash, so daß der IMG-Tag so aussieht:  <IMG SRC="datei.jpg" />
 

Entity

'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 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

Für die Deklaration von Entities gibt es drei verschiedene Arten von Syntax:

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

Die Entity-Referenz, das ist die Zeichenfolge, mit der auf eine Entity verwiesen wird.

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

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, 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

Als interne Entities werden alle Entities bezeichnet, die ihren Ersetzungstext bei der Deklaration mitgeliefert bekommen. Dies ist ein Beispiel für die Deklaration eines internen Entity:
 
<!ENTITY Pub-Status "Dies ist Version 1.1 dieses Dokuments">
 
Als externe Entities werden demgegenüber alle Entities bezeichnet, bei deren Deklaration auf  eine andere Datei verwiesen wird. Beispiel:
 
<!ENTITY boilerplate  SYSTEM "/standard/legalnotice.xml">  
 
 
Wenn man &boilerplate; verwendet, führt das dazu, daß beim Parsen des Dokuments der Inhalt der Datei /standard/legalnotice.xml an der Stelle eingefügt wird, an der bis dahin &boilerplate; gestanden hat. Der Parser wird den Inhalt der Datei so parsen, als wenn er an der entsprechenden Stelle in das Dokument eingetippt worden wäre.

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

[external subset]

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

[mixed content]

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.
Bei Möglichkeit (3) spricht man von Gemischtem Inhalt.

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

Die Namen von Elementtypen werden als Generic Identifier bezeichnet werden. Damit wird besonders herausgestellt, daß bei einer Elementtyp-Deklaration nicht ein einzelnes Element deklariert wird, sondern eine Elementart (= Elementtyp). 'Generic' bedeutet 'auf die Art bezogen'.
 

Geparstes Entity

[parsed entity; Gegenstück: nicht-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

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

Gültiges Dokument

[valid document]

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 Auszeichnungssprache HTML basiert auf SGML. Die Regeln, die eingehalten werden müssen, wenn HTML-Dokumente verfaßt werden, sind  in SGML-DTDs festgelegt. Für jede neue Version von HTML wurde eine neue DTD erstellt.

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

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

          id      ID      #REQUIRED>
Hier wird für das Element termdef 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 <termdef>-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.
 

Identifier

siehe Public Identifier bzw. System Identifier
 

IDREF- und IDREFS-Attribut

Die ID-Attribute und die IDREF-Attribute bieten zusammen einen kleinen Mechanismus zur Schaffung von Links innerhalb von Dokumenten. Jedes IDREF-Attribut verweist dabei auf ein bestimmtes ID-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

Der Inhalt eines Elements - das ist all das, was zwischen dem Start-Tag und dem End-Tag eines Elements erscheint.
 

Inhaltsmodell

Mit jeder Elementtyp-Deklaration wird ein Inhaltsmodell geliefert. Beispiele:
 
<!ELEMENT spec (front, body, back?)>

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

<!ELEMENT dictionary-body (%div.mix; | %dict.mix;)*>
 
In einer Elementtyp-Deklaration folgt auf das Schlüsselwort 'ELEMENT' der Name des Elementtyps. Die Angaben, die dahinter folgen, bilden das Inhaltsmodell.

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)*)
Es gibt zwei Schlüsselwörter, die Inhaltsmodelle besonderer Art kennzeichnen:

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

Entities ermöglichen es, für häufig verwendeten Text Kürzel zu deklarieren. Wenn das Kürzel im Dokument (oder in der DTD) auftritt, wird der Parser dafür sorgen, daß an die Stelle des Kürzels der Ersetzungstext tritt. Die Kürzel können für Text verwendet werden, von dem man erwartet, daß er sich häufig ändert, zum Beispiel den Bearbeitungsstand eines Dokuments. Sobald sich der Bearbeitungsstand geändert hat, muß man nur noch die Deklaration des Entity verändern und sorgt damit dafür, daß an jeder Stelle, an der das Kürzel gesetzt wurde, der veränderte Text erscheint.

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:

 

Interne Untermenge

[internal subset]

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:

 

Kodierungs-Deklaration

[encoding declaration]

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

Kommentare haben in XML-Dokumenten die Form, die von HTML her bekannt ist:
 
<!--Dies ist ein Kommentar.-->
 
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.

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

Leeres Element

Elemente setzen sich aus einem Start-Tag, einem End-Tag und aus dem Inhalt des Elements zusammen. Einen Sonderfall bilden die leeren Elemente; sie haben keinen Inhalt.

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

[white space]

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

[Gegenstück: Physische 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

Siehe interne Untermenge
 

Markup

[Gegenstück: Zeichendaten]

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-Deklaration ist der Oberbegriff für Elementtyp-Deklaration, Attributlisten-Deklaration, Notation-Deklaration und Entity-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

Mime-Typen spielen bei einer Internet-Verbindung auf dem Server-Rechner und auf dem lokalen eine Rolle. Indem man auf dem lokalen PC einem Dateityp einen Mime-Typ zuordnet, legt man fest, wie die Dateien des entsprechenden Typs verarbeitet werden sollen. Wenn man beispielsweise alle Dateien mit den Endungen HTM und HTML dem Mime-Typ text/html zuordnet, dann wird der Browser alles Markup, das ihm begegnet, verarbeiten. Wenn die Dateien degegen dem Mime-Typ text/plain zuordnet werden, wird der Browser beim Aufruf einer entsprechenden Datei den Quelltext anzeigen.

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

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
 

Namensraum

Das Namensraum-Problem tritt auf, wenn man ein Dokument gestalten will, das Teile von einem oder mehreren anderen Dokumenten verwendet. Wenn es sich um Dokumente handelt, die von anderen geschaffen wurden, dann wird sich immer wieder herausstellen, daß die anderen Autoren Namen verwenden, die man auch selber schon verwendet. So können ein Reiseführer über das Loire-Tal und das Prospekt eines Herstellers von Türen beide das Wort 'Schloß' verwenden und dabei sehr unterschiedliche Sachen meinen. Wenn nun jemand damit beschätigt ist, deutschsprachigen Schloß-Besitzern des Loire-Tals Türen zu verkaufen, dann entsteht aus der Doppeldeutigkeit von 'Schloß' ein Problem.

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

Das Schlüsselwort NDATA wird bei der Definition von Entities verwendet:
 
<!ENTITY bild SYSTEM "../bilder/OpenHatch.gif" NDATA gif >
Hier wird das Entity bild deklariert. Es wird eine Adresse angegeben, unter der das Entity zu finden ist. Wenn bestimmt werden soll, wie mit dem Entity zu verfahren ist, muß nach der Deklaration für die Notation gif gesucht werden.
 
Das Schlüsselwort NDATA gibt dem Parser den Hinweis, daß es sich um ein externes Entity handelt, das nicht geparst werden muß.

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

[unparsed entity; Gegenstück: 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

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 noch den Status der Wohlgeformtheit erreichen. Voraussetzung ist, daß das Dokument eine Reihe von Wohlgeformtheitsregeln einhält.

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

Dies ist ein Beispiel für eine Attribut-Deklaration, bei der das Attribut dem Attributtyp NMTOKEN zugeordnet wird:
 
<!ATTLIST produkt code NMTOKEN> 
 
 
Attribute vom Typ NMTOKEN sind den String-Attributen vom Typ CDATA ähnlich. Der Unterschied besteht darin, daß für den Wert eines NMTOKEN-Attributs dieselben Beschränkungen gelten wie für jeden Namen (siehe Stichwort Name). Im Wert eines CDATA-Attributs ist dagegen jedes Zeichen erlaubt.

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

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 externe 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
 

NOTATION (Attributtyp)

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 eps im Dokument als Wert des bild-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.

Parameter-Entity

[Gegenstück: allgemeines 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

siehe XML-Parser

PCDATA

Das Schlüsselwort #PCDATA kann bei der Deklaration von Elementen verwendet werden. Es zeigt an, daß das deklarierte Element Zeichendaten als Inhalt haben kann. Die Buchstabenfolge "PCDATA" steht für "Parsed Character Data".
 

Physische Struktur

[physical structure]

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

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

Der Teil eines XML-Dokuments, der vor dem ersten Start-Tag 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>
 

Public Identifier

[Gegenstück: System 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 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

Bei dem Resource Description Format (RDF) handelt es sich um einen Standard, mit dem festgelegt wird, wie auf der Grundlage von XML Metadaten beschrieben werden. (Metadaten sind Daten, die andere Daten, zum beispiel Dokumente, beschreiben.)

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

Die XML-Spezifikation legt auf sprachliche Präzision großen Wert. Es ist niemals die Rede davon, daß in ein Dokument eine Entity eingefügt wird. Man wählt die präzisere Sprechweise und sagt, daß eine Entity- Referenz  eingefügt wird. Die Referenz ist dabei das Kürzel, durch das die Entity vertreten wird.
 

RMD

RMDs sind syntaktische Konstrukte, die in der gültigen Endfassung der XML-Spezifikation keine Rolle mehr spielen. Die Required Markup Declaration wurde durch die Standalone-Deklaration abgelöst.
 

Root-Element

Die XML-Spezifikation sieht vor, daß alle Elemente eines Dokuments zum Inhalt eines einzelnen übergreifenden Elements gehören müssen. Das übergreifende Element wird als Root-Element (oder Dokument-Element) bezeichnet.
 

SGML

Die Standard Generalized Markup Language ist ein Standard, der festlegt, wie in elektronischen Dokumenten Strukturen und Inhalte beschrieben werden sollen. Die International Standards Organization (ISO) hat SGML 1986 zu einer Norm gemacht.

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

Eine Speicherungseinheit besteht aus einer Reihe von Zeichen, die als gemeinsames Kennzeichen haben, daß sie alle am selben physischen Ort gespeichert werden. Entities werden als Speicherungseinheiten gesehen.
 

Standalone-Deklaration

Dies ist ein Beispiel für eine XML-Deklaration, die eine Standalone-Deklaration enthält:
 
<?xml version="1.0" standalone='yes'?>
 
Hier wird dem Prozessor mitgeteilt, 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.)
 

Style Sheet

Zu SGML gehört die Idee, daß man mit Tags die Dokumentstruktur kennzeichnen soll und daß die Formatierungen davon abhängig sein sollen, was auf dem jeweiligen Ausgabegerät an Formatierungsmöglichkeiten vorhanden ist. Im Rahmen von XML gilt daselbe.

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

[Gegenstück: Public Identifier]

Es gibt drei verschiedene 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.

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

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.
 

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.
 

Validierender Parser

[Gegenstück: nicht-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

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 Zeichen-Entities bereit. Dies sind die 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 ( " ).

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

W3C

[Abkürzung für 'World Wide Web Consortium']

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

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 noch den Status der Wohlgeformtheit erreichen. Voraussetzung ist, daß das Dokument eine Reihe von Wohlgeformtheitsregeln einhält. 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.
 

Wurzel-Element / Dokument-Element

In jedem XML-Dokument gibt es ein Element, das den Container für alle anderen Elemente bildet. Der Name dieses Elements erscheint in der Dokumenttyp-Deklaration.

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

Die eXtensible Markup Language  ist eine Sprache, mit der sich Auszeichnungssprachen definieren lassen. XML ist eine verkürzte Version der Standard Generalized Markup Language (SGML).
 
Die offizielle XML-Arbeitsgruppe des W3C begann ihre Arbeit im Juli 1996. Bereits im November '96 waren die Grundzüge von XML festgelegt, und im April '97 hatte man Einigkeit über die meisten Feinheiten gewonnen. Im Dezember '97 wurde aus dem 'Working Draft' (Entwurf) eine 'Proposed Recommendation' (eine vorgeschlagene Empfehlung). Seit dem 10. Februar 1998 ist XML eine Recommendation. Wenn Veränderungen vorgenommen werden sollen, dann müssen diese in eine neue Version einfließen.
 

XML-Deklaration

XML-Dokumente können und sollen mit einer XML-Deklaration beginnen. Die XML-Deklaration gibt an, welche XML-Version verwendet wird. Wenn sie vorhanden ist, bildet sie die erste Zeile eines Dokuments.

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

Ein XML-Dokument setzt sich aus Markup und aus Inhalt zusammen.

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

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

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

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.
 

XML-Parser / XML-Prozessor

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 Prozessor 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 prüfen lediglich auf Wohlgeformtheit (wobei Verstöße gegen die Wohlgeformtheit die schwerwiegenderen Verstöße sind).
 

XML-Spezifikation

In der XML-Spezifikation ist festgelegt, wie XML funktioniert.
Auf dreierlei Weise spielen in der Spezifikation Sprachen eine Rolle:
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.
Wer sich mit der Spezifikation beschäftigt, findet formale Definitionen, die auf der Extended Backus Naur Form beruhen, außerdem aber auch normalsprachliche Darstellungen.
 

XSL

[Abkürzung für 'eXtensible Style Language']

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

[character reference]

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