[This local archive copy mirrored from the canonical site: http://www.mintert.com/xml/trans/REC-xml-19980210-de.html; links may not have complete integrity, so use the canonical document at this URL if possible.]

Extensible Markup Language (XML) 1.0

REC-xml-19980210

Extensible Markup Language (XML) 1.0

Empfehlung des W3C, 10. Februar 1998

Diese Version

• http://www.w3.org/TR/1998/REC-xml-19980210
• http://www.w3.org/TR/1998/REC-xml-19980210.xml
• http://www.w3.org/TR/1998/REC-xml-19980210.html
• http://www.w3.org/TR/1998/REC-xml-19980210.pdf
• http://www.w3.org/TR/1998/REC-xml-19980210.ps

Aktuelle Version

http://www.w3.org/TR/1998/REC-xml

Vorherige Version

http://www.w3.org/TR/PR-xml-971208

Herausgeber

• Tim Bray (Textuality und Netscape) <tbray@textuality.com>
• Jean Paoli (Microsoft) <jeanpa@microsoft.com>
• C. M. Sperberg-McQueen (Universität Chicago) <cmsmcq@uic.edu>

Zusammenfassung

Die Extensible Markup Language (XML) ist eine Teilmenge von SGML, die vollständig in diesem Dokument beschrieben ist. Das Ziel ist es, zu ermöglichen, generic SGML in der Weise über das Web auszuliefern, zu empfangen und zu verarbeiten, wie es jetzt mit HTML möglich ist. XML wurde entworfen, um eine einfache Implementierung und Zusammenarbeit sowohl mit SGML als auch mit HTML zu gewährleisten.

Status dieses Dokuments

Dieses Dokument wurde von Mitgliedern des W3C und anderen Interessierten geprüft und vom Direktor als W3C-Empfehlung gebilligt. Es ist ein stabiles Dokument und darf als Referenzmaterial verwendet oder als normative Referenz von einem anderen Dokument zitiert werden. Die Rolle des W3C bei der Erstellung dieser Empfehlung ist es, die Spezifikation bekanntzumachen und ihre breite Anwendung zu fördern. Dies erhöht die Funktionsfähigkeit und Interoperabilität des Web.

Dieses Dokument definiert eine Syntax, die als Teilmenge eines bereits vorhandenen und weithin eingesetzten internationalen Standards (Standard Generalized Markup Language, ISO 8879:1986(E), in der berichtigten und korrigierten Fassung) für die Anwendung im World Wide Web geschaffen wurde. Es ist ein Ergebnis des XML-Engagements des W3C; Einzelheiten sind unter http://www.w3.org/XML/ zu finden. Eine Liste aktueller W3C-Empfehlungen und anderer technischer Dokumente ist unter http://www.w3.org/TR/ zu finden.

Diese Spezifikation verwendet den von [Berners-Lee et al.] definierten Begriff URI; die Arbeit daran ist noch im Gange und wird voraussichtlich [IETF RFC1738] und [IETF RFC1808] aktualisieren.

Die Liste der bekannten Fehler in dieser Spezifikation ist unter http://www.w3.org/XML/xml-19980210-errata verfügbar.

Bitte melden Sie Fehler in diesem Dokument an <xml-editor@w3.org>.

Inhaltsverzeichnis

1 Einleitung

Die Extensible Markup Language, abgekürzt XML, beschreibt eine Klasse von Datenobjekten, genannt XML-Dokumente, und beschreibt teilweise das Verhalten von Computer-Programmen, die solche Dokumente verarbeiten. XML ist ein Anwendungsprofil (application profile) oder eine eingeschränkte Form von SGML, der Standard Generalized Markup Language [ISO 8879]. Durch ihre Konstruktion sind XML-Dokumente konforme SGML-Dokumente.

XML-Dokumente sind aus Speicherungseinheiten aufgebaut, genannt Entities, die entweder analysierte (parsed) oder nicht analysierte (unparsed) Daten enthalten. Analysierte Daten bestehen aus Zeichen, von denen einige Zeichendaten und andere Markup darstellen. Markup ist eine Beschreibung der Aufteilung auf Speicherungseinheiten und der logischen Struktur des Dokuments. XML bietet einen Mechanismus an, um Beschränkungen der Aufteilung und logischen Struktur zu formulieren.

Ein Software-Modul, genannt XML-Prozessor, dient dazu, XML-Dokumente zu lesen und den Zugriff auf ihren Inhalt und ihre Struktur zu erlauben. Es wird angenommen, daß ein XML-Prozessor seine Arbeit als Teil eines anderen Moduls, genannt Anwendung, erledigt. Diese Spezifikation beschreibt das notwendige Verhalten eines XML-Prozessors soweit es die Frage betrifft, wie er XML-Daten einlesen muß und welche Informationen er an die Anwendung weiterreichen muß.

1.1 Herkunft und Ziele

XML wurde von einer XML-Arbeitsgruppe (ursprünglich bekannt als das SGML Editorial Review Board) entwickelt, die 1996 unter der Schirmherrschaft des World Wide Web Consortium (W3C) gegründet wurde. Den Vorsitz hatte Jon Bosak von Sun Microsystems inne, unter aktiver Beteiligung einer XML Special Interest Group (ehemals SGML-Arbeitsgruppe), die ebenfalls vom W3C organisiert wurde. Die Mitglieder der XML-Arbeitsgruppe sind in einem der Anhänge genannt. Dan Connolly fungierte als Kontaktperson zwischen der Arbeitsgruppe und dem W3C.

Die Entwurfsziele für XML sind:

1. XML soll sich im Internet auf einfache Weise nutzen lassen.
2. XML soll ein breites Spektrum von Anwendungen unterstützen.
3. XML soll zu SGML kompatibel sein.
4. Es soll einfach sein, Programme zu schreiben, die XML-Dokumente verarbeiten.
5. Die Zahl optionaler Merkmale in XML soll minimal sein, idealerweise Null.
6. XML-Dokumente sollten für Menschen lesbar und angemessen verständlich sein.
7. Der XML-Entwurf sollte zügig abgefaßt sein.
8. Der Entwurf von XML soll formal und präzise sein.
9. XML-Dokumente sollen leicht zu erstellen sein.
10. Knappheit von XML-Markup ist von minimaler Bedeutung.

Diese Spezifikation enthält, zusammen mit den verwandten Standards (Unicode und ISO/IEC 10646 für Zeichen, Internet-RFC 1766 für Codes zur Identifikation der Sprache, ISO 639 für Codes von Sprachnamen und ISO 3166 für Ländernamen-Codes), alle Informationen, die notwendig sind, um XML in der Version 1.0 zu verstehen und um Programme zu schreiben, die sie verarbeiten.

Diese Version der XML-Spezifikation darf frei weitergegeben werden, solange der gesamte Text und alle rechtlichen Hinweise unversehrt bleiben.

1.2 Terminologie

darf (may)

Konforme Dokumente und XML-Prozessoren dürfen sich so verhalten, wie beschrieben, müssen es aber nicht.

müssen/nicht dürfen (must)

Konforme Dokumente und XML-Prozessoren müssen sich/dürfen sich nicht so verhalten, wie beschrieben, andernfalls sind sie fehlerhaft.

Fehler (error)

Eine Verletzung der Regeln der Spezifikation; die Konsequenzen sind nicht definiert. Konforme Software darf Fehler erkennen und anzeigen und anschließend weiterarbeiten.

Kritischer Fehler (fatal error)

Ein Fehler, den ein konformer XML-Prozessor erkennen und an das Anwendungsprogramm melden muß. Nach der Erkennung eines kritischen Fehlers darf der Prozessor die Verarbeitung fortsetzen, um nach weiteren Fehlern zu suchen und diese dem Anwendungsprogramm zu melden. Um die Fehlerkorrektur zu unterstützen, darf der Prozessor nichtverarbeitete Daten des Dokuments (mit vermischtem Text und Markup) dem Anwendungsprogramm zur Verfügung stellen. Wenn ein kritischer Fehler aufgetreten ist, darf ein Prozessor die normale Verarbeitung nicht fortsetzen. Dies heißt insbesondere, daß er keine weiteren Daten oder Informationen über die logische Struktur des Dokuments an das Anwendungsprogramm weiterleiten darf, wie es normalerweise geschieht.

benutzeroptional (at user option)

Konforme Software darf oder muß (in Abhängigkeit von dem Modalverb im Satz) sich so verhalten wie beschrieben. Sie muß dem Benutzer eine Möglichkeit einräumen, das beschriebene Verhalten ein- oder auszuschalten.

Gültigkeitsbeschränkung (validity constraint)

Eine Regel, die für alle gültigen XML-Dokumente gilt. Verletzungen von Gültigkeitsbeschränkungen sind Fehler. Sie müssen benutzeroptional von validierenden XML-Prozessoren gemeldet werden.

Wohlgeformtheitsbeschränkung (well-formedness constraint)

Eine Regel, die für alle wohlgeformten XML-Dokumente gilt. Verletzungen von Wohlgeformtheitsbeschränkungen sind kritische Fehler.

passen (match)

• (Strings oder Namen:) Zwei Zeichenketten oder Namen, die verglichen werden, müssen identisch sein. Zeichen mit mehreren möglichen Repräsentationen in ISO/IEC 10646 (zum Beispiel Zeichen in einer geschlossenen Form und einer Form, die aus einem Grundzeichen und einem diakritischen Zeichen zusammengesetzt wird) passen nur, wenn sie die gleiche Repräsentation in beiden Zeichenketten haben. Benutzeroptional darf ein XML-Prozessor solche Zeichen in eine kanonische Form normalisieren. Es wird keine Umwandlung zwischen Groß- und Kleinschreibung durchgeführt.
• (Strings und Regeln in der Grammatik:) Ein String paßt zu einer grammatikalischen Produktion, wenn er zur Sprache gehört, die durch die Produktion erzeugt wird.
• (Inhalt und Inhaltsmodelle:) Ein Element paßt zu seiner Deklaration, wenn es in der Weise konform ist, die in der Gültigkeitsbeschränkung »gültiges Element« beschrieben ist.

zwecks Kompatibilität (for compatibility)

Eine Eigenschaft von XML, die einzig zu dem Zweck eingeführt wurde, daß XML mit SGML kompatibel bleibt.

zwecks Zusammenarbeit (for interoperability)

Eine unverbindliche Empfehlung, die dazu dient, die Wahrscheinlichkeit zu erhöhen, daß XML-Dokumente von existierenden SGML-Prozessoren verarbeitet werden können, die älter sind als der »WebSGML Adaptions Annex«.

2 Dokumente

Ein Datenobjekt ist ein XML-Dokument, wenn es im Sinne dieser Spezifikation wohlgeformt ist. Ein wohlgeformtes XML-Dokument kann darüber hinaus gültig sein, sofern es bestimmten weiteren Einschränkungen genügt.

Jedes XML-Dokument hat sowohl eine »logische« als auch eine »physikalische Struktur«. Physikalisch besteht das Dokument aus einer Reihe von Einheiten, genannt Entities. Ein Entity kann auf andere Entities verweisen, um sie in das Dokument einzubinden. Jedes Dokument beginnt in einer »Wurzel-« oder »Dokument-Entity«. Aus logischer Sicht besteht das Dokument aus Deklarationen, Elementen, Kommentaren, Zeichenreferenzen und Processing Instructions, die innerhalb des Dokuments durch explizites Markup ausgezeichnet sind. Logische und physikalische Strukturen müssen korrekt verschachtelt sein, wie in 4.3.2 beschrieben.

2.1 Wohlgeformte XML-Dokumente

Ein textuelles Objekt ist ein wohlgeformtes XML-Dokument, wenn

1. es als Gesamtheit betrachtet zu der mit document bezeichneten Produktion paßt,
2. es alle Wohlgeformtheitsbeschränkungen dieser Spezifikation erfüllt und
3. jedes seiner parsed Entities, welches direkt oder indirekt referenziert wird, wohlgeformt ist.

Daß ein Dokument zur document-Produktion paßt, impliziert:

1. Es enthält ein oder mehrere Elemente.
2. Es existiert genau ein Element, genannt Wurzel oder Dokument-Element, von dem kein Teil im Inhalt eines anderen Elements enthalten ist. Für alle anderen Elemente gilt: Wenn das Start-Tag im Inhalt eines anderen Elements ist, dann auch das End-Tag. Einfacher ausgedrückt: Die Elemente, begrenzt durch Start- und End-Tag, sind korrekt ineinander verschachtelt.

Als eine Konsequenz daraus gilt, daß für jedes Element k, das nicht die Wurzel ist, ein anderes Element v existiert, so daß sich k im Inhalt von v befindet, aber nicht im Inhalt eines anderen Elements, das sich im Inhalt von v befindet. V heißt Vater² von k und k heißt Kind von v.

2.2 Zeichen

Ein analysiertes Entity enthält Text, eine Folge von Zeichen, die entweder Markup oder Zeichendaten darstellen. Ein Zeichen (character) ist eine atomare Einheit von Text gemäß der Spezifikation in ISO/IEC 10646. Gültige Zeichen sind Tab (Tabulator), Carriage Return (Wagenrücklauf), Line Feed (Zeilenvorschub) sowie die Grafikzeichen von Unicode und ISO/IEC 10646. Von der Verwendung von »Kompatibilitätszeichen« (compatibility characters), wie sie in Abschnitt 6.8 von [Unicode] definiert werden, wird abgeraten.

Der Mechanismus zur Kodierung von Zeichen in Bitmustern darf von Entity zu Entity variieren. Alle XML-Prozessoren müssen die Kodierungen UTF-8 und UTF-16 aus ISO/IEC 10646 akzeptieren. Die Möglichkeiten zur Deklaration, welche der beiden Kodierungen verwendet wird, sowie die Verwendung von anderen Kodierungen werden später, in 4.3.3, behandelt.

2.3 Allgemeine syntaktische Konstrukte

Dieser Abschnitt definiert einige Symbole, die innerhalb der Grammatik häufig Verwendung finden.

S (Leerraum, White Space) besteht aus einem oder mehreren Leerzeichen (#x20), Wagenrückläufen, Zeilenvorschüben oder Tabulatoren.

Zeichen sind aus Gründen der Bequemlichkeit als Buchstaben, Ziffern und andere Zeichen klassifiziert. Buchstaben bestehen aus einem führenden alphabetischen oder Silbenzeichen, möglicherweise gefolgt von einem oder mehreren kombinierenden Zeichen oder von einem ideographischen Zeichen. Die vollständige Definition der einzelnen Zeichen in jeder Klasse ist in 8 aufgeführt.

Ein Name ist ein Token³, das mit einem Buchstaben (letter) oder einem erlaubten Interpunktionszeichen beginnt, woran sich Buchstaben, Ziffern (digit), Bindestriche, Unterstriche, Doppelpunkte oder Punkte anschließen. Letztere sind als Name-Zeichen bekannt. Namen, die mit »xml« oder mit einer Zeichenkette beginnen, die zu (('X'|'x') ('M'|'m') ('L'|'l')) paßt, sind für die Standardisierung in dieser oder einer zukünftigen Version dieser Spezifikation reserviert.

Hinweis: Der Doppelpunkt ist innerhalb von XML-Namen für Experimente mit Namensräumen reserviert. Es ist zu erwarten, daß seine Bedeutung irgendwann in der Zukunft standardisiert wird. Es könnte dann notwendig sein, Dokumente, die mit dem Doppelpunkt experimentieren, zu aktualisieren. (Es gibt keine Garantie, daß ein Mechanismus für Namensräume in XML tatsächlich den Doppelpunkt als Trennzeichen für Namensräume verwendet.) Praktisch bedeutet das, daß Autoren den Doppelpunkt in XML-Namen außer zu Namensraum-Versuchen nicht einsetzen sollten, daß aber XML-Prozessoren den Doppelpunkt als Name-Zeichen akzeptieren sollten.

Ein Nmtoken (Name Token) ist eine beliebige Kombination von Name-Zeichen.

Ein Literal ist eine beliebige, in Anführungszeichen⁴ eingeschlossene Zeichenkette, die nicht das Anführungszeichen enthält, das zur Begrenzung der Zeichenkette verwendet wird. Literale werden verwendet, um den Inhalt von internen Entities (EntityValue), die Werte von Attributen (AttValue) und um externe Bezeichner (SystemLiteral) anzugeben. Beachten Sie, daß ein SystemLiteral analysiert (parsed) werden kann, ohne nach Markup zu suchen.

2.4 Zeichendaten und Markup

Text besteht aus miteinander vermengten Zeichendaten und Markup. Markup besteht aus Start-Tags, End-Tags, Tags für leere Elemente, Entity-Referenzen, Zeichenreferenzen, Kommentaren, Begrenzungen für CDATA-Abschnitte, Dokumenttyp-Deklarationen und Processing Instructions.

Sämtlicher Text, der kein Markup ist, bildet die Zeichendaten des Dokuments.

Das et-Zeichen (&) und die öffnende spitze Klammer (<) dürfen in ihrer literalen Form ausschließlich als Markup-Begrenzungen, innerhalb eines Kommentars, einer Processing Instruction oder eines CDATA-Abschnitts benutzt werden. Sie sind außerdem innerhalb des literalen Werts einer internen Entity-Deklaration zulässig, siehe 4.3.2. Falls sie an anderer Stelle benötigt werden, müssen sie geschützt (escaped) werden. Dies kann durch eine numerische Zeichenreferenz oder die Zeichenketten &amp; (Ampersand, et-Zeichen) bzw. &lt; (kleiner-als, less-than) geschehen. Die schließende spitze Klammer (>) kann durch die Zeichenkette &gt; (größer-als, greater-than) dargestellt werden. Sie muß zwecks Kompatibilität durch &gt; oder eine Zeichenreferenz geschützt werden, falls sie in der Zeichenkette ]]> an einer Stelle auftritt, an der diese Zeichenkette nicht das Ende eines CDATA-Abschnitts markiert.

Innerhalb des Inhalts eines Elements ist jede Folge von Zeichen, die keine Anfangsbegrenzung von irgendeiner Form von Markup enthalten, Teil der Zeichendaten. Innerhalb eines CDATA-Abschnitts ist jede Folge von Zeichen, die nicht den CDATA-Abschluß ]]> enthält, Teil der Zeichendaten.

Um Attributwerten zu erlauben, sowohl das einfache als auch das doppelte Anführungszeichen zu enthalten, kann das Apostroph (') als &apos; und das doppelte Anführungszeichen (") als &quot; dargestellt werden.

2.5 Kommentare

Kommentare dürfen innerhalb des Dokuments an beliebiger Stelle außerhalb des übrigen Markup stehen. Darüber hinaus dürfen sie innerhalb der Dokumenttyp-Deklaration an den von der Grammatik erlaubten Stellen stehen. Sie sind kein Bestandteil der Zeichendaten eines Dokuments. Ein XML-Prozessor kann, muß aber nicht, der Anwendung eine Möglichkeit einräumen, den Text eines Kommentars zu lesen. Zwecks Kompatibilität darf die Zeichenkette »--« (zwei Trennstriche) nicht innerhalb eines Kommentars erscheinen.

Ein Beispiel für einen Kommentar

<!-- Deklaration für <head> & <body> -->

2.6 Processing Instructions

Processing Instructions (PIs) erlauben Dokumenten, Anweisungen für Anwendungsprogramme zu enthalten.

PIs sind kein Bestandteil der Zeichendaten des Dokuments, müssen jedoch an die Anwendung weitergereicht werden. Die PIs beginnen mit einem Ziel (PITarget), das dazu dient, die Anwendung zu identifizieren, an die sich die Anweisung richtet. Die Zielnamen XML, xml und so weiter sind für die Standardisierung in dieser oder einer zukünftigen Version dieser Spezifikation reserviert. Der XML-Notationsmechanismus darf für die formale Deklaration von PI-Zielen benutzt werden.

2.7 CDATA-Abschnitte

CDATA-Abschnitte dürfen überall dort stehen, wo auch Zeichendaten erlaubt sind. Sie dienen dazu, ganze Textblöcke zu schützen, die Zeichen enthalten, die normalerweise als Markup interpretiert würden. CDATA-Abschnitte beginnen mit der Zeichenkette <![CDATA[ und enden mit ]]>.

Innerhalb eines CDATA-Abschnittes wird ausschließlich CDEnd erkannt. Das heißt die öffnende spitze Klammer und das et-Zeichen dürfen in ihrer literalen Form erscheinen. Sie müssen (und können) nicht mit &lt; bzw. &amp; geschützt werden. CDATA-Abschnitte können nicht verschachtelt werden.

Folgendes Beispiel zeigt einen CDATA-Abschnitt, in dem <gruss> und </gruss> als Zeichendaten und nicht als Markup erkannt werden.

<![CDATA[<gruss>Hallo Welt!</gruss>]]>

2.8 Prolog und Dokumenttyp-Deklaration

XML-Dokumente können und sollten mit einer XML-Deklaration beginnen, die die verwendete XML-Version spezifiziert. Beispielsweise sind die folgenden Zeilen ein vollständiges XML-Dokument, wohlgeformt, aber nicht gültig.

<?xml version="1.0"?>
<gruss>Hallo Welt!</gruss>

<gruss>Hallo Welt!</gruss>

Die Versionsnummer »1.0« sollte benutzt werden, um Konformität zu dieser Version der Spezifikation anzuzeigen. Es ist ein Fehler, wenn ein Dokument den Wert »1.0« benutzt und nicht konform zu dieser Version der Spezifikation ist. Es ist die Absicht der XML-Arbeitsgruppe, späteren Versionen dieser Spezifikation andere Nummern als »1.0« zu geben. Diese Absichtserklärung ist jedoch kein Versprechen, irgendwelche weiteren Versionen von XML zu erstellen, noch, falls es weitere gibt, irgendein bestimmtes Numerierungsschema zu verwenden. Da zukünftige Versionen nicht ausgeschlossen sind, wurde die Deklaration eingeführt, um die Möglichkeit der automatischen Versionserkennung zu erlauben, sofern dies notwendig werden sollte. Prozessoren dürfen einen Fehler anzeigen, wenn sie ein Dokument einer Version bekommen, die sie nicht unterstützen.

Die Funktion des Markup in einem XML-Dokument ist es, die Aufteilung auf Speicherungseinheiten und die logische Struktur zu beschreiben sowie Attribut-Wert-Paare mit der logischen Struktur zu verbinden. XML stellt einen Mechanismus zur Verfügung, die Dokumenttyp-Deklaration, um Beschränkungen der logischen Struktur zu definieren und die Verwendung von vordefinierten Speichereinheiten zu unterstützen. Ein XML-Dokument ist gültig, wenn es eine dazugehörige Dokumenttyp-Deklaration besitzt und wenn sich das Dokument an die darin formulierten Beschränkungen hält.

Die Dokumenttyp-Deklaration muß vor dem ersten Element im Dokument stehen.

Die XML-Dokumenttyp-Deklaration enthält oder verweist auf Markup-Deklarationen, die eine Grammatik für eine Klasse von Dokumenten bilden. Diese Grammatik ist bekannt als Dokumenttyp-Definition, kurz DTD. Die Dokumenttyp-Deklaration kann entweder auf eine externe Teilmenge (eine besondere Art eines externen Entity) verweisen, die Markup-Deklarationen enthält, oder sie kann Markup-Deklarationen direkt in einer internen Teilmenge enthalten oder beides. Die DTD für ein Dokument besteht aus beiden Teilmengen zusammen.

Eine Markup-Deklaration ist eine Elementtyp-Deklaration, eine Attributlisten-Deklaration oder eine Notation-Deklaration. Diese Deklarationen dürfen ganz oder teilweise innnerhalb von Parameter-Entities stehen, wie in den Wohlgeformtheits- und Gültigkeitsbeschränkungen unten beschrieben. Für vollständigere Informationen siehe Abschnitt 4.

Die Markup-Deklarationen dürfen ganz oder teilweise durch den Ersetzungstext von Parameter-Entities gebildet werden. Die Produktionen für einzelne Nicht-Terminale (elementdecl, AttlistDecl usw.), die später in dieser Spezifikation folgen, beschreiben die Deklarationen, nachdem sämtliche Parameter-Entities aufgelöst wurden.

Gültigkeitsbeschränkung: Wurzel-Elementtyp
Der Name in der Dokumenttyp-Deklaration muß mit dem Elementtyp des Wurzel-Elements übereinstimmen.

Gültigkeitsbeschränkung: Ordentliche Deklaration/PE-Verschachtelung
Der Ersetzungstext von Parameter-Entities muß ordentlich mit Markup-Deklarationen verschachtelt sein. Das heißt: wenn entweder das erste oder das letzte Zeichen einer Markup-Deklaration (markupdecl, siehe oben) im Ersetzungstext für eine Parameter-Entity-Referenz enthalten ist, dann müssen beide im selben Ersetzungstext enthalten sein.

Wohlgeformtheitsbeschränkung: PEs in interner Teilmenge
Im internen Teil der DTD können Parameter-Entity-Referenzen nur dort stehen, wo auch Markup-Deklarationen stehen können, nicht jedoch innerhalb von Markup-Deklarationen. (Dies gilt nicht für Referenzen, die in externen Parameter-Entities erscheinen oder für die externe Teilmenge.

Wie die interne Teilmenge so muß auch die externe Teilmenge und jedes externe Parameter-Entity, auf das die DTD Bezug nimmt, aus einer Folge von vollständigen Markup-Deklarationen des Typs bestehen, der durch das Nicht-Terminal markupdecl erlaubt wird, vermengt mit Leerraum (White Space) oder Parameter-Entity-Referenzen. Allerdings dürfen Teile des Inhalts der externen Teilmenge oder von externen Parameter-Entities unter Verwendung von bedingten Abschnitten ignoriert werden. Dies ist innerhalb der internen Teilmenge nicht erlaubt.

Die externe Teilmenge und externe Parameter-Entities unterscheiden sich darüber hinaus von der internen Teilmenge dadurch, daß Parameter-Entity-Referenzen innerhalb von Markup-Deklarationen erlaubt sind, nicht nur zwischen Markup-Deklarationen.

Ein Beispiel:

<?xml version="1.0"?>
<!DOCTYPE gruss SYSTEM "hallo.dtd">
<gruss>Hallo Welt!</gruss>

Der System-Identifier hallo.dtd gibt den URI einer DTD für das Dokument an.

Die Deklaration kann auch lokal angegeben werden, wie in folgendem Beispiel.

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

Wenn sowohl die externe als auch die interne Teilmenge verwendet werden, sollte die interne Teilmenge vor der externen Teilmenge stehen. Dies hat den Effekt, daß Entity- und Attributlisten-Deklarationen in der internen Teilmenge Vorrang vor jenen in der externen Teilmenge haben.

2.9 Standalone-Dokumentdeklaration

Markup-Deklarationen können den Inhalt eines Dokuments beeinflussen, wie er von einem XML-Prozessor an eine Anwendung weitergereicht wird. Beispiele sind Vorgaben für Attributwerte sowie Entity-Deklarationen. Die Standalone-Dokumentdeklaration (engl. alleinstehend), die als Teil der XML-Deklaration erscheinen darf, zeigt an, ob es Deklarationen gibt, die außerhalb des Dokumentes stehen.

In einer Standalone-Dokumentdeklaration zeigt der Wert »yes« (Ja), daß es keine Markup-Deklarationen außerhalb des Dokuments gibt (weder in der externen Teilmenge der DTD noch in einem externen Parameter-Entity, auf die von der internen Teilmenge verwiesen wird), die die Informationen beeinflussen, die vom XML-Prozessor an die Anwendung weitergereicht werden. Der Wert »no« (Nein) zeigt an, daß möglicherweise solche externen Markup-Deklarationen vorhanden sind. Beachten Sie, daß die Standalone-Dokumentdeklaration lediglich anzeigt, ob es externe Deklarationen gibt. Das Vorhandensein von Referenzen auf externe Entities in einem Dokument, die intern deklariert sind, ändert den Standalone-Status nicht.

Wenn es keine externen Markup-Deklarationen gibt, hat die Standalone-Dokumentdeklaration keine Bedeutung. Wenn es externe Markup-Deklarationen gibt, jedoch keine Standalone-Dokumentdeklaration vorhanden ist, wird der Wert »no« angenommen.

Ein XML-Dokument, für das standalone="no" gilt, kann algorithmisch in ein Standalone-Dokument konvertiert werden, was für netzweite Anwendungen wünschenswert sein kann.

Gültigkeitsbeschränkung: Standalone-Dokumentdeklaration
Die Standalone-Dokumentdeklaration muß den Wert »no« haben, falls eine externe Markup-Deklaration eine der folgenden Deklarationen enthält:

• Attribute mit einem Vorgabewert (Default), falls Elemente, für die diese Attribute gelten, im Dokument erscheinen, ohne daß Werte für diese Attribute angegeben wurden
• andere Entities als amp, lt, gt, apos, quot, falls Referenzen zu solchen Entities im Dokument erscheinen
• Attribute mit Werten, die normalisiert werden, wobei das Attribut im Dokument mit einem Wert erscheint, der sich durch die Normalisierung ändert
• Elementtypen, deren Inhalt weitere Elemente enthält, falls Leerraum (White Space) direkt innerhalb einer Instanz solcher Typen erscheint

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

2.10 Behandlung von Leerraum

Bei dem Editieren von XML-Dokumenten ist es oft angenehm, Leerraum (White Space; Leerzeichen (spaces), Tabulatoren, Leerzeilen; innerhalb dieser Spezifikation mit dem Nicht-Terminal S bezeichnet) zu verwenden, um das Markup für eine bessere Lesbarkeit voneinander abzusetzen. Dieser Leerraum soll üblicherweise beim Versenden des Dokuments nicht erhalten bleiben. Auf der anderen Seite gibt es häufig »signifikanten« Leerraum, der auch beim Versenden erhalten bleiben soll, beispielsweise in Gedichten und Quellcode.

Ein XML-Prozessor muß stets alle Zeichen in einem Dokument, die nicht zum Markup gehören, an die Anwendung weiterreichen. Ein validierender XML-Prozessor muß die Anwendung außerdem darüber informieren, welche Leerraumzeichen im Inhalt eines Elements stehen.

Ein besonderes Attribut namens xml:space kann einem Element zugewiesen werden, um anzuzeigen, daß Leerraum in diesem Element von Anwendungen erhalten werden soll. In gültigen Dokumenten muß dieses Attribut, wie jedes andere, deklariert werden. Bei der Deklaration muß es als Aufzählungstyp, dessen einzige Werte »default« (Vorgabe) und »preserve« (Erhalten) sind, geschrieben werden. Zum Beispiel:

<!ATTLIST gedicht   xml:space (default|preserve) 'preserve'>

Der Wert »default« zeigt an, daß die normale Leerraumbehandlung einer Anwendung für dieses Element akzeptabel ist. Der Wert »preserve« zeigt die Absicht an, daß Anwendungen sämtlichen Leerraum erhalten. Diese erklärte Absicht gilt für alle Elemente innerhalb des Elements, für das »preserve« angegeben wurde, es sei denn, es ist für ein eingebettetes Element explizit mit dem Attribut xml:space überschrieben worden.

Vom Wurzelelement eines beliebigen Dokuments wird angenommen, daß es keine Leerraumbehandlung der Anwendung vorsieht, es sei denn, es gibt einen Wert für dieses Attribut vor -- oder das Attribut ist mit einem Vorgabewert deklariert.

2.11 Behandlung des Zeilenendes

Analysierte (parsed) XML-Entities sind oft in Dateien abgelegt, die, zur leichteren Änderbarkeit, in Zeilen unterteilt sind. Diese Zeilen sind üblicherweise durch Kombinationen der Zeichen Wagenrücklauf (carriage-return, #xD) und Zeilenvorschub (line-feed, #xA) getrennt.

Um die Aufgabe von Anwendungen zu erleichtern, muß ein XML-Prozessor das einzelne Zeichen #xA an die Anwendung weiterreichen, wo immer ein externes analysiertes Entity oder der literale Entity-Wert eines internen analysierten Entity entweder die literale Zweizeichenfolge #xD#xA oder ein einzelnes Literal #xD enthält. (Dieses Verhalten läßt sich angenehmerweise erreichen, indem man alle Zeilenumbrüche beim Lesen vor dem Analysieren zu #xA normalisiert.)

2.12 Identifikation der Sprache

In der Dokumentenverarbeitung ist es oft nützlich, die natürliche oder formale Sprache, in der der Inhalt geschrieben ist, zu identifizieren. Ein besonderes Attribut namens xml:lang kann in Dokumente eingefügt werden, um die für den Inhalt oder für die Attributwerte von beliebigen Elementen verwendete Sprache anzugeben. In gültigen Dokumenten muß dieses Attribut, wie jedes andere, deklariert werden. Die Werte dieses Attributs sind Sprachencodes gemäß Definition in [IETF RFC 1766]:

Der Langcode ist etwas folgender Art:

• ein Zwei-Buchstaben Sprachencode gemäß [ISO 639]
• ein Sprachencode, der bei der Internet Assigned Numbers Authority [IANA] registriert ist; sie beginnen mit dem Präfix »i-« oder »I-«.
• ein Sprachencode, den der Benutzer selbst vergeben hat oder der zwischen zwei Parteien zum privaten Gebrauch vereinbart wurde; diese Codes müssen mit dem Präfix »x-« oder »X-« beginnen, um Konflikte mit Namen zu vermeiden, die später standardisiert oder bei der IANA registriert werden.

Es dürfen beliebig viele Subcode-Segmente existieren. Falls das erste Subcode-Segment vorhanden ist und aus zwei Buchstaben besteht, dann muß es ein Ländercode aus [ISO 3166] sein. Falls der erste Subcode aus mehr als zwei Buchstaben besteht, dann muß es ein bei der IANA registrierter Subcode für die fragliche Sprache sein; es sei denn, Langcode beginnt mit einem »x-« oder »X-«.

Es ist üblich, den Sprachencode in Kleinbuchstaben und den Ländercode (falls vorhanden) in Großbuchstaben anzugeben. Beachten Sie, daß diese Werte, anders als andere Namen in XML-Dokumenten, von der Groß/Kleinschreibung unabhängig sind.

Ein Beispiel:

<p xml:lang="en">The quick brown fox jumps over the lazy dog.</p>
<p xml:lang="de-DE">In welcher Straße hast du geparkt?</p>
<p xml:lang="de-CH">In welcher Strasse hast du parkiert?</p>
<sp who="Faust" desc='leise' xml:lang="de">
    <l>Habe nun, ach! Philosophie,</l>
    <l>Juristerei, und Medizin</l>
    <l>und leider auch Theologie</l>
    <l>durchaus studiert mit heißem Bemüh'n.</l>
    </sp>

Die mit xml:lang gemachte Deklaration wird auf alle Attribute und den Inhalt des Elementes angewandt, für das xml:lang spezifiziert wurde. Innerhalb des Inhalts kann ein weiteres Attribut xml:lang dieses Verhalten für ein eingebettetes Element überschreiben.

Eine einfache Deklaration für xml:lang kann folgende Form annehmen:

xml:lang  NMTOKEN  #IMPLIED

Es können auch Vorgabewerte -- falls sinnvoll -- angegeben werden. In einer Sammlung von französischen Gedichten für deutschsprachige Studenten mit Erläuterungen und Bemerkungen in Deutsch kann die Deklaration für das xml:lang-Attribut etwa folgendermaßen aussehen:

<!ATTLIST gedicht       xml:lang NMTOKEN 'fr'>
<!ATTLIST erlaeuterung  xml:lang NMTOKEN 'de'>
<!ATTLIST bemerkung     xml:lang NMTOKEN 'de'>

3 Logische Strukturen

Jedes XML-Dokument enthält ein oder mehrere Elemente, die entweder durch Start- und End-Tags oder, im Falle eines leeren Elements, durch ein Leeres-Element-Tag begrenzt sind. Jedes Element hat einen Typ, der durch einen Namen, auch »generic identifier« (GI) genannt, identifiziert wird, und es kann auch eine Menge von Attributspezifikationen haben. Jede Attributspezifikation hat einen Namen und einen Wert.

Diese Spezifikation macht keine Einschränkungen hinsichtlich Semantik, Verwendung, Benennung (abgesehen von der Syntax) von Elementtypen und Attributen, mit der Ausnahme, daß Namen, deren Anfang zu (('X'|'x')('M'|'m')('L'|'l')) paßt, für die Standardisierung in dieser oder einer zukünftigen Verision dieser Spezifikation reserviert sind.

Wohlgeformtheitsbeschränkung: Elementtyp-Übereinstimmung
Der Name im End-Tag eines Elements muß mit dem Elementtyp im Start-Tag übereinstimmen.

Gültigkeitsbeschränkung: gültiges Element
Ein Element ist gültig, wenn es eine Deklaration gibt, die zu elementdecl paßt, wobei der Name zu dem Elementtyp paßt und eine der folgenden Bedingungen gilt:

1. Die Deklaration paßt zu EMPTY, und das Element hat keinen Inhalt.
2. Die Deklaration paßt zu children, und die Folge der Kind-Elemente gehört zu der Sprache, die durch den regulären Ausdruck im Inhaltsmodell generiert wird, mit optionalem Leerraum (Zeichen, die zu dem Nicht-Terminal S passen) zwischen jedem Paar von Kind-Elementen.
3. Die Deklaration paßt zu Mixed, und der Inhalt besteht aus Zeichendaten und Kind-Elementen, deren Typen zu den Namen im Inhaltsmodell passen.
4. Die Deklaration paßt zu Any, und die Typen aller Kind-Elemente sind deklariert worden.

3.1 Start-Tags, End-Tags und Leeres-Element-Tags

Der Beginn jedes nicht-leeren XML-Elements ist durch ein Start-Tag markiert.

Der Name in den Start- und End-Tags ist der Typ des Elements. Die Name-AttValue-Paare werden als Attribut-Spezifikation des Elements bezeichnet, wobei der Name in jedem Paar der Attribut-Name und der Inhalt des AttValue (der Text zwischen den '- oder "-Zeichen) der Attribut-Wert ist.

Wohlgeformtheitsbeschränkung: Eindeutige Attributspezifikation
Kein Attributname darf mehr als einmal in demselben Start-Tag oder Leeres-Element-Tag erscheinen.

Gültigkeitsbeschränkung: Typ des Attributwertes
Das Attribut muß deklariert worden sein. Der Wert muß von dem Typ sein, der für ihn deklariert wurde (siehe dazu 3.3).

Wohlgeformtheitsbeschränkung: Keine externen Entity-Referenzen
Attributwerte können weder direkte noch indirekte Entity-Referenzen auf externe Entities enthalten.

Wohlgeformtheitsbeschränkung: Kein < in Attribut-Werten
Der Ersetzungstext eines Entities, auf das direkt oder indirekt in einem Attributwert verwiesen wird, darf kein < enthalten (außer &lt;).

Ein Beispiel für einen Start-Tag:

<termdef id="dt-hund" term="hund">

Das Ende jedes Elements, das mit einem Start-Tag beginnt, muß mit einem End-Tag markiert werden. Dieses muß einen Namen enthalten, der den Elementtyp wiederholt, wie er vom Start-Tag vorgegeben wurde.

Ein Beispiel eines End-Tags:

</termdef>

Der Text zwischen Start- und End-Tag wird der Inhalt des Elements genannt.

Wenn ein Element leer (empty) ist, dann muß es entweder durch einen Start-Tag, auf den unmittelbar ein End-Tag folgt, oder durch ein Leeres-Element-Tag dargestellt werden. Ein Leeres-Element-Tag hat eine besondere Form:

Leeres-Element-Tags können für jedes Element benutzt werden, das keinen Inhalt hat, unabhängig davon, ob es mit dem Schlüsselwort EMPTY deklariert wurde. Zwecks Zusammenarbeit muß (und kann nur) das Leeres-Element-Tag nur für Elemente verwendet werden, die als EMPTY deklariert wurden.

Beispiele für leere Elemente:

<IMG align="left" src="http://www.w3.org/Icons/WWW/w3c_home" />
<br></br>
<br/>

3.2 Elementtyp-Deklarationen

Die Element-Struktur eines XML-Dokuments kann zum Zwecke der Validierung durch Elementtyp- und Attributlisten-Deklarationen beschränkt werden. Eine Elementtyp-Deklaration beschränkt den Inhalt eines Elements.

Elementtyp-Deklarationen beschränken oft, welche Elementtypen als Kinder des Elements erscheinen können. Benutzeroptional kann ein XML-Prozessor eine Warnung ausgeben, falls eine Deklaration einen Elementtyp nennt, für den es keine Deklaration gibt. Dies ist aber kein Fehler.

Eine Elementtyp-Deklaration hat folgende Form:

Hierbei bezeichnet Name den zu deklarierenden Elementtyp.

Gültigkeitsbeschränkung: Eindeutige Elementtyp-Deklarationen
Kein Elementtyp darf mehr als einmal deklariert werden.

Beispiel für Elementtyp-Deklarationen:

<!ELEMENT br EMPTY>
<!ELEMENT p (#PCDATA|emph)* >
<!ELEMENT %name.para; %content.para; >
<!ELEMENT container ANY>

3.2.1 Element-Inhalt

Ein Elementtyp hat Element-Inhalt, wenn Elemente dieses Typs ausschließlich Kindelemente (keine Zeichendaten) enthalten dürfen, die optional durch Leerraum (Zeichen, die zu dem Nicht-Terminal S passen) unterteilt sind. In diesem Fall enthält die Beschränkung ein Inhaltsmodell, eine einfache Grammatik, die die erlaubten Typen der Kindelemente und die Reihenfolge, in der sie erscheinen dürfen, festlegt. Die Grammatik ist auf Inhaltsteilen (content particles, cps) aufgebaut, die aus Namen, Auswahllisten (choice) und Folgen (sequence) von Inhaltsteilen bestehen.

Hierbei ist Name der Typ eines Elements, das als Kind vorkommen darf. Jeder Inhaltsteil einer Auswahlliste kann im Elementinhalt an der Stelle stehen, an der die Auswahlliste in der Grammatik steht. Inhaltsteile in einer Folge müssen alle im Elementinhalt und in der vorgegebenen Reihenfolge erscheinen. Das optionale Zeichen, das auf einen Namen oder eine Liste folgt, legt fest, ob der Inhalt oder die Inhaltsteile in der Liste einmal oder mehrmals (+), keinmal oder mehrmals (*) oder keinmal oder einmal (?) auftreten dürfen. Das Fehlen eines solchen Operators bedeutet, daß das Element oder der Inhaltsteil genau einmal erscheinen muß. Diese Syntax und Bedeutung sind identisch zu denen, die in den Produktionen dieser Spezifikation Verwendung finden.

Der Inhalt eines Elements paßt zu einem Inhaltsmodell, dann und nur dann, wenn es möglich ist, unter Befolgung der Sequenz-, Auswahl- und Wiederholungsoperatoren einen Pfad durch das Inhaltsmodell zu finden, wobei jedes Element im Inhalt zu einem Elementtyp im Inhaltsmodell paßt. Zwecks Kompatibilität ist es ein Fehler, wenn ein Element im Dokument zu mehr als einem Elementtyp im Inhaltsmodell paßt. Für weitere Informationen siehe Abschnitt 11.

Gültigkeitsbeschränkung: Ordentliche Gruppierung/PE-Verschachtelung
Der Ersetzungstext von Parameter-Entities muß ordentlich mit geklammerten Gruppen verschachtelt sein. Das heißt: Wenn entweder die öffnende oder die schließende Klammer in einem choice-, seq- oder Mixed-Konstrukt im Ersetzungstext eines Parameter-Entity enthalten ist, dann müssen beide im selben Ersetzungstext enthalten sein. Zwecks Zusammenarbeit gilt: Wenn eine Parameter-Entity-Referenz in einem choice-, seq- oder Mixed-Konstrukt erscheint, dann sollte dessen Ersetzungstext nicht leer sein und weder das erste noch das letzte nicht-leere Zeichen (non-blank) des Ersetzungstextes sollte ein Konnektor (| oder ,) sein.

Beispiele für Modelle mit Element-Inhalt:

<!ELEMENT spec (front, body, back?)>
<!ELEMENT div1 (head, (p | list | note)*, div2*)>
<!ELEMENT dictionary-body (%div.mix; | %dict.mix;)*>

3.2.2 Gemischter Inhalt

Ein Element hat gemischten Inhalt, wenn Elemente dieses Typs Zeichendaten enthalten dürfen, die optional mit Kindelementen gemischt sind. In diesem Fall können die Typen der Kindelemente beschränkt werden, nicht jedoch ihre Reihenfolge oder ihre Anzahl.

wobei Name den Elementtyp bezeichnet, der als Kind erscheinen darf.

Gültigkeitsbeschränkung: Keine doppelten Typen
Derselbe Name darf nicht mehr als einmal in einer Deklaration von gemischtem Inhalt erscheinen.

Beispiel für Deklarationen von gemischtem Inhalt:

<!ELEMENT p (#PCDATA|a|ul|b|i|em)*>
<!ELEMENT p (#PCDATA | %font; | %phrase; | %special; | %form;)* >
<!ELEMENT b (#PCDATA)>

3.3 Attributlisten-Deklaration

Attribute werden verwendet, um Name-Wert-Paare mit Elementen zu verknüpfen. Attribut-Spezifikationen dürfen ausschließlich innerhalb von Start-Tags und Leeres-Element-Tags erscheinten. Folglich ist die Produktion zu deren Erkennung im Abschnitt 3.1 zu finden. Deklarationen von Attribut-Listen dürfen benutzt werden, um

• die Menge der Attribute zu definieren, die zu einem gegebenen Elementtyp gehören,
• Typbeschränkungen für diese Attribute aufzustellen und
• Vorgabewerte für Attribute anzugeben.

Attributlisten-Deklarationen spezifizieren den Namen, Datentyp und ggf. den Vorgabewert jedes Attributs, das zu einem gegebenen Element gehört:

Der Name in der AttlistDecl-Regel ist der Typ eines Elements. Benutzeroptional kann ein XML-Prozessor eine Warnung ausgeben, wenn Attribute für einen nicht deklarierten Elementtyp deklariert werden; dies ist jedoch kein Fehler. Der Name in der AttDef-Regel ist der Name des Attributs.

Falls mehr als eine AttlistDecl für ein gegebenes Element angegeben wird, werden sie alle vereinigt. Falls mehr als eine Definition für dasselbe Attribut eines gegebenen Elementtyps angegeben wird, so gilt zwingend die erste Deklaration, und alle weiteren werden ignoriert. Zwecks Zusammenarbeit können sich Verfasser von DTDs entscheiden, maximal eine Attributlisten-Deklaration für einen gegebenen Elementtyp, maximal eine Attributdefinition für einen gegebenen Attributnamen und mindestens eine Attributdefinition in jeder Attributlisten-Deklaration vorzusehen. Zwecks Zusammenarbeit kann ein XML-Prozessor benutzeroptional eine Warnung ausgeben, wenn mehr als eine Attributlisten-Deklaration für einen gegeben Elementtyp angegeben ist oder wenn mehr als eine Attributdefinition für ein gegebenes Attribut angegeben ist; dies ist jedoch kein Fehler.

3.3.1 Attribut-Typen

Es gibt drei Arten von XML-Attribut-Typen: einen Zeichenketten-Typ (string), eine Menge von Token-Typen (tokenized) und einen Aufzählungstyp (enumerated). Der Zeichenketten-Typ kann jede literale Zeichenkette als Wert aufnehmen. Der Token-Typ hat verschiedene lexikalische und semantische Beschränkungen:

Gültigkeitsbeschränkung: ID
Werte des Typs ID müssen zur Produktion Name passen. Ein Name darf nicht mehr als einmal als Wert dieses Typs in einem XML-Dokument erscheinen. Das heißt, ID-Werte müssen die Elemente, die sie tragen, eindeutig identifizieren.

Gültigkeitsbeschränkung: Eine ID pro Elementtyp
Kein Elementtyp darf mehr als ein ID-Attribut besitzen.

Gültigkeitsbeschränkung: Vorgabe für ID-Attribute
Ein ID-Attribut muß einen deklarierten Vorgabewert von #IMPLIED oder #REQUIRED haben.

Gültigkeitsbeschränkung: IDREF
Werte des Typs IDREF müssen zur Produktion Name passen, und Werte des Typs IDREFS müssen zur Produktion Names passen. Jeder Name muß mit dem Wert eines ID-Attributs eines Elements im XML-Dokument übereinstimmen. Das heißt, IDREF-Werte müssen zum Wert irgendeines ID-Attributs passen.

Gültigkeitsbeschränkung: Entity-Name
Werte des Typs ENTITY müssen zur Produktion Name passen, Werte des Typs ENTITIES müssen zur Produktion Names passen. Jeder Name muß mit dem Namen eines in der DTD deklarierten, nicht analysierten (unparsed) Entity übereinstimmen.

Gültigkeitsbeschränkung: Name-Token
Werte des Typs NMTOKEN müssen zur Produktion Nmtoken passen, Werte des Typs NMTOKENS müssen zur Produktion Nmtokens passen.

Aufzählungs-Attributtypen können einen Wert aus einer deklarierten Liste von Werten annehmen. Es gibt zwei Arten von Aufzählungstypen:

Ein NOTATION-Attribut identifiziert eine Notation, die in der DTD mit einem zugehörigen System- und/oder Public-Identifier deklariert ist. Die Notation dient dazu, das Element mit diesem Attribut zu interpretieren.

Gültigkeitsbeschränkung: Notation-Attribute
Werte dieses Typs müssen zu einem der Notation-Namen passen, die in der Deklaration enthalten sind. Alle Notation-Namen in der Deklaration müssen deklariert sein.

Gültigkeitsbeschränkung: Aufzählung
Werte dieses Typs müssen zu einem der Nmtoken-Token aus der Deklaration passen.

Zwecks Zusammenarbeit sollte jedes Nmtoken nicht mehr als einmal in den Aufzählungsattributen eines einzelnen Elementes vorkommen.

3.3.2 Attribut-Vorgaben

Eine Attribut-Deklaration enthält Informationen, ob ein Attribut vorkommen muß und, falls nicht, wie ein XML-Prozessor bei einem im Dokument fehlenden Attribut reagieren sollte.

In einer Attribut-Deklaration bedeutet #REQUIRED (notwendig), daß das Attribut immer angegeben werden muß und #IMPLIED (impliziert), daß es keinen Vorgabewert gibt. Wenn die Deklaration weder #REQUIRED noch #IMPLIED ist, enthält der AttValue-Wert den deklarierten Vorgabe-Wert. Das Schlüsselwort #FIXED (fest) zeigt an, daß das Attribut stets den Vorgabewert haben muß. Falls ein Vorgabewert deklariert ist, verhält sich ein XML-Prozessor bei einem weggelassenen Attribut so, als ob das Attribut mit dem Vorgabewert im Dokument stünde.

Gültigkeitsbeschränkung: Notwendiges Attribut
Falls die Attribut-Vorgabe das Schlüsselwort #REQUIRED ist, so muß das Attribut für alle Elemente des in der Attributlisten-Deklaration genanten Typs angegeben werden.

Gültigkeitsbeschränkung: korrekte Attribut-Vorgabe
Der deklarierte Vorgabewert muß den lexikalischen Beschränkungen des deklarierten Attribut-Typs genügen.

Gültigkeitsbeschränkung: Feste Attribut-Vorgabe
Wenn ein Attribut einen mit dem Schlüsselwort #FIXED deklarierten Vorgabewert besitzt, müssen alle Instanzen des Attributes den Vorgabewert besitzen.

Beispiel für Attributlisten-Deklarationen:

<!ATTLIST termdef
          id      ID      #REQUIRED
          name    CDATA   #IMPLIED>
<!ATTLIST list
          type    (bullets|ordered|glossary)  "ordered">
<!ATTLIST form
          method  CDATA   #FIXED "POST">

3.3.3 Normalisierung von Attribut-Werten

Bevor der Wert eines Attributs an die Anwendung weitergereicht oder auf Gültigkeit geprüft wird, muß der XML-Prozessor ihn folgendermaßen normalisieren:

• Im Falle einer Zeichenreferenz wird das referenzierte Zeichen an den Attribut-Wert angehängt.
• Im Falle einer Entity-Referenz wird der Ersetzungstext des Entity rekursiv verarbeitet.
• Im Falle eines Leerraum-Zeichens (whitespace character: #x20, #xD, #xA, #x9) wird #x20 an den normalisierten Wert angehängt. Eine Ausnahme ist die Sequenz »#xD#xA«, die Teil eines extern-analysierten (external parsed) Entity oder des literalen Werts eines intern analysierten (internal parsed) Entity ist. Für sie wird nur ein einziges #x20 angehängt.
• Andere Zeichen werden dem normalisierten Wert angehängt.

Falls der deklarierte Wert nicht CDATA ist, muß der XML-Prozessor den normalisierten Wert in folgender Weise weiterverarbeiten: Er entfernt alle führenden und abschließenden Leerzeichen (#x20) und ersetzt Folgen von Leerzeichen (#x20) durch ein einzelnes Leerzeichen (#x20).

Alle Attribute, für die keine Deklaration gelesen wurde, sollten von einem nicht-validierenden Parser behandelt werden, als ob sie als CDATA deklariert wären.

3.4 Bedingte Abschnitte

Bedingte Abschnitte sind Teile der externen Teilmenge der Dokumenttyp-Deklaration, die in Abhängigkeit von einem Schlüsselwort in die logische Struktur der DTD eingebunden oder von ihr ausgeschlossen sind.

So wie die internen und externen Teilmengen der DTD darf auch ein bedingter Abschnitt eine oder mehrere vollständige Deklarationen, Kommentare, Processing Instructions oder verschachtelte bedingte Abschnitte, vermischt mit Leerraum, enthalten.

Wenn das Schlüsselwort des bedingten Abschnitts INCLUDE heißt, dann wird der Inhalt des bedingten Abschnitts als Teil der DTD angesehen. Wenn das Schlüsselwort des bedingten Abschnitts IGNORE heißt, dann ist der Inhalt des bedingten Abschnitts kein logischer Teil der DTD. Beachten Sie, daß selbst der Inhalt von ignorierten bedingten Abschnitten für eine zuverlässige Analyse gelesen werden muß, um verschachtelte bedingte Abschnitte zu erkennen und um sicherzustellen, daß das Ende des äußeren (ignorierten) bedingten Abschnitts korrekt erkannt wird. Wenn ein bedingter Abschnitt mit dem Schlüsselwort INCLUDE innerhalb eines größeren bedingten Abschnitts mit dem Schlüsselwort IGNORE vorkommt, dann werden sowohl der innere als auch der äußere ignoriert.

Wenn das Schlüsselwort des bedingten Abschnitts ein Parameter-Entity ist, dann muß das Entity durch seinen Inhalt ersetzt werden, bevor der Prozessor entscheiden kann, ob er den bedingten Abschnitt ignoriert oder einbindet.

Ein Beispiel:

<!ENTITY % entwurf 'INCLUDE' >
<!ENTITY % fertig  'IGNORE' >
 
<![%entwurf;[
<!ELEMENT buch (kommentare*, titel, rumpf, anhaenge?)>
]]>
<![%fertig;[
<!ELEMENT buch (titel, rumpf, anhaenge?)>
]]>

4 Physikalische Strukturen

Ein XML-Dokument kann aus einer oder mehreren Speicherungseinheiten bestehen. Diese werden Entities genannt. Sie haben alle Inhalt und sind alle (abgesehen vom Dokument-Entity, s.u., und der externen Teilmenge der DTD) durch einen Namen identifiziert. Jedes XML-Dokument besitzt ein Entity namens Dokument-Entity, welches als Ausgangspunkt für den XML-Prozessor dient und das gesamte Dokument enthalten darf.

Entities dürfen entweder analysiert (parsed) oder nicht-analysiert (unparsed) sein. Der Inhalt eines analysierten Entity wird als sein Ersetzungstext bezeichnet. Dieser Text gilt als integraler Bestandteil des Dokuments.

Ein nicht-analysiertes Entity ist eine Ressource, deren Inhalt Text sein kann oder auch nicht, und falls es sich um Text handelt, nicht XML sein muß. Jedes nicht-analysierte Entity hat eine zugeordnete Notation, die durch ihren Namen identifiziert wird. XML erlegt dem Inhalt eines nicht-analysierten Entity keine Beschränkungen auf, es muß lediglich gewährleistet sein, daß der XML-Prozessor der Anwendung die Bezeichner für das Entity und für die Notation zur Verfügung stellt.

Analysierte Entities werden mit ihrem Namen durch Entity-Referenzen aufgerufen. Nicht-analysierte Entities werden mit ihrem Namen, der als Wert von ENTITY oder ENTITIES angegeben ist, aufgerufen.

Allgemeine Entities dienen der Verwendung innerhalb des Dokumentinhalts. In dieser Spezifikation werden allgemeine Entities oft unpräzise Entities genannt, sofern dies nicht zu Mehrdeutigkeit führt. Parameter-Entities sind analysierte Entities für die Benutzung innerhalb der DTD. Diese beiden Arten von Entities verwenden verschiedene Formen der Referenzierung und werden in unterschiedlichen Kontexten erkannt. Darüber hinaus belegen sie verschiedene Namensräume, d.h. ein Parameter-Entity und ein allgemeines Entity mit demselben Namen sind zwei verschiedenen Entities.

4.1 Zeichen- und Entity-Referenzen

Eine Zeichenreferenz verweist auf ein spezifisches Zeichen im Zeichensatz ISO/IEC 10646, etwa ein Zeichen, das auf dem Eingabegerät nicht direkt verfügbar ist.

Wohlgeformtheitsbeschränkung: Erlaubtes Zeichen
Zeichen, auf die mittels einer Zeichenreferenz verwiesen wird, müssen zu der Produktion für Char passen.

Wenn die Zeichenreferenz mit »&#x« beginnt, stellen die Ziffern und Buchstaben bis zum abschließenden ; die hexadezimale Darstellung des Zeichencodes in ISO/IEC 10646 dar. Wenn sie nur mit »&#« beginnt, stellen die Ziffern bis zum abschließenden ; die dezimale Darstellung des Zeichencodes dar.

Eine Entity-Referenz verweist auf den Inhalt eines benannten Entity. Referenzen zu analysierten allgemeinen Entities verwenden das et-Zeichen (&) und das Semikolon (;) als Begrenzungszeichen. Parameter-Entity-Referenzen verwenden das Prozentzeichen (%) und das Semikolon (;) als Begrenzungszeichen.

Wohlgeformtheitsbeschränkung: Entity deklariert
In einem Dokument ohne DTD, einem Dokument mit nur einer internen DTD-Teilmenge ohne Parameter-Entity-Referenzen oder einem Dokument mit »standalone='yes'« muß der Name in der Entity-Referenz zu dem in einer Entity-Deklaration passen. Eine Ausnahme ist, daß wohlgeformte Dokumente keine der folgenden Entities deklarieren müssen: amp, lt, gt, apos, quot. Die Deklaration eines Parameter-Entity muß vor einer Referenz darauf erfolgen. Auf ähnliche Weise muß die Deklaration eines allgemeinen Entity vor einer Referenz erfolgen, die im Vorgabewert in einer Attributlisten-Deklaration steht. Beachten Sie, daß im Fall von Entities, die in der externen Teilmenge oder in externen Parameter-Entities deklariert sind, ein nicht-validierender Parser nicht verpflichtet ist, deren Deklarationen zu lesen und zu verarbeiten. Für diese Dokumente gilt die Regel, daß ein Entity nur dann deklariert sein muß, wenn eine Wohlgeformtheitsbeschränkung standalone='yes' gilt.

Gültigkeitsbeschränkung: Entity deklariert
In einem Dokument mit einer externen Teilmenge oder externen Parameter-Entities mit »standalone='no'« muß der in der Entity-Referenz angegebene Name mit dem in der Deklaration übereinstimmen. Zwecks Zusammenarbeit sollten gültige Dokumente die Entities amp, lt, gt, apos, quot wie in 4.6 definieren. Die Deklaration eines Parameter-Entity muß vor einer Referenz darauf erfolgen. Auf ähnliche Weise muß die Deklaration eines allgemeinen Entity vor einer Referenz erfolgen, die im Vorgabewert in einer Attributlisten-Deklaration steht.

Wohlgeformtheitsbeschränkung: Analysiertes Entity
Eine Entity-Referenz darf keinen Namen eines nicht-analysierten Entity enthalten. Auf nicht-analysierte Entities darf nur in solchen Attribut-Werten verwiesen werden, die vom Typ ENTITY oder ENTITIES sind.

Wohlgeformtheitsbeschränkung: Keine Rekursion
Ein analysiertes Entity darf weder direkt noch indirekt eine rekursive Referenz auf sich selbst enthalten.

Wohlgeformtheitsbeschränkung: In der DTD
Parameter-Entity-Referenzen dürfen nur in der DTD erscheinen.

Beispiele für Zeichen- und Entity-Referenzen:

Drücke <taste>kleiner-als</taste> (&#x3C;), um die
Optionen zu speichern.
Dieses Dokument wurde am &dokdatum; erstellt und
ist als &sicherheits-stufe; klassifiziert.

Beispiel einer Parameter-Entity-Referenz:

<!-- Deklariere Parameter-Entity "ISOLat2"... -->
<!ENTITY % ISOLat2
         SYSTEM "http://www.xml.com/iso/isolat2-xml.entities" >
<!-- ... und nun verweise darauf. -->
%ISOLat2;

4.2 Entity-Deklarationen

Entities werden auf folgende Weise deklariert:

Der Name bezeichnet das Entity in einer Entity-Referenz oder, im Falle eines nicht-analysierten Entity, im Wert eines ENTITY- oder ENTITIES-Attributs. Wenn dasselbe Entity mehr als einmal deklariert wird, ist die erste Deklaration verbindlich. Benutzeroptional kann ein XML-Prozessor eine Warnung ausgeben, wenn Entities mehrfach deklariert sind.

4.2.1 Interne Entities

Wenn die Entity-Definition ein EntityValue ist, wird das definierte Entity internes Entity genannt. Es gibt keine separate Speicherungseinheit, der Inhalt des Entity ist in der Deklaration angegeben. Beachten Sie, daß eine gewisse Verarbeitung von Entity- und Zeichenreferenzen im literalen Entity-Wert notwendig sein kann, um den korrekten Ersetzungstext zu erzeugen; siehe 4.5.

Ein internes Entity ist ein analysiertes (parsed) Entity.

Ein Beispiel für eine interne Entity-Deklaration:

<!ENTITY Pub-Status "Dies ist eine Vorabveröffentlichung dieser Spezifikation">

4.2.2 Externe Entities

Ein Entity, das nicht intern ist, ist ein externes Entity, das folgendermaßen deklariert wird:

Wenn NDataDecl vorhanden ist, handelt es sich um ein allgemeines nicht-analysiertes Entity, sonst ist es ein analysiertes Entity.

Gültigkeitsbeschränkung: Deklarierte Notation
Der Name muß mit dem deklarierten Namen einer Notation übereinstimmen.

Das SystemLiteral wird der System-Identifier des Entity genannt. Es handelt sich um einen URI, der dazu benutzt werden kann, das Entity aufzufinden. Beachten Sie, daß das Hash-Zeichen (#) und das bei URIs häufig benutzte Identifier-Fragment kein formaler Bestandteil des URIs selbst sind. Ein XML-Prozessor kann einen Fehler anzeigen, wenn ein Identifier-Fragment als Teil eines System-Identifier angegeben wird. Soweit keine Informationen, die außerhalb des Rahmens dieser Spezifikation liegen, etwas anders aussagen (z.B. ein besonderes XML-Element, das von einer bestimmten DTD definiert wird, oder eine Processing Instruction, die durch eine bestimmte Anwendungsspezifikation definiert wird), beziehen sich relative URIs auf die Adresse der Quelle, in der die Entity-Deklaration steht. Ein URI kann damit relativ zum Dokument-Entity, zum Entity, das die externe DTD-Teilmenge enthält, oder zu irgendeinem anderen externen Parameter-Entity sein.

Ein XML-Prozessor sollte ein Nicht-ASCII-Zeichen in einem URI in folgender Weise behandeln:

1. Darstellung des Zeichens in UTF-8 als ein oder mehrere Bytes
2. Anschließendes Schützen (escape) dieser Bytes mit dem entsprechenden URI-Verfahren (d.h. Umwandeln eines Bytes in %HH, wobei HH die hexadezimale Notation des Byte-Wertes ist)

Zusätzlich zu einen System-Identifier darf ein externer Identifier auch einen Public-Identifier enthalten. Ein XML-Prozessor, der versucht, den Inhalt des Entity zu laden, kann den Public-Identifier verwenden, um einen alternativen URI zu erzeugen. Falls der Prozessor dazu nicht in der Lage ist, muß er den als System Identifier angegebenen URI verwenden. Vor der Abbildung des Public-Identifier auf einen System-Identifier müssen alle Folgen von Leerraum (White Space) auf ein einzelnes Leerzeichen (#x20) normalisiert und führende und abschließende Leerzeichen entfernt werden.

Beispiele für Deklarationen von externen Entities:

<!ENTITY open-hatch
         SYSTEM "http://www.textuality.com/boilerplate/OpenHatch.xml">
<!ENTITY open-hatch
         PUBLIC "-//Textuality//TEXT Standard open-hatch boilerplate//EN"
         "http://www.textuality.com/boilerplate/OpenHatch.xml">
<!ENTITY hatch-pic
         SYSTEM "../grafix/OpenHatch.gif"
         NDATA gif >

4.3 Analysierte Entities

4.3.1 Die Text-Deklaration

Extern-analysierte Entities können mit einer Text-Deklaration beginnen.

Die Text-Deklaration muß literal angegeben werden, nicht als Referenz auf ein analysiertes Entity. An keiner Stelle außer am Anfang eines externen analysierten Entity darf eine Text-Deklaration vorkommen.

4.3.2 Wohlgeformte, analysierte Entities

Das Dokument-Entity ist wohlgeformt, wenn es zur Produktion document paßt. Ein externes, allgemeines, analysiertes Entity ist wohlgeformt, wenn es zur Produktion extParsedEnt paßt. Ein externes Parameter-Entity ist wohlgeformt, wenn es zur Produktion extPE paßt.

Ein internes, allgemeines, analysiertes Entity ist wohlgeformt, wenn sein Ersetzungstext zur Produktion content paßt. Alle internen Parameter-Entities sind per definitionem wohlgeformt.

Eine Konsequenz der Wohlgeformtheit von Entities ist, daß die logische und physikalische Struktur eines XML-Dokuments korrekt verschachtelt ist. Kein Start-Tag, End-Tag, Leeres-Element-Tag, Element, Kommentar, Processing Instruction, Zeichen- oder Entityreferenz kann in einem Entity beginnen und in einem anderen enden.

4.3.3 Zeichenkodierung in Entities

Jedes extern-analysierte Entity in einem XML-Dokument kann eine andere Zeichenkodierung verwenden. Alle XML-Prozessoren müssen in der Lage sein, Entities in UTF-8 oder UTF-16 zu lesen.

Entities in UTF-16-Kodierung müssen mit einer Byte-Order-Markierung beginnen, die in ISO/IEC 10646, Annex E, und in Unicode Appendix B (das ZERO WIDTH NO-BREAK SPACE-Zeichen, #xFEFF) beschrieben ist. Dies ist eine Kodierungssignatur, die weder Teil des Markup noch der Zeichendaten des XML-Dokumentes ist. XML-Prozessoren müssen in der Lage sein, dieses Zeichen zu verwenden, um zwischen UTF-8 und UTF-16 zu unterscheiden.

Obwohl ein XML-Prozessor lediglich Entities in den Kodierungen UTF-8 und UTF-16 lesen muß, ist es offensichtlich, daß andere Kodierungen überall in der Welt benutzt werden. Deshalb kann es wünschenswert sein, daß ein XML-Prozessor solche Entities lesen und benutzen kann. Analysierte Entities, die in einer anderen Kodierung als UTF-8 und UTF-16 gespeichert sind, müssen mit einer Text-Deklaration beginnen, die eine Kodierungsdeklaration enthält.

Im Dokument-Entity ist die Kodierungsdeklaration ein Teil der XML-Deklaration. Der EncName ist der Name der verwendeten Kodierung.

In einer Kodierungsdeklaration sollten die Werte »UTF-8«, »UTF-16«, »ISO-10646-UCS-2« und »ISO-10646-UCS-4« für die verschiedenen Kodierungen und Transformationen von Unicode und ISO/IEC 10646 benutzt werden. Die Werte »ISO-8859-1«, »ISO-8859-2«, ... »ISO-8859-9« sollten für die Teile von ISO 8859 benutzt werden. Die Werte »ISO-2022-JP«, »Shift_JIS« und »EUC-JP« sollten für die verschiedenen Kodierungsformen von JIS X-0208-1997 benutzt werden. XML-Prozessoren dürfen andere Kodierungen erkennen. Es wird empfohlen, daß andere als die genannten Zeichenkodierungen, die bei der Internet Assigned Numbers Authority [IANA] (als Zeichensatz, charsets) registriert sind, mit ihrem registrierten Namen genannt werden. Beachten Sie, daß diese registrierten Namen als case-insensitive definiert sind. Prozessoren sollten einen Vergleich also auch case-insensitive durchführen.

Bei Abwesenheit von Informationen, die durch ein externes Transportprotokoll (z.B. HTTP oder MIME-Typ) geliefert werden, ist es ein Fehler, wenn ein Entity, welches eine Kodierungsdeklaration enthält, in einer anderen Kodierung an den XML-Prozessor übergeben wird. Ebenso ist es ein Fehler, wenn eine Kodierungsdeklaration an einer anderen Stelle als dem Anfang des externen Entity steht oder auch, wenn ein Entity, das weder mit einer Byte-Order-Markierung noch mit einer Kodierungsdeklaration beginnt, eine andere Kodierung als UTF-8 benutzt. Beachten Sie, daß wegen der Tatsache, daß ASCII eine Teilmenge von UTF-8 ist, ASCII-Entities nicht unbedingt eine Kodierungsdeklaration brauchen.

Es ist ein kritischer Fehler, wenn ein XML-Prozessor ein Entity in einer Kodierung bekommt, die er nicht verarbeiten kann.

Beispiel für Kodierungsdeklarationen:

<?xml encoding='UTF-8'?>
<?xml encoding='EUC-JP'?>

4.4 Behandlung von Entities und Referenzen durch einen XML-Prozessor

Die folgende Tabelle faßt zusammen, in welchem Kontext Zeichenreferenzen, Entity-Referenzen und der Aufruf von nicht-analysierten Entities stehen dürfen und wie sich ein XML-Prozessor in jedem Fall zu verhalten hat. Die Einträge in der linken Spalte beschreiben den Kontext:

Referenz im Inhalt

ist eine Referenz zwischen Start-Tag und End-Tag eines Elements. Korrespondiert mit dem Nicht-Terminal content.

Referenz im Attribut-Wert

ist eine Referenz entweder im Wert eines Attributes (im Start-Tag) oder ein Vorgabewert in einer Attributdeklaration. Korrespondiert mit dem Nicht-Terminal AttValue.

Auftreten als Attribut-Wert

als ein Name, nicht als Referenz, entweder als Wert eines Attributs, das als Typ ENTITY deklariert wurde, oder als ein Wert einer Liste von Token (durch Leerzeichen getrennt) in einem Attribut des Typs ENTITIES.

Referenz im Entity-Wert

ist eine Referenz innerhalb des literalen Entity-Werts in der Deklaration eines Parameter- oder internen Entity. Korrespondiert mit dem Nicht-Terminal EntityValue.

Referenz in der DTD

ist eine Referenz in der internen oder externen Teilmenge der DTD, aber außerhalb eines EntityValue oder AttValue.

4.4.1 Nicht erkannt

Außerhalb der DTD hat das Prozent-Zeichen (%) keine besondere Bedeutung. Folglich wird das, was in der DTD ein Parameter-Entity wäre, im Inhalt nicht als Markup erkannt. Ebenso werden die Namen von nicht-analysierten Entities nicht erkannt, es sei denn, sie erscheinen als Wert eines entsprechend deklarierten Attributs.

4.4.2 Inkludiert

Ein Entity wird inkludiert, wenn sein Ersetzungstext an der Stelle der Referenz selbst geladen und verarbeitet wird, so als ob es Teil des Dokumentes wäre und zwar an der Stelle, an der die Referenz steht. Der Ersetzungstext kann sowohl Zeichendaten als auch Markup enthalten (mit Ausnahme der Parameter-Entities), die in der üblichen Weise behandelt werden, abgesehen davon, daß Ersetzungstext, der dazu dient, Markup-Zeichen zu schützen (die Entities amp, lt, gt, apos, quot), stets als Zeichendaten behandelt wird. (Die Zeichenkette »AT&amp;T;« expandiert zu »AT&T;« und das übriggebliebene et-Zeichen wird nicht als Begrenzung einer Entity-Referenz angesehen.) Eine Zeichenreferenz wird inkludiert, wenn das referenzierte Zeichen an Stelle der Referenz verarbeitet wird.

4.4.3 Inkludiert, falls validierend

Wenn der XML-Prozessor bei dem Versuch, ein Dokument zu validieren, auf eine Referenz zu einem analysierten Entity stößt, dann muß der Prozessor dessen Ersetzungstext inkludieren. Wenn es sich um ein externes Entity handelt und der Prozessor gar nicht versucht, das XML-Dokument zu validieren, ist es dem Prozessor freigestellt, den Ersetzungtext zu inkludieren. Wenn ein nicht-validierender Parser einen Ersetzungtext nicht inkludiert, muß er die Anwendung darüber informieren, daß er auf ein Entity gestoßen ist, dieses aber nicht eingelesen hat.

Diese Regel basiert auf der Erkenntnis, daß die automatische Inkludierung, die durch den Entity-Mechanismus von SGML und XML zur Verfügung steht und dazu gedacht war, Modularität bei der Texterstellung zu ermöglichen, nicht unbedingt für andere Anwendungen geeignet ist, insbesondere für das Dokument-Browsing. Beispielsweise könnten Browser sich dafür entscheiden, eine Referenz auf ein extern-analysiertes Entity visuell anzuzeigen und das Entity erst auf Anfrage zu laden und darzustellen.

4.4.4 Verboten

Das folgende ist verboten und stellt einen kritischen Fehler dar:

• das Erscheinen einer Referenz auf ein nicht-analysiertes Entity
• das Erscheinen einer Zeichen- oder allgemeinen Entity-Referenz in der DTD, es sei denn sie steht innerhalb eines EntityValue oder AttValue
• eine Referenz auf ein externes Entity in einem Attribut-Wert

4.4.5 In Literal inkludiert

Wenn eine Entity-Referenz in einem Attribut-Wert erscheint oder wenn eine Parameter-Entity-Referenz in einem literalen Entity-Wert erscheint, wird dessen Ersetzungstext an Stelle der Referenz selbst verarbeitet; so, als ob er Teil des Dokuments an der Stelle wäre, an der die Referenz steht. Eine Ausnahme ist, daß ein einfaches (Apostroph) oder doppeltes Anführungszeichen im Ersetzungstext stets als normales Zeichen behandelt wird und das Literal nicht beendet. Zum Beispiel ist folgendes wohlgeformt:

<!ENTITY % JN '"Ja"' >
<!ENTITY WasErSagte "Er sagte &JN;" >

Dieses jedoch nicht:

<!ENTITY EndAttr "27'" >
<element attribute='a-&EndAttr;>

4.4.6 Informieren

Wenn der Name eines nicht-analysierten Entity als ein Token im Wert eines Attributs erscheint, dessen deklarierter Typ ENTITY oder ENTITIES ist, dann muß ein validierender Prozessor die Anwendung über den System- und Public-Identifier (falls vorhanden) des Entity und dessen Notation informieren.

4.4.7 Durchgereicht

Wenn eine Referenz auf ein allgemeines Entity im EntityValue in einer Entity-Deklaration erscheint, wird es unverändert durchgereicht.

4.4.8 Als PE inkludiert

Genau wie extern-analysierte Entities müssen auch Parameter-Entities nur dann inkludiert werden, wenn das Dokument validiert wird. Wenn eine Parameter-Entity-Referenz in der DTD erkannt und inkludiert wird, wird dessen Ersetzungstext um ein führendes und abschließendes Leerzeichen (#x20) erweitert. Die Absicht ist es, den Ersetzungstext so zu beschränken, daß er in sich geschlossene grammatikalische Token der DTD enthält.

4.5 Konstruktion des Ersetzungstextes von internen Entities

Bei der Diskussion der Behandlung von internen Entities ist es nützlich, zwei Formen von Entity-Werten zu unterscheiden:

1. Der literale Entity-Wert ist die in Anführungszeichen eingeschlossene Zeichenkette in der Entity-Deklaration, korrespondierend zu dem Nicht-Terminal EntityValue.
2. Der Ersetzungstext ist der Inhalt des Entity nach Ersetzen von Zeichen- und Parameter-Entity-Referenzen.

Der literale Entity-Wert, wie er in einer internen Entity-Deklaration (EntityValue) angegeben ist, darf Zeichen-, Parameter-Entity- und allgemeine Entity-Referenzen enthalten. Solche Referenzen müssen vollständig innerhalb des literalen Entity-Werts enthalten sein. Der tatsächliche Ersetzungstext, der wie oben beschrieben inkludiert wird, muß den Ersetzungstext von jedem Parameter-Entity, das referenziert wird, enthalten. Im Falle von Zeichenreferenzen muß er das referenzierte Zeichen im literalen Entity-Wert enthalten. Allgemeine Entity-Referenzen müssen jedoch bleiben wie sie sind, nicht expandiert. Gegeben sei beispielsweise folgende Deklaration:

<!ENTITY % pub    "&#xc9;ditions Gallimard" >
<!ENTITY   rights "All rights reserved" >
<!ENTITY   book   "La Peste: Albert Camus,
&#xA9; 1947 %pub;. &rights;" >

La Peste: Albert Camus,
© 1947 Éditions Gallimard. &rights;

Die allgemeine Entity-Referenz »&rights;« würde expandiert, wenn die Referenz »&book;« im Inhalt des Dokuments oder in einem Attributwert stehen würde.

Diese einfachen Regeln können komplexe Wechselwirkungen haben. Für eine detaillierte Diskussion komplizierterer Beispiele siehe 10.

4.6 Vordefinierte Entities

Entity- und Zeichenreferenzen können beide benutzt werden, um die öffnende spitze Klammer, das et-Zeichen und andere Begrenzungen zu schützen. Zu diesem Zweck ist eine Menge von allgemeinen Entities (amp, lt, gt, apos, quot) spezifiert worden. Außerdem können numerische Zeichenreferenzen verwendet werden. Diese werden unmittelbar expandiert, sobald sie erkannt werden, und müssen als Zeichendaten behandelt werden. So können die numerischen Zeichenreferenzen »&#60;« und »&#38;« verwendet werden, um die Zeichen < und & innerhalb von Zeichendaten zu schützen.

Alle XML-Prozessoren müssen diese Entities erkennen, unabhängig davon, ob sie deklariert sind oder nicht. Zwecks Zusammenarbeit sollten gültige XML-Dokumente diese Entities vor der Benutzung wie andere deklarieren. Wenn die fraglichen Entities deklariert sind, müssen sie als interne Entities deklariert werden, deren Ersetzungstext das einzelne zu schützende Zeichen oder eine Zeichenreferenz darauf ist, wie unten gezeigt.

<!ENTITY lt     "&#38;#60;">
<!ENTITY gt     "&#62;">
<!ENTITY amp    "&#38;#38;">
<!ENTITY apos   "&#39;">
<!ENTITY quot   "&#34;">

Beachten Sie, daß die Zeichen < und & in der Deklaration von »lt« und »amp« doppelt geschützt sind, um die Anforderung zu erfüllen, daß Entity-Ersetzungen wohlgeformt sind.

4.7 Notation-Deklarationen

Notationen identifizieren durch einen Namen das Format von nicht-analysierten Entities, das Format von Elementen, die ein Notation-Attribut tragen oder die Anwendung, an die sich eine Processing Instruction richtet.

Notation-Deklarationen geben einer Notation einen Namen für die Verwendung in Entity- und Attributlisten-Deklarationen und in Attribut-Spezifikationen sowie einen externen Identifier für die Notation, der es dem XML-Prozessor oder seinem Anwendungsprogramm erlaubt, ein Hilfsprogramm zu finden, das in der Lage ist, Daten in der gegebenen Notation zu verarbeiten.

XML-Prozessoren müssen Anwendungen mit dem Namen und dem/den externen Identifier(n) jeder Notation versorgen, die deklariert werden und auf die in einem Attribut-Wert, einer Attributdefinition oder einer Entity-Deklaration verwiesen wird. Sie dürfen außerdem den externen Identifier zu einem System-Identifier, einem Dateinamen oder einer anderen benötigten Information auflösen, die es der Anwendung erlaubt, einen Prozessor für die Daten in der beschriebenen Notation aufzurufen. (Es ist kein Fehler, wenn ein XML-Dokument Notationen deklariert und referenziert, für die keine notationsspezifischen Anwendungen auf dem System verfügbar sind, auf dem der XML-Prozessor oder dessen Anwendung läuft.)

4.8 Dokument-Entity

Das Dokument-Entity dient als Wurzel des Entity-Baumes und als Startpunkt für einen XML-Prozessor. Diese Spezifikation gibt nicht an, wie das Dokument-Entity von einem XML-Prozessor gefunden wird. Anders als andere Entities hat das Dokument-Entity keinen Namen und kann im Eingabestrom des Prozessors ganz ohne Identifikation erscheinen.

5 Konformität

5.1 Validierende und nicht-validierende Prozessoren

Konforme XML-Prozessoren fallen in zwei Kategorien: validierend und nicht-validierend.

Sowohl validierende als auch nicht-validierende Prozessoren müssen Verletzungen der in dieser Spezifikation genannten Wohlgeformtheitsbeschränkung, die im Inhalt des Dokument-Entity und jedes anderen analysierten Entity das sie lesen, melden.

Validierende Prozessoren müssen Verletzungen der Beschränkungen, die durch die Deklarationen in der DTD formuliert werden, sowie jedes Nicht-Erfüllen der in dieser Spezifikation formulierten Gültigkeitsbeschränkung melden. Um dies zu erreichen, müssen validierende XML-Prozessoren die gesamte DTD und alle extern-analysierten Entities, die im Dokument referenziert werden, einlesen und verarbeiten.

Nicht-validierende Prozessoren müssen lediglich das Dokument-Entity, einschließlich der gesamten internen DTD-Teilmenge auf Wohlgeformtheit prüfen. Während sie das Dokument nicht auf Gültigkeit prüfen müssen, müssen sie alle Deklarationen, die sie in der internen DTD-Teilmenge lesen, und alle Parameter-Entities, die sie lesen, verarbeiten, bis zur ersten Referenz auf ein Parameter-Entity, das sie nicht lesen. Das heißt, sie müssen die Information in solchen Deklarationen nutzen, um Attribut-Werte zu normalisieren, sie müssen den Ersetzungstext von internen Entities einfügen, und sie müssen Vorgabewerte (defaults) liefern. Sie dürfen keine Entity-Deklarationen oder Attributlisten-Deklarationen verarbeiten, die sich hinter einer Referenz auf ein nicht gelesenes Parameter-Entity befinden, da das Entity überschreibende Deklarationen enthalten könnte.

5.2 Benutzen von XML-Prozessoren

Das Verhalten von validierenden XML-Prozessoren ist hochgradig vorhersagbar; er muß jeden Teil eines Dokuments lesen und alle Verletzungen von Wohlgeformtheit und Gültigkeit melden. Geringer sind die Ansprüche an einen nicht validierenden Prozessor; er muß keinen anderen Teil als das Dokument-Entity lesen. Dies hat zwei Effekte, die für den Benutzer eines XML-Prozessors wichtig sein könnten:

• Bestimmte Wohlgeformtheitsfehler, insbesondere solche, die das Lesen von externen Entities erfordern, werden von einem nicht-validierenden XML-Prozessor möglicherweise nicht entdeckt. Beispiele sind sowohl in den Beschränkungen mit den Titeln »Entity deklariert«, »Analysiertes Entity« und »Keine Rekursion« zu finden als auch in einigen der als verboten beschriebenen Fälle im Abschnitt 4.4.
• Die Information, die vom Prozessor an die Anwendung gereicht wird, kann variieren, abhängig davon, ob der Prozessor Parameter- und externe Entities liest. Zum Beispiel darf es ein nicht-validierender Prozessor unterlassen, Attributwerte zu normalisieren, Ersetzungstext von externen Entities einzufügen oder Vorgabewerte für Attribute zu liefern. In welchen Fällen er es macht, hängt davon ab, ob er Deklarationen in externen oder Parameter-Entities gelesen hat.

Für die maximale Verläßlichkeit bei der Zusammenarbeit mit verschiedenen XML-Prozessoren sollten sich Anwendungen, die nicht-validierende Prozessoren benutzen, auf kein Verhalten verlassen, das solche Prozessoren nicht zeigen müssen. Anwendungen, die gewisse Dinge benötigen, wie die Verwendung von Vorgabewerten oder interne Entities, die in externen Entities deklariert sind, sollten validierende XML-Prozessoren benutzen.

6 Notation

Die formale Grammatik von XML ist in dieser Spezifikation unter Verwendung einer einfachen Erweiterten Backus-Naur-Form (EBNF) notiert. Jede Regel der Gramamtik definiert ein Symbol in der folgenden Form:

Symbol ::= Ausdruck

Symbole beginnen mit einem großen Anfangsbuchstaben, falls sie durch einen regulären Ausdruck definiert sind, sonst mit einem kleinen Anfangsbuchstaben. Literale Zeichenketten sind in Anführungszeichen eingeschlossen.

Innerhalb des Ausdrucks auf der rechten Seite der Regel werden die folgenden Ausdrücke verwendet, um Muster von einem oder mehr Zeichen anzugeben:

#xN

wobei N eine ganze Hexadezimalzahl ist. Dieser Ausdruck paßt zu dem Zeichen aus ISO/IEC 10646, dessen kanonischer (UCS-4-) Code bei Interpretation als vorzeichenlose (unsigned) Binärzahl den Wert N hat. Die Anzahl der führenden Nullen in #xN ist unwichtig. Die Anzahl der führenden Nullen im korrespondierenden Code ist durch die Zeichenkodierung vorgegeben und für XML unerheblich.

[a-zA-Z], [#xN-#xN]

paßt zu jedem Zeichen mit einem Code innerhalb und inklusive des/der angegebenen Intervalle(s).

[^a-z], [^#xN-#xN]

paßt zu jedem Zeichen außerhalb des Intervalls.

[^abc], [^#xN#xN#xN]

paßt zu jedem Zeichen, das nicht zu den genannten gehört.

"zeichenkette"

paßt zu der literalen Zeichenkette, die innerhalb der doppelten Anführungszeichen angegeben ist.

'zeichenkette'

paßt zu der literalen Zeichenkette, die innerhalb der einfachen Anführungszeichen (Apostroph) angegeben ist.

Diese Symbole können auf folgende Weise kombiniert werden, um komplexere Muster zu bilden. A und B stellen jeweils einfach Ausdrücke dar.

(ausdruck)

ausdruck wird als Einheit betrachtet und kann, wie in dieser Liste beschrieben, kombiniert werden.

A?

paßt zu A oder nichts; optionales A.

A B

paßt zu A, gefolgt von B.

A | B

paßt zu A oder B, aber nicht zu beidem.

A - B

paßt zu jeder Zeichenkette, die zu A paßt, aber nicht zu B.

A+

paßt zu einfachem oder mehrfachem Vorkommen von A.

A*

paßt zu null-, ein- oder mehrfachem Vorkommen von A.

Weitere in den Produktionen benutzte Notationen sind:

/* ... */

Kommentar

[WGB: ... ]

Wohlgeformtheitsbeschränkung. Diese identifiziert durch einen Namen eine mit einer Produktion verknüpfte Beschränkung eines wohlgeformten Dokuments.

[GKB: ... ]

Gültigkeitsbeschränkung. Diese identifiziert durch einen Namen eine mit einer Produktion verknüpfte Beschränkung eines gültigen Dokuments.

7 Anhang A: Referenzen

7.1 Normative Referenzen

IANA

(Internet Assigned Numbers Authority) Official Names for Character Sets, ed. Keld Simonsen et al. Siehe ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets.

IETF RFC 1766

IETF (Internet Engineering Task Force). RFC 1766: Tags for the Identification of Languages, ed. H. Alvestrand. 1995.

ISO 639

(International Organization for Standardization). ISO 639:1988 (E). Code for the representation of names of languages. [Geneva]: International Organization for Standardization, 1988.

ISO 3166

(International Organization for Standardization). ISO 3166-1:1997 (E). Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes [Geneva]: International Organization for Standardization, 1997.

ISO/IEC 10646

ISO (International Organization for Standardization). ISO/IEC 10646-1993 (E). Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. [Geneva]: International Organization for Standardization, 1993 (plus amendments AM 1 through AM 7).

Unicode

The Unicode Consortium. The Unicode Standard, Version 2.0. Reading, Mass.: Addison-Wesley Developers Press, 1996.

7.2 Weitere Referenzen

Aho/Ullman

Aho, Alfred V., Ravi Sethi und Jeffrey D. Ullman. Compilers: Principles, Techniques, and Tools. Reading: Addison-Wesley, 1986, rpt. corr. 1988.

Berners-Lee et al.

Berners-Lee, T., R. Fielding und L. Masinter. Uniform Resource Identifiers (URI): Generic Syntax and Semantics. 1997. (Work in progress; see updates to RFC 1738.)

Brüggemann-Klein

Brüggemann-Klein, Anne. Regular Expressions into Finite Automata. Extended abstract in I. Simon, Hrsg., LATIN 1992, S. 97-98. Springer-Verlag, Berlin 1992. Full Version in Theoretical Computer Science 120: 197-213, 1993.

Brüggemann-Klein und Wood

Brüggemann-Klein, Anne, und Derick Wood. Deterministic Regular Languages. Universität Freiburg, Institut für Informatik, Bericht 38, Oktober 1991.

Clark

James Clark. Comparison of SGML and XML. Siehe http://www.w3.org/TR/NOTE-sgml-xml-971215.

IETF RFC 1738

IETF (Internet Engineering Task Force). RFC 1738: Uniform Resource Locators (URL), ed. T. Berners-Lee, L. Masinter, M. McCahill. 1994.

IETF RFC 1808

IETF (Internet Engineering Task Force).RFC 1808: Relative Uniform Resource Locators, ed. R. Fielding. 1995.

IETF RFC 2141

IETF (Internet Engineering Task Force). RFC 2141: URN Syntax, ed. R. Moats. 1997.

ISO 8879

ISO (International Organization for Standardization). ISO 8879:1986(E). Information processing -- Text and Office Systems -- Standard Generalized Markup Language (SGML). First edition -- 1986-10-15. [Geneva]: International Organization for Standardization, 1986.

ISO/IEC 10744

ISO (International Organization for Standardization). ISO/IEC 10744-1992 (E). Information technology -- Hypermedia/Time-based Structuring Language (HyTime). [Geneva]: International Organization for Standardization, 1992. Extended Facilities Annexe. [Geneva]: International Organization for Standardization, 1996.

8 Anhang B: Zeichenklassen

Den im Unicode-Standard definierten Charakteristika zufolge sind Zeichen klassifiziert als Grundzeichen (base characters; unter anderem gehören dazu die alphabetischen Zeichen des lateinischen Alphabets ohne diakritische Zeichen), ideographische Zeichen sowie kombinierte Zeichen (unter anderem gehören dazu diakritische Zeichen). Zusammen bilden diese Klassen die Klasse der Buchstaben (letters). Außerdem werden Ziffern (digits) und Erweiterungen (extenders) unterschieden.

Die hier definierten Klassen könnten aus der Unicode-Zeichendatenbank in folgender Weise abgeleitet werden:

• Anfangszeichen von Namen müssen in einer der Kategorien Ll, Lu, Lo, Lt, Nl sein.
• Andere Namen-Zeichen als die Anfangszeichen müssen in einer der Kategorien Mc, Me, Mn, Lm, Nd sein.
• Zeichen im Kompatibilitätsbereich (compatibility area; das sind Zeichen mit einem Code größer #xF900 als und kleiner als #xFFFE) sind in XML-Namen nicht erlaubt.
• Zeichen, die eine Zeichensatz- oder Kompatibilitätszerlegung (font or compatibility decomposition) haben (d.h. solche, die mit einem »compatibility formatting tag« in Feld 5 der Datenbank -- durch ein mit einem »<« beginnendes Feld 5 gekennzeichnet) sind nicht erlaubt.
• Die folgenden Zeichen werden als Anfangszeichen von Namen, im Gegensatz zu Namen-Zeichen, behandelt, da die Property-Datei sie als alphabetisch klassifiziert: [#x02BB-#x02C1], #x0559, #x06E5, #x06E6.
• Die Zeichen #x20DD-#x20E0 sind ausgeschlossen (in Übereinstimmung mit Unicode, Abschnitt 5.14)
• Zeichen #x00B7 ist als Erweiterung klassifiziert, da die Property-Liste es so einstuft.
• Zeichen #x0387 wurde als Namen-Zeichen hinzugefügt, da #x00B7 sein kanonisches Äquivalent ist.
• Zeichen »:« und »_« sind als Anfangszeichen für Namen erlaubt.
• Zeichen »-« und ».« sind als Namen-Zeichen erlaubt.

9 Anhang C: XML und SGML (nicht normativ)

XML wurde als Teilmenge von SGML entworfen, so daß jedes gültige XML-Dokument auch ein konformes SGML-Dokument ist. Für einen detaillierten Vergleich der weitergehenden Beschränkungen, die XML über SGML hinaus einem Dokument auferlegt, siehe [Clark].

10 Anhang D: Expansion von Entity- und Zeichenreferenzen (nicht normativ)

Dieser Anhang enthält einige Beispiele, die die Abfolge der Erkennung und Expansion von Entity- und Zeichenreferenzen, wie in 4.4 beschrieben, illustrieren.

Wenn die DTD folgende Deklaration enthält

<!ENTITY beispiel "<p>Ein et-Zeichen (&#38;#38;) kann 
numerisch (&#38;#38;#38;) oder mit einem allgemeinen
Entity (&amp;amp;) geschützt werden.</p>" >

dann wird der XML-Prozessor die Zeichenreferenzen erkennen, sobald er die Entity-Deklaration analysiert, und wird sie auflösen, um schließlich folgende Zeichenkette als den Wert des Entity »beispiel« zu speichern:

<p>Ein et-Zeichen (&#38;) kann 
numerisch (&#38;#38;) oder mit einem allgemeinen
Entity (&amp;amp;) geschützt werden.</p>

Eine Referenz auf »&beispiel;« im Dokument verursacht eine erneute Analyse, in der die Start- und End-Tags des »p«-Elements erkannt und die drei Referenzen erkannt und expandiert werden. Das Ergebnis ist ein »p«-Element mit folgendem Inhalt (alles Zeichendaten, keine Begrenzungen oder Markup):

Ein et-Zeichen (&) kann 
numerisch (&) oder mit einem allgemeinen
Entity (&) geschützt werden.

Ein komplexeres Beispiel wird die Regeln und ihre Auswirkungen vollständig illustrieren. Im folgenden Beispiel dienen die Zeilennummern einzig zur Referenzierung.

 1 <?xml version='1.0'?>
 2 <!DOCTYPE test [
 3 <!ELEMENT test (#PCDATA) >
 4 <!ENTITY % xx '&#37;zz;'>
 5 <!ENTITY % zz '&#60;!ENTITY trickreiche "fehler-anfällig" >' >
 6 %xx;
 7 ]>
 8 <test>Dieses Beispiel zeigt eine &trickreiche; Methode.</test>

Dieses führt zu folgendem:

• In Zeile 4 wird die Referenz auf das Zeichen 37 sofort aufgelöst, und das Parameter-Entity »xx« wird in der Symboltabelle mit dem Wert »%zz;« abgelegt. Da der Ersetzungstext nicht noch einmal analysiert wird, wird die Referenz auf das Parameter-Entity »zz« nicht erkannt. (Und das wäre auch ein Fehler, denn »zz« ist noch nicht deklariert.)
• In Zeile 5 wird die Zeichenreferenz »<« sofort expandiert, und das Parameter-Entity »zz« wird mit dem Ersetzungstext »<!ENTITY trickreiche "fehler-anfällige" >« abgelegt, was eine wohlgeformte Entity-Deklaration ist.
• In Zeile 6 wird die Referenz auf »xx« erkannt, und der Ersetzungstext von »xx«, nämlich »%zz;«, wird analysiert. Die Referenz auf »zz« wird seinerseits erkannt und dessen Ersetzungstext (»<!ENTITY trickreiche "fehler-anfällige" >«) wird analysiert. Das allgemeine Entity »trickreiche« wurde nun mit dem Ersetzungstext »fehler-anfällige« deklariert.
• In Zeile 8 wird die Referenz auf das allgemeine Entity »trickreiche« erkannt und expandiert, so daß der volle Inhalt des Elementes »test« nun die folgende selbstbeschreibende (und grammatikalisch falsche) Zeichenkette ist: »Dieses Beispiel zeigt eine fehler-anfällig Methode.«

11 Anhang E: Deterministische Inhaltsmodelle (nicht normativ)

Zwecks Kompatibilität ist es notwendig, daß Inhaltsmodelle in Elementtyp-Deklarationen deterministisch sind.

SGML benötigt deterministische Inhaltsmodelle (dort »unzweideutig« (unambiguous) genannt). XML-Prozessoren, die mit SGML-Systemen konstruiert wurden, können nicht-deterministische Inhaltsmodelle als Fehler anzeigen.

Zum Beispiel ist das Inhaltsmodell ((b, c) | (b, d)) nicht deterministisch, da der Parser bei einem gegebenen initialen b nicht wissen kann, welches b im Inhaltsmodell dazu paßt, ohne vorauszuschauen und nachzusehen, welches Element dem b folgt. In diesem Fall können die zwei Referenzen auf b auf folgende Weise zu einer einzigen Referenz zusammengefaßt werden: (b, (c | d)). Ein einleitendes b paßt nun eindeutig zu einem Namen im Inhaltsmodell. Der Parser braucht nicht mehr vorauszuschauen, um zu sehen, was folgt. Sowohl c als auch d würden akzeptiert.

Etwas formaler: Ein endlicher Automat kann aus dem Inhaltsmodell unter Verwendung von Standardalgorithmen, etwa Algorithmus 3.5 in Abschnitt 3.9 von Aho, Sethi und Ullman [Aho/Ullman], konstruiert werden. In vielen solcher Algorithmen wird eine Folgemenge für jeden Zustand im regulären Ausdruck (d.h. jedes Blatt im Syntaxbaum des regulären Ausdrucks) konstruiert. Falls ein Zustand eine Folgemenge besitzt, in der mehr als ein Folgezustand mit dem gleichen Elementtyp-Namen markiert ist, dann ist das Inhaltsmodell fehlerhaft und kann als Fehler angezeigt werden.

Es existieren Algorithmen, die es erlauben, viele (aber nicht alle) nicht-deterministischen Inhaltsmodelle automatisch auf äquivalente deterministische Modelle zurückzuführen; siehe Brüggemann-Klein 1991 [Brüggemann-Klein].

12 Anhang F: Automatische Erkennung von Zeichenkodierungen (nicht normativ)

Die XML-Kodierungsdeklaration fungiert als eine interne Markierung in jedem Entity, die anzeigt, welche Zeichenkodierung benutzt wird. Bevor ein XML-Prozessor die interne Markierung lesen kann, muß er offensichtlich wissen, welche Zeichenkodierung benutzt wird -- was genau das ist, was die interne Markierung anzeigen will. Im allgemeinen Fall ist das eine hoffnungslose Situation. In XML ist es aber nicht völlig hoffnungslos, weil XML den allgemeinen Fall auf zwei Arten einschränkt: Es wird angenommen, daß jede Implementation nur eine endliche Menge von Zeichenkodierungen unterstützt, und die XML-Kodierungsdeklaration ist in ihrer Position und ihrem Inhalt eingeschränkt, um eine automatische Erkennung der benutzten Zeichenkodierung in jedem Entity im Normalfall zu ermöglichen. Außerdem sind in vielen Fällen zusätzlich zum XML-Datenstrom andere Informationsquellen verfügbar. Zwei Fälle können unterschieden werden, abhängig davon, ob das XML-Entity dem Prozessor ohne oder mit weiteren (externen) Informationen zur Verfügung steht. Wir nehmen zunächst den ersten Fall an.

Da jedes XML-Entity, das nicht im UTF-8- oder UTF-16-Format vorliegt, mit einer XML-Kodierungsdeklaration beginnen muß, in der die ersten Zeichen »<?xml« sind, kann jeder konforme Prozessor nach Einlesen von zwei bis vier Oktetten entscheiden, welcher der folgenden Fälle vorliegt. Beim Lesen dieser Liste kann es hilfreich sein, zu wissen, daß in UCS-4 das »<« die Kodierung »#x0000003C« und »?« die Kodierung »#x0000003F« hat und daß die Byte-Order-Markierung, die von UTF-16-Datenströmen benötigt wird, die Kodierung »#xFEFF« hat.

• 00 00 00 3C: UCS-4, Big-endian-Maschine (Reihenfolge 1234)
• 3C 00 00 00: UCS-4, Little-endian-Maschine (Reihenfolge 4321)
• 00 00 3C 00: UCS-4, ungewöhnliche Oktett-Reihenfolge (2143)
• 00 3C 00 00: UCS-4, ungewöhnliche Oktett-Reihenfolge (3412)
• FE FF: UTF-16, Big-endian
• FF FE: UTF-16, Little-endian
• 00 3C 00 3F: UTF-16, Big-endian, keine Byte-Order-Markierung (und damit -- streng genommen -- fehlerhaft)
• 3C 00 3F 00: UTF-16, Little-endian, keine Byte-Order-Markierung (und damit -- streng genommen -- fehlerhaft)
• 3C 3F 78 6D: UTF-8, ISO 646, ASCII, einige Teile von ISO 8859, Shift-JIS, EUC oder jede andere 7-Bit-, 8-Bit-, oder Kodierung mit gemischter Breite, die sicherstellt, daß die ASCII-Zeichen ihre normale Position, Breite und Werte haben. Die tatsächliche Kodierungsdeklaration muß gelesen werden, aber da jede dieser Kodierungen die gleichen Bitmuster für ASCII-Zeichen verwendet, kann die Kodierungsdeklaration selbst sicher gelesen werden.
• 4C 6F A7 94: EBCDIC (In einigen Fällen muß die vollständige Kodierungsdeklaration gelesen werden, um sagen zu können, welche Codepage verwendet wird.)
• andere: UTF-8 ohne Kodierungsdeklaration; andernfalls ist der Datenstrom fehlerhaft, unvollständig oder in irgendeinen Wrapper eingepackt.

Dieses Niveau der automatischen Erkennung ist ausreichend, um die XML-Kodierungsdeklaration zu lesen und den Identifier für die Zeichenkodierung zu analysieren, was immer noch notwendig ist, um zwischen einzelnen Mitgliedern einer Kodierungsfamilie zu unterscheiden (z.B. um UTF-8 von 8859 und die Teile von 8859 voneinander zu unterscheiden oder um die genaue EBCDIC-Codepage zu identifizieren).

Da der Inhalt der Kodierungsdeklaration auf ASCII-Zeichen beschränkt ist, kann ein Prozessor sicher die gesamte Kodierungsdeklaration lesen, sobald er erkannt hat, welche Kodierungsfamilie verwendet wird. Da praktisch alle weit verbreiteten Zeichenkodierungen in eine der obengenannten Kategorien fallen, erlaubt die XML-Kodierungsdeklaration eine hinreichend zuverlässige Selbstbeschreibung der Zeichenkodierungen, selbst wenn externe Informationsquellen auf Ebene des Betriebssystems oder Transport-Protokolls unzuverlässig sind.

Hat der Prozessor einmal die verwendete Zeichenkodierung erkannt, kann er angemessen handeln, sei es durch den Aufruf einer für jeden Fall separaten Eingaberoutine oder den Aufruf einer geeigneten Konvertierungsfunktion für jedes Eingabezeichen.

Wie jedes selbstkennzeichnende System wird auch die XML-Kodierungsdeklaration nicht funktionieren, falls irgendeine Software den Zeichensatz oder die Kodierung des Entity ändert, ohne die Kodierungsdeklaration zu aktualisieren. Programmierer von Routinen zur Zeichenkodierung sollten mit Sorgfalt die Korrektheit von internen und externen Informationen zur Kennzeichnung eines Entity sicherstellen.

Der zweite mögliche Fall tritt ein, wenn das XML-Entity durch Kodierungsinformationen ergänzt wird, wie in einigen Filesystemen und Netzwerkprotokollen. Wenn mehrere Informationsquellen verfügbar sind, sollten ihre relative Priorität und die bevorzugte Methode zur Handhabung von Konflikten als Teil des Übertragungsprotokolls, das zum Versenden von XML benutzt wird, spezifiziert werden. Regeln für die relative Priorität der internen Kennzeichnung und zum Beispiel der MIME-Typ-Kennzeichnung in einem externen Protokollkopf sollten Teil des RFC-Dokumentes sein, das die MIME-Typen text/xml und application/xml definiert. Im Interesse der Zusammenarbeit werden aber folgende Regeln empfohlen:

• Falls ein XML-Entity in einer Datei steht, dann werden die Byte-Order-Markierung und die Processing Instruction mit Kodierungsdeklaration verwendet (falls vorhanden), um die Zeichenkodierung zu bestimmen. Alle anderen Heuristiken und Informationsquellen dienen einzig dazu, im Fehlerfall weiterzuarbeiten.
• Falls ein XML-Entity mit dem MIME-Typ »text/xml« ausgeliefert wird, dann bestimmt der »charset«-Parameter des MIME-Typs die Zeichenkodierung. Alle anderen Heuristiken und Informationsquellen dienen einzig dazu, im Fehlerfall weiterzuarbeiten.
• Falls ein XML-Entity mit dem MIME-Typ »application/xml« ausgeliefert wird, dann werden die Byte-Order-Markierung und die Processing Instruction mit Kodierungsdeklaration verwendet (falls vorhanden), um die Zeichenkodierung zu bestimmen. Alle anderen Heuristiken und Informationsquellen dienen einzig zur Fehlerbehebung.

Diese Regeln gelten nur bei Fehlen von Dokumentation der Protokoll-Ebene. Insbesondere sobald die MIME-Typen »text/xml« und »application/xml« definiert sind, werden die Empfehlungen des relevanten RFC diese Regeln ersetzen.

13 Anhang G: XML-Arbeitsgruppe des W3C (nicht normativ)

Diese Spezifikation wurde von der W3C-XML-Arbeitsgruppe (AG) erstellt und deren Veröffentlichung gebilligt. Die Billigung der AG bedeutet nicht zwingend, daß alle AG-Mitglieder dafür gestimmt haben. Die momentanen und ehemaligen Mitglieder der XML-AG sind:

Jon Bosak, Sun (Vorsitz); James Clark (Technische Leitung); Tim Bray, Textuality und Netscape (XML-Co-Herausgeber); Jean Paoli, Microsoft (XML-Co-Herausgeber); C. M. Sperberg-McQueen, U. of Ill. (XML-Co-Herausgeber); Dan Connolly, W3C (Verbindung zum W3C); Paula Angerstein, Texcel; Steve DeRose, INSO; Dave Hollander, HP; Eliot Kimber, ISOGEN; Eve Maler, ArborText; Tom Magliery, NCSA; Murray Maloney, Muzmo and Grif; Makoto Murata, Fuji Xerox Information Systems; Joel Nava, Adobe; Conleth O'Connell, Vignette; Peter Sharpe, SoftQuad; John Tigue, DataChannel

Copyright © 1998 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.