edition W3C.de

Extensible Markup Language (XML) 1.0 (Zweite Auflage)

Deutsche Übersetzung

20. Januar 2002

Diese Version:
http://www.edition-w3c.de/TR/2000/REC-xml-20001006
Aktuelle Version:
http://www.edition-w3c.de/TR/REC-xml
Übersetzer:
Stefan Mintert, Linkwerk.com

Know How by Linkwerk.com Bei diesem Dokument handelt es sich um eine Übersetzung eines W3C-Textes. Dieser Text ist urheberrechtlich geschützt; bitte beachten Sie die nachfolgenden Hinweise des Originaldokuments. Die Rechte an der Übersetzung liegen bei den Übersetzern sowie beim Verlag Addison-Wesley. Die Übersetzung hat keine durch das W3C legitimierte, normative Wirkung. Das einzige maßgebliche Dokument ist das englische Original.

Bitte senden Sie Fehler und Korrekturen zur deutschen Fassung an die Übersetzer.

Kommentare der Übersetzer, die als solche gekennzeichnet sind, unterliegen dem Urheberrecht der Übersetzer. Sie sind nicht Bestandteil des Ursprungsdokuments.

XML-Schulungen für Entwickler!
Jetzt online auf Linkwerk.com buchen!



W3C

Extensible Markup Language (XML) 1.0 (Zweite Auflage)

W3C-Empfehlung 6. Oktober 2000

Diese Version:
http://www.w3.org/TR/2000/REC-xml-20001006 (XHTML, XML, PDF, XHTML rezensierte Version mit farbig hervorgehobenen Änderungen)
Aktuelle Version:
http://www.w3.org/TR/REC-xml
Vorherige Version:
http://www.w3.org/TR/2000/WD-xml-2e-20000814 http://www.w3.org/TR/1998/REC-xml-19980210
Herausgeber:
Tim Bray, Textuality and Netscape <tbray@textuality.com>
Jean Paoli, Microsoft <jeanpa@microsoft.com>
C. M. Sperberg-McQueen, University of Illinois at Chicago and Text Encoding Initiative <cmsmcq@uic.edu>
Eve Maler, Sun Microsystems, Inc. <eve.maler@east.sun.com> - Zweite Auflage

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 bekannt zu machen und ihre breite Anwendung zu fördern. Dies erhöht die Funktionsfähigkeit und Interoperabilität des Web hallo berlin.

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. Die englische Version dieser Spezifikation ist die einzige normative Version. Für Übersetzungen siehe http://www.w3.org/XML/#trans. Eine Liste aktueller W3C-Empfehlungen und anderer technischer Dokumente ist unter http://www.w3.org/TR zu finden.

Diese zweite Auflage ist keine neue Version von XML (zuerst veröffentlicht am 10. Februar 1998); sie enthält zur bequemeren Lesbarkeit lediglich die Änderungen, die durch die Errata der ersten Auflage impliziert werden (verfügbar unter http://www.w3.org/XML/xml-19980210-errata). Die Errata-Liste für diese zweite Auflage steht unter http://www.w3.org/XML/xml-V10-2e-errata zur Verfügung..

Bitte melden Sie Fehler in diesem Dokument an xml-editor@w3.org; ein Archiv ist vorhanden.

Anmerkung:

C. M. Sperberg-McQueens Zugehörigkeit hat sich seit Veröffentlichung der ersten Auflage geändert. Er ist nun beim World Wide Web Consortium und kann erreicht werden unter cmsmcq@w3.org.

Inhaltsverzeichnis

1 Einführung
    1.1 Herkunft und Ziele
    1.2 Terminologie
2 Dokumente
    2.1 Wohlgeformte XML-Dokumente
    2.2 Zeichen
    2.3 Allgemeine syntaktische Konstrukte
    2.4 Zeichendaten und Markup
    2.5 Kommentare
    2.6 Verarbeitungsanweisungen
    2.7 CDATA-Abschnitte
    2.8 Prolog und Dokumenttyp-Deklaration
    2.9 Standalone-Dokumentdeklaration
    2.10 Behandlung von Leerraum
    2.11 Behandlung des Zeilenendes
    2.12 Identifikation der Sprache
3 Logische Strukturen
    3.1 Start-Tags, End-Tags und Leeres-Element-Tags
    3.2 Elementtyp-Deklarationen
        3.2.1 Element-Inhalt
        3.2.2 Gemischter Inhalt
    3.3 Attributlisten-Deklaration
        3.3.1 Attribut-Typen
        3.3.2 Attribut-Vorgaben
        3.3.3 Normalisierung von Attribut-Werten
    3.4 Bedingte Abschnitte
4 Physische Strukturen
    4.1 Zeichen- und Entity-Referenzen
    4.2 Entity-Deklarationen
        4.2.1 Interne Entities
        4.2.2 Externe Entities
    4.3 Analysierte Entities
        4.3.1 Die Text-Deklaration
        4.3.2 Wohlgeformte analysierte Entities
        4.3.3 Zeichenkodierung in Entities
    4.4 Behandlung von Entities und Referenzen durch einen XML-Prozessor
        4.4.1 Nicht erkannt
        4.4.2 Inkludiert
        4.4.3 Inkludiert, falls validierend
        4.4.4 Verboten
        4.4.5 In Literal inkludiert
        4.4.6 Informieren
        4.4.7 Durchgereicht
        4.4.8 Als PE inkludiert
    4.5 Konstruktion des Ersetzungstextes von internen Entities
    4.6 Vordefinierte Entities
    4.7 Notation-Deklarationen
    4.8 Dokument-Entity
5 Konformität
    5.1 Validierende und nicht-validierende Prozessoren
    5.2 Benutzen von XML-Prozessoren
6 Notation

Anhänge

A Referenzen
    A.1 Normative Referenzen
    A.2 Weitere Referenzen
B Zeichenklassen
C XML und SGML (nicht normativ)
D Expansion von Entity- und Zeichenreferenzen (nicht normativ)
E Deterministische Inhaltsmodelle (nicht normativ)
F Automatische Erkennung von Zeichenkodierungen (nicht normativ)
    F.1 Erkennung ohne externe Kodierungsinformation
    F.2 Priorisierung bei Vorhandensein von externer Kodierungsinformation
G XML-Arbeitsgruppe des W3C (nicht normativ)
H W3C XML Core -Gruppe (nicht normativ)
I Hinweise zur Produktion (nicht normativ)

Anhänge zur Übersetzung

a Referenzen
b Hinweise zur Produktion

Endnoten



1 Einführung

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.

[Definition: Ein Software-Modul, genannt XML-Prozessor, dient dazu, XML-Dokumente zu lesen und den Zugriff auf ihren Inhalt und ihre Struktur zu erlauben.] [Definition: Es wird angenommen, dass 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 muss und welche Informationen er an die Anwendung weiterreichen muss.


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 abgefasst 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 kostenlos weitergegeben werden, solange der Text und alle rechtlichen Hinweise unversehrt bleiben.


1.2 Terminologie

Die Terminologie, die zur Beschreibung von XML-Dokumenten verwendet wird, ist innerhalb dieser Spezifikation definiert. Die in der folgenden Liste definierten Begriffe werden benutzt, um jene Definitionen zu formulieren und die Aktionen eines XML-Prozessors zu beschreiben.

darf (may)

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

müssen/nicht dürfen (must)

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

Fehler (error)

[Definition: 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)

[Definition: Ein Fehler, den ein konformer XML-Prozessor erkennen und an das Anwendungsprogramm melden muss. 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, dass 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)

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

Gültigkeitsbeschränkung (validity constraint)

[Definition: 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)

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

passen (match)

[Definition: (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. (Strings und Regeln in der Grammatik:) Ein String passt zu einer grammatikalischen Produktion, wenn er zur Sprache gehört, die durch die Produktion erzeugt wird. (Inhalt und Inhaltsmodelle:) Ein Element passt zu seiner Deklaration, wenn es in der Weise konform ist, die in der Gültigkeitsbeschränkung [GKB: gültiges Element] beschrieben ist.]

zwecks Kompatibilität (for compatibility)

[Definition: Bezeichnet einen Satz, der eine Eigenschaft von XML beschreibt, die einzig zu dem Zweck eingeführt wurde, dass XML mit SGML kompatibel bleibt.]

zwecks Zusammenarbeit (for interoperability)

[Definition: Bezeichnet einen Satz, der eine unverbindliche Empfehlung beschreibt, die dazu dient, die Wahrscheinlichkeit zu erhöhen, dass XML-Dokumente von existierenden SGML-Prozessoren verarbeitet werden können, die älter sind als der WebSGML Adaptations Annex to ISO 8879.]


2 Dokumente

[Definition: 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 physische Struktur. Physisch 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 Verarbeitungsanweisungen, die innerhalb des Dokuments durch explizites Markup ausgezeichnet sind. Logische und physikalische Strukturen müssen korrekt verschachtelt sein, wie in 4.3.2 Wohlgeformte analysierte Entities beschrieben.


2.1 Wohlgeformte XML-Dokumente

[Definition: Ein textuelles Objekt ist ein wohlgeformtes XML-Dokument, wenn:]

  1. es als Gesamtheit betrachtet zu der mit document bezeichneten Produktion passt,

  2. es alle Wohlgeformtheitsbeschränkungen dieser Spezifikation erfüllt und

  3. jedes seiner parsed Entities, welches direkt oder indirekt referenziert wird, wohlgeformt ist.


Document
[1]    document    ::=    prolog element Misc*

Dass ein Dokument zur document-Produktion passt, impliziert:

  1. Es enthält ein oder mehrere Elemente.

  2. [Definition: 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 sich das Start-Tag im Kontext eines anderen Elements befindet, dann befindet sich das End-Tag im Kontext des selben Elements. Einfacher ausgedrückt: Die Elemente, begrenzt durch Start- und End-Tag, sind korrekt ineinander verschachtelt.

[Definition: Als eine Konsequenz daraus gilt, dass für jedes Element k, das nicht die Wurzel ist, ein anderes Element v existiert, so dass 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

[Definition: Ein analysiertes Entity enthält Text, eine Folge von Zeichen, die entweder Markup oder Zeichendaten darstellen.] [Definition: Ein Zeichen (character) ist eine atomare Einheit von Text gemäß der Spezifikation in ISO/IEC 10646 [ISO/IEC 10646] (siehe auch [ISO/IEC 10646-2000]). Gültige Zeichen sind Tab (Tabulator), Carriage Return (Wagenrücklauf), Line Feed (Zeilenvorschub) sowie die gültigen Zeichen von Unicode und ISO/IEC 10646. Die Versionen der Normen, die in A.1 Normative Referenzen genannt sind, waren gültig als dieser Text geschrieben wurde. Neue Zeichen können diesen Normen durch Erweiterungen oder neue Auflagen hinzugefügt werden. Folglich müssen XML-Prozessoren jedes dieser Zeichen innerhalb der Regel für Char akzeptieren.Von der Verwendung von »Kompatibilitätszeichen« (compatibility characters), wie sie in Abschnitt 6.8 von [Unicode] (siehe auch D21 in Abschnitt 3.6 von [Unicode3]) definiert werden, wird abgeraten.]


Zeichenbereich
[2]    Char    ::=    #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] /* jedes Unicode-Zeichen, ausgenommen die Ersatzblöcke FFFE und FFFF. */

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 Zeichenkodierung in Entities, 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.


Leerraum
[3]    S    ::=    (#x20 | #x9 | #xD | #xA)+

Zeichen sind aus Gründen der Bequemlichkeit als Buchstaben, Ziffern und andere Zeichen klassifiziert.Ein Buchstabe besteht aus einem führenden alphabetischen oder Silbenzeichen oder aus einem ideografischen Zeichen. Die vollständige Definition der einzelnen Zeichen in jeder Klasse ist in B Zeichenklassen aufgeführt.

[Definition: 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')) passt, sind für die Standardisierung in dieser oder einer zukünftigen Version dieser Spezifikation reserviert.

Anmerkung:

Die Empfehlung »Namensräume in XML« [XML Names] weist Namen, die den Doppelpunkt enthalten, eine Bedeutung zu. Deshalb sollten Autoren den Doppelpunkt in XML-Namen zu keinem anderem Zweck als den Namensräumen verwenden. XML-Prozessoren müssen den Doppelpunkt aber als Zeichen für Namen akzeptieren.

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


Namen und Token
[4]    NameChar    ::=    Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar | Extender
[5]    Name    ::=    (Letter | '_' | ':') (NameChar)*
[6]    Names    ::=    Name (S Name)*
[7]    Nmtoken    ::=    (NameChar)+
[8]    Nmtokens    ::=    Nmtoken (S Nmtoken)*

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, dass ein SystemLiteral analysiert (parsed) werden kann, ohne nach Markup zu suchen.


Literale
[9]    EntityValue    ::=    '"' ([^%&"] | PEReference | Reference)* '"'
|  "'" ([^%&'] | PEReference | Reference)* "'"
[10]    AttValue    ::=    '"' ([^<&"] | Reference)* '"'
|  "'" ([^<&'] | Reference)* "'"
[11]    SystemLiteral    ::=    ('"' [^"]* '"') | ("'" [^']* "'")
[12]    PubidLiteral    ::=    '"' PubidChar* '"' | "'" (PubidChar - "'")* "'"
[13]    PubidChar    ::=    #x20 | #xD | #xA | [a-zA-Z0-9] | [-'()+,./:=?;!*#@$_%]

Anmerkung:

Auch wenn die EntityValue-Produktion die Definition eines Entity erlaubt, das nur aus einem einzelnen, literalen < besteht (z.B. <!ENTITY mylt "<">), wird dringend angeraten, dies zu vermeiden, da jede Referenz auf dieses Entity zu einer Wohlgeformheitsverletzung führt.


2.4 Zeichendaten und Markup

Text besteht aus miteinander vermengten Zeichendaten und Markup. [Definition: Markup besteht aus Start-Tags, End-Tags, Leeres-Element-Tags, Entity-Referenzen, Zeichenreferenzen, Kommentaren, Begrenzungen für CDATA-Abschnitte, Dokumenttyp-Deklarationen, Verarbeitungsanweisungen, XML-Deklarationen, Text-Deklarationen, und jeglichem Leerraum auf oberster Ebene des Dokument-Entity (d.h. außerhalb des Dokument-Elements und nicht innerhalb von irgendwelchem Markup.]

[Definition: 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 Verarbeitungsanweisung, oder eines CDATA-Abschnitts benutzt werden. 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 muss 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-Abschluss »]]>« 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.


Zeichendaten
[14]    CharData    ::=    [^<&]* - ([^<&]* ']]>' [^<&]*)

2.5 Kommentare

[Definition: 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 der Anwendung eine Möglichkeit einräumen, den Text eines Kommentars zu lesen, muss dies aber nicht tun. Zwecks Kompatibilität darf die Zeichenkette »--« (zwei Trennstriche) nicht innerhalb eines Kommentars erscheinen.] Parameter-Entity-Referenzen werden innerhalb von Kommentaren nicht erkannt.


Kommentare
[15]    Comment    ::=    '<!--' ((Char - '-') | ('-' (Char - '-')))* '-->'

Ein Beispiel für einen Kommentar:

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

Beachten Sie, dass die Grammatik nicht erlaubt, einen Kommentar durch ---> zu beenden. Das folgende Beispiel ist daher nicht wohlgeformt.

<!-- B+, B, or B --->

2.6 Verarbeitungsanweisungen

[Definition: Verarbeitungsanweisungen (Processing Instructions, PIs) erlauben Dokumenten, Anweisungen für Anwendungsprogramme zu enthalten.]


Verarbeitungsanweisungen
[16]    PI    ::=    '<?' PITarget (S (Char* - (Char* '?>' Char*)))? '?>'
[17]    PITarget    ::=    Name - (('X' | 'x') ('M' | 'm') ('L' | 'l'))

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-Notation-Mechanismus darf für die formale Deklaration von PI-Zielen benutzt werden. Parameter-Entity-Referenzen werden innerhalb von Verarbeitungsanweisungen nicht erkannt.


2.7 CDATA-Abschnitte

[Definition: 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 »]]>«.]


CDATA-Abschnitte
[18]    CDSect    ::=    CDStart CData CDEnd
[19]    CDStart    ::=    '<![CDATA['
[20]    CData    ::=    (Char* - (Char* ']]>' Char*))
[21]    CDEnd    ::=    ']]>'

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

[Definition: XML-Dokumente 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> 

Gleiches gilt hierfür:

<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 Nummerierungsschema 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 Markups 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. [Definition: 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 muss vor dem ersten Element im Dokument stehen.


Prolog
[22]    prolog    ::=    XMLDecl? Misc* (doctypedecl Misc*)?
[23]    XMLDecl    ::=    '<?xml' VersionInfo EncodingDecl? SDDecl? S? '?>'
[24]    VersionInfo    ::=    S 'version' Eq ("'" VersionNum "'" | '"' VersionNum '"')/* */
[25]    Eq    ::=    S? '=' S?
[26]    VersionNum    ::=    ([a-zA-Z0-9_.:] | '-')+
[27]    Misc    ::=    Comment | PI | S

[Definition: 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.]

[Definition: Eine Markup-Deklaration ist eine Elementtyp-Deklaration, eine Attributlisten-Deklaration, eine Entity-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 weitere Informationen siehe Abschnitt 4 Physische Strukturen.


Dokumenttyp-Definition
[28]    doctypedecl    ::=    '<!DOCTYPE' S Name (S ExternalID)? S? ('[' (markupdecl | DeclSep)* ']' S?)? '>' [GKB: Wurzel-Elementtyp]
[WGB: Externe Teilmenge]
/* */
[28a]    DeclSep    ::=    PEReference | S [WGB: PE zwischen Deklarationen]
/* */
[29]    markupdecl    ::=    elementdecl | AttlistDecl | EntityDecl | NotationDecl | PI | Comment [GKB: Ordentliche Deklaration/PE-Verschachtelung]
[WGB: PEs in interner Teilmenge]

Beachten Sie, dass es möglich ist, ein wohlgeformtes Dokument mit einer doctypedecl zu schreiben, das weder auf eine externe Teilmenge verweist, nocht eine interne Teilmenge enthält.

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 inkludiert wurden.

Parameter-Entity-Referenzen werden überall in der DTD erkannt (interne und externe Teilmengen sowie externe Paramter-Entities, mit Ausnahme von Literalen, Proeccsing Instructions, Kommentaren und dem Inhalt von ignorierten bedingten Abschnitten (siehe 3.4 Bedingte Abschnitte). Sie werden auch in literalen Entity-Werten erkannt. Die Verwendung von Parameter-Entities in der internen Teilmenge ist in der Form wie oben beschrieben eingeschränkt.

Gültigkeitsbeschränkung: Wurzel-Elementtyp

Der Name in der Dokumenttyp-Deklaration muss mit dem Elementtyp des Wurzel-Elements übereinstimmen.

Gültigkeitsbeschränkung: Ordentliche Deklaration/PE-Verschachtelung

Der Ersetzungstext von Parameter-Entities muss 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 in demselben 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.

Wohlgeformtheitsbeschränkung: Externe Teilmenge

Die externe Teilmenge, falls vorhanden, muss zur Produktion von extSubset passen.

Wohlgeformtheitsbeschränkung: PE zwischen Deklarationen

Der Ersetzungstext einer Parameter-Entity-Referenz in einer DeclSep muss zur Produktion extSubsetDecl passen.

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


Externe Teilmenge
[30]    extSubset    ::=    TextDecl? extSubsetDecl
[31]    extSubsetDecl    ::=    ( markupdecl | conditionalSect | DeclSep)* /* */

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

Ein Beispiel eines XML-Dokuments mit einer Dokumenttyp-Deklaration:

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

Der System-Identifier »hallo.dtd« gibt die Adresse (eine URI-Referenz) 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, dass 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. allein stehend), die als Teil der XML-Deklaration erscheinen darf, zeigt an, ob es Deklarationen gibt, die außerhalb des Dokument-Entity oder in Parameter-Entities stehen. [Definition: Eine externe Markup-Deklaration ist als Markup-Deklaration definiert, die in der externen Teilmenge oder in einem Parameter-Entity steht (extern oder intern; letzteres ist hier genannt, weil nicht-validierende interne Parameter-Entities nicht lesen müssen).]


Standalone-Dokumentdeklaration
[32]    SDDecl    ::=    S 'standalone' Eq (("'" ('yes' | 'no') "'") | ('"' ('yes' | 'no') '"')) [GKB: Standalone-Dokumentdeklaration]

In einer Standalone-Dokumentdeklaration zeigt der Wert »yes« (Ja), dass es keine externen Markup-Deklarationen gibt, die die Informationen beeinflussen, die vom XML-Prozessor an die Anwendung weitergereicht werden. Der Wert »no« (Nein) zeigt an, dass möglicherweise solche externen Markup-Deklarationen vorhanden sind. Beachten Sie, dass 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 muss 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 dass 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

Ein Beispiel für eine XML-Dekaration mit einer Standalone-Dokumentdeklaration:

<?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 muss stets alle Zeichen in einem Dokument, die nicht zum Markup gehören, an die Anwendung weiterreichen. Ein validierender XML-Prozessor muss die Anwendung außerdem darüber informieren, welche Leerraumzeichen im Inhalt eines Elements stehen.

Ein besonderes Attribut names xml:space kann einem Element zugewiesen werden, um anzuzeigen, dass Leerraum in diesem Element von Anwendungen erhalten werden soll. In gültigen Dokumenten muss dieses Attribut, wie jedes andere, deklariert werden, falls es benutzt wird. Bei der Deklaration muss es als Aufzählungstyp geschrieben werden, dessen Werte entweder »default« oder »preserve« oder beide sind. Zum Beispiel:

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

<!-- -->
<!ATTLIST pre xml:space (preserve) #FIXED 'preserve'>

Der Wert »default« zeigt an, dass die normale Leerraumbehandlung einer Anwendung für dieses Element akzeptabel ist. Der Wert »preserve« zeigt die Absicht an, dass 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, dass 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, müssen die Zeichen, die von einem XML-Prozessor an eine Anwendung weitergereicht werden, so sein, als ob der XML-Prozessor folgendermaßen arbeitet: Alle Zeilenumbrüche in externen analysierten Entities (einschließlich des Dokument-Entity) werden beim Einlesen vor dem Parsing dadurch normalisiert, dass sowohl die Zwei-Zeichenfolge #xD#xA als auch jedes #xD, das nicht einem #xA voran geht, in ein einzelnes #xA-Zeichen umgewandelt wird.


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 muss dieses Attribut, wie jedes andere, deklariert werden, falls es benutzt wird. Die Werte dieses Attributs sind Sprachencodes gemäß Definition in [IETF RFC 1766], Tags for the Identification of Languages, oder des Nachfolgers im IETF-Normierungsprozesses.

Anmerkung:

[IETF RFC 1766]-Marken bestehen aus einem zwei-buchstabigen Sprachen-Code gemäß Definition in [ISO 639], aus einem zwei-buchstabigen Länder-Code gemäß Definition in [ISO 3166] oder aus Sprachbezeichnern, die bei der Internet Assigned Numbers Authority [IANA-LANGCODES] registriert sind. Es wir erwartet, dass der Nachfolger von [IETF RFC 1766] drei-buchstabige Sprachen-Codes einführen wird, die gegenwärtig nicht durch [ISO 639] abgedeckt werden.

(Die Produktionsregeln 33 bis 38 wurden entfernt.)

Zum 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

[Definition: 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.


Element
[39]    element    ::=    EmptyElemTag
| STag content ETag [WGB: Elementtyp-Übereinstimmung]
[GKB: gültiges Element]

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

Wohlgeformtheitsbeschränkung: Elementtyp-Übereinstimmung

Der Name im End-Tag eines Elements muss 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 passt, wobei der Name zu dem Elementtyp passt und eine der folgenden Bedingungen gilt:

  1. Die Deklaration passt zu EMPTY, und das Element hat keinen Inhalt.

  2. Die Deklaration passt 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 dem Start-Tag und dem ersten KindElement, zwischen Kind-Elementen oder zwischen dem letzten Kind-Element und dem End-Tag. Beachten Sie, dass ein CDATA-Abschnitt, der nur Leerraum enthält, nicht zum Nicht-Terminal S passt und deshalb nicht an dieser Stelle auftreten darf.

  3. Die Deklaration passt zu Mixed, und der Inhalt besteht aus Zeichendaten und Kind-Elementen, deren Typen zu den Namen im Inhaltsmodell passen.

  4. Die Deklaration passt zu ANY, und die Typen aller Kind-Elemente sind deklariert worden.


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

[Definition: Der Beginn jedes nicht-leeren XML-Elements ist durch ein Start-Tag markiert.]


Start-Tag
[40]    STag    ::=    '<' Name (S Attribute)* S? '>' [WGB: Eindeutige Attributspezifikation]
[41]    Attribute    ::=    Name Eq AttValue [GKB: Typ des Attributwertes]
[WGB: Keine externen Entity-Referenzen]
[WGB: Kein < in Attribut-Werten]

Der Name in den Start- und End-Tags ist derTyp des Elements. [Definition: Die Name-AttValue-Paare werden als Attributspezifikation des Elements bezeichnet], [Definition: wobei der Name in jedem Paar der Attribut-Name] und [Definition: der Inhalt des AttValue (der Text zwischen den '- oder "-Zeichen) der Attribut-Wert ist.]Beachten Sie, dass die Reihenfolge von Attributspezifikationen in einem Start-Tag oder in einem Leeres-Element-Tag nicht entscheidend 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 muss deklariert worden sein. Der Wert muss von dem Typ sein, der für ihn deklariert wurde (siehe dazu 3.3 Attributlisten-Deklaration).

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.

Ein Beispiel für einen Start-Tag:

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

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


End-Tag
[42]    ETag    ::=    '</' Name S? '>'

Ein Beispiel eines End-Tags:

</termdef>

[Definition: Der Text zwischen Start- und End-Tag wird der Inhalt des Elements genannt.]


Inhalt von Elementen
[43]    content    ::=    CharData? ((element | Reference | CDSect | PI | Comment) CharData?)* /* */

[Definition: Ein Element ohne Inhalt heißt leer.] Wenn ein Element leer ist, dann muss es entweder durch einen Start-Tag, auf den unmittelbar ein End-Tag folgt, oder durch ein Leeres-Element-Tag dargestellt werden. [Definition: Ein Leeres-Element-Tag hat eine besondere Form:]


Leeres-Element-Tag
[44]    EmptyElemTag    ::=    '<' Name (S Attribute)* S? '/>' [WGB: Eindeutige Attributspezifikation]

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 sollte das Leeres-Element-Tag für Elemente benutzt werden, die als EMPTY deklariert sind, und nur für solche.

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.

[Definition: Eine Elementtyp-Deklaration hat folgende Form:]


Elementtyp-Deklaration
[45]    elementdecl    ::=    '<!ELEMENT' S Name S contentspec S? '>' [GKB: Eindeutige Elementtyp-Deklarationen]
[46]    contentspec    ::=    'EMPTY' | 'ANY' | Mixed | children

Hierbei bezeichnet der 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

[Definition: 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.][Definition: 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:


Modelle für Element-Inhalt
[47]    children    ::=    (choice | seq) ('?' | '*' | '+')?
[48]    cp    ::=    (Name | choice | seq) ('?' | '*' | '+')?
[49]    choice    ::=    '(' S? cp ( S? '|' S? cp )+ S? ')' /* */
/* */
[GKB: Ordentliche Gruppierung/PE-Verschachtelung]
[50]    seq    ::=    '(' S? cp ( S? ',' S? cp )* S? ')' /* */
[GKB: Ordentliche Gruppierung/PE-Verschachtelung]

Hierbei ist Name der Typ eines Elements, das als child 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 (*) bzw. keinmal oder einmal (?) auftreten dürfen. Das Fehlen eines solchen Operators bedeutet, dass das Element oder der Inhaltsteil genau einmal erscheinen muss. Diese Syntax und Bedeutung sind identisch zu denen, die in den Produktionen dieser Spezifikation Verwendung finden.

Der Inhalt eines Elements passt 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 passt. Zwecks Kompatibilität ist es ein Fehler, wenn ein Element im Dokument zu mehr als einem Elementtyp im Inhaltsmodell passt. Für weitere Informationen siehe Abschnitt E Deterministische Inhaltsmodelle.

Gültigkeitsbeschränkung: Ordentliche Gruppierung/PE-Verschachtelung

Der Ersetzungstext von Parameter-Entities muss 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 in demselben Ersetzungstext enthalten sein.

Zwecks Zusammenarbeit gilt: Wenn eine Parameter-Entity-Referenz in einem choice-, seq- oder Mixed-Konstrukt erscheint, dann sollte ihr Ersetzugstext mindestens ein nicht leeres Zeichen (kein Leerraum) enthalten, und weder das erste noch das letzte nicht leere Zeichen 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

[Definition: Ein Elementtyp 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.


Deklaration von gemischtem Inhalt
[51]    Mixed    ::=    '(' S? '#PCDATA' (S? '|' S? Name)* S? ')*'
| '(' S? '#PCDATA' S? ')' [GKB: Ordentliche Gruppierung/PE-Verschachtelung]
[GKB: Keine doppelten Typen]

Dabei bezeichnet Name den Elementtyp, der als Kind erscheinen darf. Das Schlüsselwort #PCDATA leitet sich historisch von dem Ausdruck »parsed character data« ab.

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

Attributlisten-Deklaration werden verwendet, um Name-Wert-Paare mit Elementen zu verknüpfen. Attribut-Spezifikationen dürfen ausschließlich innerhalb von Start-Tags und Leeres-Element-Tagserscheinen. Folglich ist die Produktion zu deren Erkennung im Abschnitt 3.1 Start-Tags, End-Tags und Leeres-Element-Tags 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.

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


Attributlisten-Deklaration
[52]    AttlistDecl    ::=    '<!ATTLIST' S Name AttDef* S? '>'
[53]    AttDef    ::=    S Name S AttType S DefaultDecl

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 in einer Attributlisten-Deklaration 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. Die Gültigkeitsbeschränkungen, die in der Grammatik angegeben werden, werden angewendet, nachdem der Attributwert wie in 3.3 Attributlisten-Deklaration beschrieben normalisiert wurde.


Attributtypen
[54]    AttType    ::=    StringType | TokenizedType | EnumeratedType
[55]    StringType    ::=    'CDATA'
[56]    TokenizedType    ::=    'ID' [GKB: ID]
[GKB: Eine ID pro Elementtyp]
[GKB: Vorgabe für ID-Attribute]
| 'IDREF' [GKB: IDREF]
| 'IDREFS' [GKB: IDREF]
| 'ENTITY' [GKB: Entity Name]
| 'ENTITIES' [GKB: Entity Name]
| 'NMTOKEN' [GKB: Name-Token]
| 'NMTOKENS' [GKB: Name-Token]

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

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


Aufzählungs-Attributtypen
[57]    EnumeratedType    ::=    NotationType | Enumeration
[58]    NotationType    ::=    'NOTATION' S '(' S? Name (S? '|' S? Name)* S? ')' [GKB: Notation-Attribute]
[GKB: Eine Notation pro Elementtyp]
[GKB: Keine Notation für leere Elemente]
[59]    Enumeration    ::=    '(' S? Nmtoken (S? '|' S? Nmtoken)* S? ')' [GKB: Aufzählung]

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: Eine Notation pro Elementtyp

Für keinen Elementtyp darf mehr als ein NOTATION-Attribut spezifiziert werden.

Gültigkeitsbeschränkung: Keine Notation für leere Elemente

Zwecks Kompatibilität darf ein Attribut vom Wert NOTATION nicht für ein Element deklariert werden, das als EMPTY deklariert ist.

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 muss und, falls nicht, wie ein XML-Prozessor bei einem im Dokument fehlenden Attribut reagieren sollte.


Attribut-Vorgaben
[60]    DefaultDecl    ::=    '#REQUIRED' | '#IMPLIED'
| (('#FIXED' S)? AttValue) [GKB: Notwendiges Attribut]
[GKB: korrekte Attribut-Vorgabe]
[WGB: Kein < in Attribut-Werten]
[GKB: Feste Attribut-Vorgabe]

In einer Attribut-Deklaration bedeutet #REQUIRED (notwendig), dass das Attribut immer angegeben werden muss und #IMPLIED (impliziert), dass es keinen Vorgabewert gibt.[Definition: Wenn die Deklaration weder #REQUIRED noch #IMPLIED ist, enthält derAttValue-Wert den deklarierten Vorgabe-Wert. Das Schlüsselwort #FIXED (fest) zeigt an, dass das Attribut stets den Vorgabewert haben muss. 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 muss das Attribut für alle Elemente des in der Attributlisten-Deklaration genannten Typs angegeben werden.

Gültigkeitsbeschränkung: korrekte Attribut-Vorgabe

Der deklarierte Vorgabewert muss 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.

Beispiele 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, muss der XML-Prozessor ihn durch Anwendung des nachfolgenden Algorithmus normalisieren. Alternativ kann er eine andere Methode anwenden, so dass der Wert, der an die Anwendung weitergereicht wird, dem entspricht, den folgender Algorithmus erzeugt.

  1. Alle Zeilenumbrüche müssen beim Einlesen zu #xA, wie in 2.11 Behandlung des Zeilenendes beschrieben, normalisiert worden sein, so dass der Rest dieses Algorithmus auf dem in dieser Weise normalisierten Text arbeiten kann.

  2. Beginne mit einem normalisierten Wert, bestehend aus der leeren Zeichenkette.

  3. Für jedes Zeichen, Entity-Referenz oder Zeichenreferenz im nicht-normalisierten Attribut-Wert, beginnend mit dem ersten und fortlaufend bis zum letzten, tue follgendes:

    • Für jede Zeichenreferenz hänge das referenzierte Zeichen an den normalisierten Wert an.

    • Für eine Entity-Referenz wende Schritt 3 dieses Algorithmus auf den Ersetzungstext des Entity an.

    • Für ein Leerraum-Zeichen (#x20, #xD, #xA, #x9) hänge ein Leerzeichen (#x20) an den normalisierten Wert an.

    • Für ein anderes Zeichen hänge das Zeichen an den normalisierten Wert an.

Falls der deklarierte Wert nicht CDATA ist, muss 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).

Beachten Sie, dass falls der nicht-normalisierte Attributwert eine Zeichenreferenz zu einem anderen Leerraumzeichen als dem Leerzeichen (#x20) enthält, der normalisierte Wert dann das referenzierte Zeichen selbst (#xD, #xA oder #x9) enthält. Dies steht im Gegensatz zu dem Fall, dass der nicht-normalisierte Wert ein Leeraumzeichen (keine Referenz) enthält, die durch ein Leerzeichen (#x20) im normalisierten Wert ersetzt wird; ebenfalls im Gegensatz zu dem Fall, dass der nicht-normalisierte Wert eine Entity-Referenz enthält, deren Ersetzungstext ein Leerraumzeichen enthält; durch die rekursive Verarbeitung wird das Leerraumzeichen durch ein Leerzeichen (#x20) im normalisierten Wert ersetzt.

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

Es folgen Beispiel für Attribut-Normalisierung. Gegeben seien die folgenden Deklarationen:

<!ENTITY d "&#xD;">
<!ENTITY a "&#xA;">
<!ENTITY da "&#xD;&#xA;">

Die Attributspezifikationen in der linken Spalte (unten) würden zu der Zeichenfolge in der mittleren Spalte normalisiert, falls a als NMTOKENS deklariert wäre, und zu denen in der rechten Spalte, falls a als CDATA deklariert wäre.

Attributspezifikation a ist NMTOKENS a ist CDATA
a="

xyz"
x y z #x20 #x20 x y z
a="&d;&d;A&a;&a;B&da;"
A #x20 B #x20 #x20 A #x20 #x20 B #x20 #x20
a=
"&#xd;&#xd;A&#xa;&#xa;B&#xd;&#xa;"
#xD #xD A #xA #xA B #xD #xA #xD #xD A #xA #xA B #xD #xD

Beachten Sie, dass das letzte Beispiel ungültig (aber wohlgeformt) ist, falls a als Typ NMTOKENS deklariert ist.


3.4 Bedingte Abschnitte

[Definition: 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.]


Bedingte Abschnitte
[61]    conditionalSect    ::=    includeSect | ignoreSect
[62]    includeSect    ::=    '<![' S? 'INCLUDE' S? '[' extSubsetDecl ']]>' /* */
[GKB: Ordentliche Verschachtelung von bedingten Abschnitten und PEs]
[63]    ignoreSect    ::=    '<![' S? 'IGNORE' S? '[' ignoreSectContents* ']]>' /* */
[GKB: Ordentliche Verschachtelung von bedingten Abschnitten und PEs]
[64]    ignoreSectContents    ::=    Ignore ('<![' ignoreSectContents ']]>' Ignore)*
[65]    Ignore    ::=    Char* - (Char* ('<![' | ']]>') Char*)

Gültigkeitsbeschränkung: Ordentliche Verschachtelung von bedingten Abschnitten und PEs

Falls einer der Teile »<![«, »[« oder »]]>« eines bedingten Abschnitts im Ersetzungstext eines Parameter-Entities enthalten ist, dann müssen alle Teile im selben Ersetzungstext enthalten sein.

So wie die internen und externen Teilmengen der DTD darf auch ein bedingter Abschnitt eine oder mehrere vollständige Deklarationen, Kommentare, Verarbeitungsanweisungen 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. 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. Der Inhalt eines ignorierten bedingten Abschnitts wird analysiert (parsed), indem all Zeichen nach der Klammer »[«, die auf das Schlüsselwort (IGNORE) folgt, ignoriert werden, mit Ausnahme der Start- und Endzeichen (»<![« und »]]>«) des eingebetteten bedingten Abschnitts, bis das passende Endzeichen gefunden wird. Parameter-Entity-Referenzen werden während dieses Vorgangs nichts erkannt.

Wenn das Schlüsselwort des bedingten Abschnitts ein Parameter-Entity ist, dann muss 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 Physische Strukturen

[Definition: 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 und der externen Teilmenge der DTD) durch einen Entity-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. [Definition: Der Inhalt eines analysierten Entity wird als sein Ersetzungstext bezeichnet. Dieser Text gilt als integraler Bestandteil des Dokuments.]

[Definition: Ein nicht-analysiertes Entity ist eine Ressource, deren Inhalt Text sein kann oder auch nicht, und falls es sich um Text handelt, etwas aderes als XML sein darf. 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 muss lediglich gewährleistet sein, dass 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.

[Definition: Allgemeine Entities dienen der Verwendung innerhalb des Dokumentinhalts. In dieser Spezifikation werden allgemeine Entities oft unpräzise Entity genannt, sofern dies nicht zu Mehrdeutigkeit führt.] [Definition: 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 dem gleichen Namen sind zwei verschiedene Entities.


4.1 Zeichen- und Entity-Referenzen

[Definition: 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.]


Zeichenreferenz
[66]    CharRef    ::=    '&#' [0-9]+ ';'
| '&#x' [0-9a-fA-F]+ ';' [WGB: Erlaubtes Zeichen]

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.

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


Entity-Referenz
[67]    Reference    ::=    EntityRef | CharRef
[68]    EntityRef    ::=    '&' Name ';' [WGB: Entity deklariert]
[GKB: Entity deklariert]
[WGB: Analysiertes Entity]
[WGB: Keine Rekursion]
[69]    PEReference    ::=    '%' Name ';' [GKB: Entity deklariert]
[WGB: Keine Rekursion]
[WGB: In der DTD]

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'«, im Falle einer Entity-Referenz, die nicht innerhalb der externen Teilmenge oder eines Parameter-Entity auftritt, muss der Name in der Entity-Referenz zu dem in einer Entity-Deklaration passen, die nicht innerhalb der externen Teilmenge oder eines Parameter-Entity auftritt. Eine Ausnahme ist, dass wohlgeformte Dokumente keine der folgenden Entities deklarieren müssen: amp, lt, gt, apos, quot. Die Deklaration eines allgemeinen Entity muss vor einer Referenz erfolgen, die im Vorgabewert in einer Attributlisten-Deklaration steht.

Beachten Sie, dass 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, dass ein Entity nur dann deklariert sein muss, 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'«muss der in der Entity-Referenz angegebene Name zu dem in der Deklaration passen. Zwecks Zusammenarbeit sollten gültige Dokumente die Entities amp, lt, gt, apos, quot wie in 4.6 Vordefinierte Entities definieren. Die Deklaration eines Parameter-Entity muss vor einer Referenz darauf erfolgen. Ebenso muss die Deklaration eines allgemeinen Entity vor einer Attributlisten-Deklaration, die einen Vorgabewert mit einer direkten oder indirekten Referenz zu jenem allgemeinen Entity enthält, erfolgen.

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

[Definition: Entities werden auf folgende Weise deklariert:]


Entity-Deklarationen
[70]    EntityDecl    ::=    GEDecl | PEDecl
[71]    GEDecl    ::=    '<!ENTITY' S Name S EntityDef S? '>'
[72]    PEDecl    ::=    '<!ENTITY' S '%' S Name S PEDef S? '>'
[73]    EntityDef    ::=    EntityValue | (ExternalID NDataDecl?)
[74]    PEDef    ::=    EntityValue | ExternalID

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

[Definition: 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, dass eine gewisse Verarbeitung von Entity- und Zeichenreferenzen im literalen Entity-Wert notwendig sein kann, um den korrekten Ersetzungstext zu erzeugen; siehe 4.5 Konstruktion des Ersetzungstextes von internen Entities.

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

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


Deklaration von Externen Entities
[75]    ExternalID    ::=    'SYSTEM' S SystemLiteral
| 'PUBLIC' S PubidLiteral S SystemLiteral
[76]    NDataDecl    ::=    S 'NDATA' S Name [GKB: Deklarierte Notation]

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 muss mit dem deklarierten Namen einer Notation übereinstimmen.

[Definition: Das SystemLiteral wird der System-Identifier des Entity genannt. Es handelt sich um eine URI-Referenz (gemäß Definition in [IETF RFC 2396], aktualisiert durch [IETF RFC 2732]), die dazu gedacht ist, aufgelöst zu werden, damit der XML-Prozessor Eingabedaten bekommt, um den Ersetzungstext des Entity zu erzeugen.] Es ist ein Fehler, wenn ein fragmentarischer Identifier (einer, der mit einem # beginnt) Teil eines System-Identifier ist. Soweit keine Informationen, die außerhalb des Rahmens dieser Spezifikation liegen, etwas anderes aussagen (z.B. ein besonderes XML-Element, das von einer bestimmten DTD definiert wird, oder eine Verarbeitungsanweisung, 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.

URI-Referenzen verlangen eine Kodierung und einen Schutz bestimmter Zeichen. Die nicht erlaubten Zeichen umfassen alle nicht-ASCII-Zeichen, sowie die ausgeschlossenen Zeichen, die in Abschnitt 2.4 von [IETF RFC 2396] aufgeführt sind. Davon ausgenommen sind das Doppelkreuz (#) und das Prozentzeichen (%), sowie die eckigen Klammern, die durch [IETF RFC 2732] wieder zugelassen sind. Nicht erlaubte Zeichen müssen in folgender Weise geschützt werden:

  1. Jedes nicht erlaubte Zeichen wird nach UTF-8 [IETF RFC 2279] als ein oder mehr Bytes konvertiert.

  2. Alle Oktette, die einem nicht erlaubten Zeichen entsprechen, werden durch das Verfahren für URI-Escape-Sequenzen geschützt (d.h. Konvertierung in %HH, wobei HH für die hexadezimale Notation des Byte-Werts steht.

  3. Das ursprüngliche Zeichen wird durch die entstehende Zeichenfolge ersetzt.

[Definition: 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 eine alternative URI-Referenz zu erzeugen. Falls der Prozessor dazu nicht in der Lage ist, muss er die als System-Identifier angegebene URI-Referenz 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 sowie 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 sollten jeweils mit einer Text-Deklaration beginnen.


Text-Deklaration
[77]    TextDecl    ::=    '<?xml' VersionInfo? EncodingDecl S? '?>'

Die Text-Deklaration muss 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.Die Text-Deklaration in einem externen analysierten Entity gilt nicht als Teil des Ersetzungstexts.


4.3.2 Wohlgeformte analysierte Entities

Das Dokument-Entity ist wohlgeformt, wenn es zur Produktion document passt. Ein externes, allgemeines, analysiertes Entity ist wohlgeformt, wenn es zur Produktion extParsedEnt passt. Alle externen Parameter-Entities sind per definitionem wohlgeformt.


Wohlgeformte, extern-analysierte Entities
[78]    extParsedEnt    ::=    TextDecl? content

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

Eine Konsequenz der Wohlgeformtheit von Entities ist, dass die logische und physikalische Struktur eines XML-Dokuments korrekt verschachtelt ist. Kein Start-Tag, End-Tag, Leeres-Element-Tag, Element, Kommentar, Verarbeitungsanweisung, Zeichen- oder Entity-Referenz 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 sowohl in UTF-8- als auch UTF-16-Kodierung zu lesen. Die Ausdrücke »UTF-8« und »UTF-16« in dieser Spezifikation beziehen sich nicht auf Zeichenkodierungen mit anderen Bezeichnungen, selbst wenn diese Kodierungen oder Bezeichnungen sehr ähnlich zu UTF-8 oder UTF-16 sind.

Entities in UTF-16-Kodierung müssen mit einer Byte-Order-Markierung beginnen, die in Annex F von [ISO/IEC 10646], Annex H von [ISO/IEC 10646-2000], Abschnitt 2.4 von [Unicode] und Abschnitt 2.7 von [Unicode3] (das ZERO WIDTH NO-BREAK SPACE-Zeichen, #xFEFF) beschrieben sind. 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 muss, ist es offensichtlich, dass andere Kodierungen überall in der Welt benutzt werden. Deshalb kann es wünschenswert sein, dass ein XML-Prozessor solche Entities lesen und benutzen kann. Bei Abwesenheit einer externen Information über die Zeichenkodierung (wie zum Beispiel MIME-Kopfzeilen), müssen analysierte Entities, die in einer anderen Kodierung als UTF-8 und UTF-16 gespeichert sind, mit einer Text-Deklaration beginnen, die eine Kodierungsdeklaration enthält.


Kodierungsdeklaration
[80]    EncodingDecl    ::=    S 'encoding' Eq ('"' EncName '"' | "'" EncName "'" )
[81]    EncName    ::=    [A-Za-z] ([A-Za-z0-9._] | '-')* /* Kodierungsnamen enthalten ausschließlich lateinische Buchstaben */

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-n« (wobei n die Nummer des Teils ist) 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. Es wird empfohlen, dass andere als die genannten Zeichenkodierungen, die bei der Internet Assigned Numbers Authority [IANA-CHARSETS] (als Zeichensatz, charsets) registriert sind, mit ihrem registrierten Namen genannt werden. Andere Kodierungen sollten Namen benutzen, die mit einem »x-«Präfix versehen sind. XML-Prozessoren sollten Namen von Zeichenkodierungen case-insensitive behandeln. Des weiteren sollten sie einen bei der IANA registrierten Namen entweder als eine bei der IANA unter diesem Namen registrierte Kodierung oder als unbekannt behandeln (Prozessoren sind selbstverständlich nicht verpflichtet, alle IANA-registrierten Kodierungen zu unterstützen).

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 ein Entity, das weder mit einer Byte-Order-Markierung noch mit einer Kodierungsdeklaration beginnt, eine andere Kodierung als UTF-8 benutzt. Beachten Sie, dass wegen der Tatsache, dass ASCII eine Teilmenge von UTF-8 ist, ASCII-Entities nicht unbedingt eine Kodierungsdeklaration brauchen.

Es ist ein kritischer Fehler, wenn eine TextDecl an einer anderen Stelle steht als am Anfang eines externen Entity.

Es ist ein kritischer Fehler, wenn ein XML-Prozessor ein Entity in einer Kodierung bekommt, die er nicht verarbeiten kann. Es ist ein kritischer Fehler, wenn für ein XML-Entity (durch Vorgabewert, Kodierungsdeklaration oder Protokoll) eine bestimmte Kodierung angegeben wird, das Entity jedoch Oktett-Folgen enthält, die in dieser Kodierung nicht zulässig sind. Ebenso ist es ein kritischer Fehler, wenn ein XML-Entity keine Kodierungsdeklaration enthält und sein Inhalt kein gültiges UTF-8 oder UTF-16 ist.

Beispiele für Textdeklarationen, die Kodierungsdeklarationen enthalten:

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

4.4 Behandlung von Entities und Referenzen durch einen XML-Prozessor

Die folgende Tabelle fasst 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, AttValue, PI, Comment, SystemLiteral, PubidLiteral oder dem Inhalt eines ignorierten bedingten Abschnitts (siehe 3.4 Bedingte Abschnitte).

Entity-Typ Zeichen
Parameter intern, allgemein extern analysiert, allgemein nicht-analysiert
Referenz im Inhalt Nicht erkannt Inkludiert Inkludiert, falls validierend Verboten Inkludiert
Referenz im Attribut-Wert Nicht erkannt In Literal inkludiert Verboten Verboten Inkludiert
Auftreten als Attribut-Wert Nicht erkannt Verboten Verboten Informieren Nicht erkannt
Referenz im Entity-Wert In Literal inkludiert Durchgereicht Durchgereicht Verboten Inkludiert
Referenz in der DTD Als PE inkludiert Verboten Verboten Verboten Verboten

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 (content) 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

[Definition: 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. (Die Zeichenkette »AT&amp;T;« expandiert zu »AT&T;« und das übrig gebliebene 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 muss der Prozessor dessen Ersetzungstext inkludieren. Wenn es sich um ein externes Entity handelt und der Prozessor gar nicht versucht, das XML-Dokument zu validieren, darf der Prozessor den Ersetzungtext inkludieren, er muss aber nicht. Wenn ein nicht-validierender Prozessor einen Ersetzungstext nicht inkludiert, muss er die Anwendung darüber informieren, dass er auf ein Entity gestoßen ist, dieses aber nicht eingelesen hat.

Diese Regel basiert auf der Erkenntnis, dass 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, dass 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 muss 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, dass er in sich geschlossene grammatikalische Token der DTD enthält. Dieses Verhalten gilt nicht für Parameter-Entity-Referenzen innerhalb von Entity-Werten; diese werden in 4.4.5 In Literal inkludiert beschrieben.


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. [Definition: Der literale Entity-Wert ist die in Anführungszeichen eingeschlossene Zeichenkette in der Entity-Deklaration, korrespondierend zu dem Nicht-Terminal EntityValue.] [Definition: 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, muss den Ersetzungstext von jedem Parameter-Entity, das referenziert wird, enthalten. Im Falle von Zeichenreferenzen muss 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;" >

Dann ist der Ersetzungstext für das Entity »book« Folgendes:

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 D Expansion von Entity- und Zeichenreferenzen.


4.6 Vordefinierte Entities

[Definition: Entity- und Zeichenreferenzen können beide benutzt werden, um die öffnende spitze Klammer, das et-Zeichen und andere Begrenzungen zu schützen (escape). 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 Entities lt oder amp deklariert werden, dann müssen sie als interne Entities deklariert werden, deren Ersetzungstext eine Zeichenreferenz auf die entsprechenden Zeichen (kleiner-als oder et-zeichen) ist, die zu schützen sind. Das doppelte Schützen ist für diese Entities notwendig, damit Referenzen darauf ein wohlgeformtes Ergebnis liefern. Wenn die Entities gt, apos oder quot deklariert werden, dann müssen sie als interne Entities deklariert werden, deren Ersetzungstext das einzelne zu schützende Zeichen ist (oder eine Zeichenreferenz auf dieses Zeichen; das doppelte Schützen ist hier nicht notwendig, aber ungefährlich). Zum Beispiel:

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

4.7 Notation-Deklarationen

[Definition: 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 Verarbeitungsanweisung richtet.]

[Definition: 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.]


Notation-Deklarationen
[82]    NotationDecl    ::=    '<!NOTATION' S Name S (ExternalID | PublicID) S? '>' [GKB: Eindeutiger Notation-Name]
[83]    PublicID    ::=    'PUBLIC' S PubidLiteral

Gültigkeitsbeschränkung: Eindeutiger Notation-Name

Ein Name darf nur für eine Notation-Deklaration verwendet werden.

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

[Definition: 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 lassen sich in zwei Kategorien einordnen: 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.

[Definition: Validierende Prozessoren müssen (benutzeroptional) 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. [Definition: 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.] Mit Ausnahme von standalone="yes" dürfen sie 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 muss 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 muss 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 Behandlung von Entities und Referenzen durch einen XML-Prozessor.

  • 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ässlichkeit 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 Grammatik definiert ein Symbol in der folgenden Form:

Symbol ::= Ausdruck

Symbole beginnen mit einem großen Anfangsbuchstaben, falls sie das Startsymbol einer regulären Sprache 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 wobei N eine ganze Hexadezimalzahl ist. Dieser Ausdruck passt 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]

passt zu jedem Char mit einem Code innerhalb und inklusive des/der angegebenen Intervalle(s).

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

passt zu jedem Char mit einem der aufgezählten Werte. Aufzählungen und Intervalle können innerhalb eines Klammerpaares kombiniert werden.

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

passt zu jedem Char außerhalb des Intervalls.

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

passt zu jedem Char, das nicht zu den genannten gehört. Aufzählungen und Intervalle verbotener Zeichen können innerhalb eines Klammerpaares kombiniert werden.

"string"

passt zu der literalen Zeichenkette, die innerhalb der doppelten Anführungszeichen angegeben ist.

'string'

passt zu der literalen Zeichenkette, die innerhalb der einfachen Anführungszeichen 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)

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

A?

passt zu A oder nichts; optionales A.

A B

passt zu A, gefolgt von B. Konkatenation hat Vorrang vor Alternative; folglich ist A B | C D identisch mit (A B) | (C D).

A | B

passt zu A oder B, aber nicht zu beidem.

A - B

passt zu jeder Zeichenkette, die zu A passt, aber nicht zu B.

A+

passt zu einfachem oder mehrfachem Vorkommen von A. Dieser Operator hat Vorrang vor Alternative; folglich ist A+ | B+ identisch mit (A+) | (B+).

A*

passt zu null-, ein- oder mehrfachem Vorkommen von A. Dieser Operator hat Vorrang vor Alternative; folglich ist A* | B* identisch mit (A*) | (B*).

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.


A Referenzen


A.1 Normative Referenzen

IANA-CHARSETS
(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. (Siehe http://www.ietf.org/rfc/rfc1766.txt)
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).
ISO/IEC 10646-2000
ISO (International Organization for Standardization). ISO/IEC 10646-1:2000. Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. [Geneva]: International Organization for Standardization, 2000.
Unicode
The Unicode Consortium. The Unicode Standard, Version 2.0. Reading, Mass.: Addison-Wesley Developers Press, 1996.
Unicode3
The Unicode Consortium. The Unicode Standard, Version 3.0. Reading, Mass.: Addison-Wesley Developers Press, 2000. ISBN 0-201-61633-5.

A.2 Weitere Referenzen

Aho/Ullman
Aho, Alfred V., Ravi Sethi, and Jeffrey D. Ullman. Compilers: Principles, Techniques, and Tools. Reading: Addison-Wesley, 1986, rpt. corr. 1988.
Berners-Lee et al.
Berners-Lee, T., R. Fielding, and L. Masinter. Uniform Resource Identifiers (URI): Generic Syntax and Semantics. 1997. (in Arbeit befindlich; Siehe Aktualisierungen von RFC1738.)
Brüggemann-Klein
Brüggemann-Klein, Anne. Formal Models in Document Processing. Habilitationsschrift. Faculty of Mathematics at the University of Freiburg, 1993. (Siehe ftp://ftp.informatik.uni-freiburg.de/documents/papers/brueggem/habil.ps.)
Brüggemann-Klein and Wood
Brüggemann-Klein, Anne, and Derick Wood. Deterministic Regular Languages. Universität Freiburg, Institut für Informatik, Bericht 38, Oktober 1991. Extended abstract in A. Finkel, M. Jantzen, Hrsg., STACS 1992, S. 173-184. Springer-Verlag, Berlin 1992. Lecture Notes in Computer Science 577. Full version titled One-Unambiguous Regular Languages in Information and Computation 140 (2): 229-253, February 1998.
Clark
James Clark. Comparison of SGML and XML. Siehe http://www.edition-w3c.de/TR/NOTE-sgml-xml-971215.
IANA-LANGCODES
(Internet Assigned Numbers Authority) Registry of Language Tags, ed. Keld Simonsen et al. (Siehe http://www.isi.edu/in-notes/iana/assignments/languages/)
IETF RFC2141
IETF (Internet Engineering Task Force). RFC 2141: URN Syntax, ed. R. Moats. 1997. (Siehe http://www.ietf.org/rfc/rfc2141.txt)
IETF RFC 2279
IETF (Internet Engineering Task Force). RFC 2279: UTF-8, a transformation format of ISO 10646, ed. F. Yergeau, 1998. (Siehe http://www.ietf.org/rfc/rfc2279.txt)
IETF RFC 2376
IETF (Internet Engineering Task Force). RFC 2376: XML Media Types. ed. E. Whitehead, M. Murata. 1998. (Siehe http://www.ietf.org/rfc/rfc2376.txt)
IETF RFC 2396
IETF (Internet Engineering Task Force). RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax. T. Berners-Lee, R. Fielding, L. Masinter. 1998. (Siehe http://www.ietf.org/rfc/rfc2396.txt)
IETF RFC 2732
IETF (Internet Engineering Task Force). RFC 2732: Format for Literal IPv6 Addresses in URL's. R. Hinden, B. Carpenter, L. Masinter. 1999. (Siehe http://www.ietf.org/rfc/rfc2732.txt)
IETF RFC 2781
IETF (Internet Engineering Task Force). RFC 2781: UTF-16, an encoding of ISO 10646, ed. P. Hoffman, F. Yergeau. 2000. (Siehe http://www.ietf.org/rfc/rfc2781.txt)
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 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.
WEBSGML
ISO (International Organization for Standardization). ISO 8879:1986 TC2. Information technology -- Document Description and Processing Languages. [Geneva]: International Organization for Standardization, 1998. (Siehe http://www.sgmlsource.com/8879rev/n0029.htm)
XML Names
Tim Bray, Dave Hollander, and Andrew Layman, editors. Namespaces in XML. Textuality, Hewlett-Packard, and Microsoft. World Wide Web Consortium, 1999. (Siehe http://www.edition-w3c.de/TR/REC-xml-names/)

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), ideografische Zeichen sowie kombinierte Zeichen (unter anderem gehören dazu diakritische Zeichen). Außerdem werden Ziffern (digits) und Erweiterungen (extenders) unterschieden.


Zeichen
[84]    Letter    ::=    BaseChar | Ideographic
[85]    BaseChar    ::=    [#x0041-#x005A] | [#x0061-#x007A] | [#x00C0-#x00D6] | [#x00D8-#x00F6] | [#x00F8-#x00FF] | [#x0100-#x0131] | [#x0134-#x013E] | [#x0141-#x0148] | [#x014A-#x017E] | [#x0180-#x01C3] | [#x01CD-#x01F0] | [#x01F4-#x01F5] | [#x01FA-#x0217] | [#x0250-#x02A8] | [#x02BB-#x02C1] | #x0386 | [#x0388-#x038A] | #x038C | [#x038E-#x03A1] | [#x03A3-#x03CE] | [#x03D0-#x03D6] | #x03DA | #x03DC | #x03DE | #x03E0 | [#x03E2-#x03F3] | [#x0401-#x040C] | [#x040E-#x044F] | [#x0451-#x045C] | [#x045E-#x0481] | [#x0490-#x04C4] | [#x04C7-#x04C8] | [#x04CB-#x04CC] | [#x04D0-#x04EB] | [#x04EE-#x04F5] | [#x04F8-#x04F9] | [#x0531-#x0556] | #x0559 | [#x0561-#x0586] | [#x05D0-#x05EA] | [#x05F0-#x05F2] | [#x0621-#x063A] | [#x0641-#x064A] | [#x0671-#x06B7] | [#x06BA-#x06BE] | [#x06C0-#x06CE] | [#x06D0-#x06D3] | #x06D5 | [#x06E5-#x06E6] | [#x0905-#x0939] | #x093D | [#x0958-#x0961] | [#x0985-#x098C] | [#x098F-#x0990] | [#x0993-#x09A8] | [#x09AA-#x09B0] | #x09B2 | [#x09B6-#x09B9] | [#x09DC-#x09DD] | [#x09DF-#x09E1] | [#x09F0-#x09F1] | [#x0A05-#x0A0A] | [#x0A0F-#x0A10] | [#x0A13-#x0A28] | [#x0A2A-#x0A30] | [#x0A32-#x0A33] | [#x0A35-#x0A36] | [#x0A38-#x0A39] | [#x0A59-#x0A5C] | #x0A5E | [#x0A72-#x0A74] | [#x0A85-#x0A8B] | #x0A8D | [#x0A8F-#x0A91] | [#x0A93-#x0AA8] | [#x0AAA-#x0AB0] | [#x0AB2-#x0AB3] | [#x0AB5-#x0AB9] | #x0ABD | #x0AE0 | [#x0B05-#x0B0C] | [#x0B0F-#x0B10] | [#x0B13-#x0B28] | [#x0B2A-#x0B30] | [#x0B32-#x0B33] | [#x0B36-#x0B39] | #x0B3D | [#x0B5C-#x0B5D] | [#x0B5F-#x0B61] | [#x0B85-#x0B8A] | [#x0B8E-#x0B90] | [#x0B92-#x0B95] | [#x0B99-#x0B9A] | #x0B9C | [#x0B9E-#x0B9F] | [#x0BA3-#x0BA4] | [#x0BA8-#x0BAA] | [#x0BAE-#x0BB5] | [#x0BB7-#x0BB9] | [#x0C05-#x0C0C] | [#x0C0E-#x0C10] | [#x0C12-#x0C28] | [#x0C2A-#x0C33] | [#x0C35-#x0C39] | [#x0C60-#x0C61] | [#x0C85-#x0C8C] | [#x0C8E-#x0C90] | [#x0C92-#x0CA8] | [#x0CAA-#x0CB3] | [#x0CB5-#x0CB9] | #x0CDE | [#x0CE0-#x0CE1] | [#x0D05-#x0D0C] | [#x0D0E-#x0D10] | [#x0D12-#x0D28] | [#x0D2A-#x0D39] | [#x0D60-#x0D61] | [#x0E01-#x0E2E] | #x0E30 | [#x0E32-#x0E33] | [#x0E40-#x0E45] | [#x0E81-#x0E82] | #x0E84 | [#x0E87-#x0E88] | #x0E8A | #x0E8D | [#x0E94-#x0E97] | [#x0E99-#x0E9F] | [#x0EA1-#x0EA3] | #x0EA5 | #x0EA7 | [#x0EAA-#x0EAB] | [#x0EAD-#x0EAE] | #x0EB0 | [#x0EB2-#x0EB3] | #x0EBD | [#x0EC0-#x0EC4] | [#x0F40-#x0F47] | [#x0F49-#x0F69] | [#x10A0-#x10C5] | [#x10D0-#x10F6] | #x1100 | [#x1102-#x1103] | [#x1105-#x1107] | #x1109 | [#x110B-#x110C] | [#x110E-#x1112] | #x113C | #x113E | #x1140 | #x114C | #x114E | #x1150 | [#x1154-#x1155] | #x1159 | [#x115F-#x1161] | #x1163 | #x1165 | #x1167 | #x1169 | [#x116D-#x116E] | [#x1172-#x1173] | #x1175 | #x119E | #x11A8 | #x11AB | [#x11AE-#x11AF] | [#x11B7-#x11B8] | #x11BA | [#x11BC-#x11C2] | #x11EB | #x11F0 | #x11F9 | [#x1E00-#x1E9B] | [#x1EA0-#x1EF9] | [#x1F00-#x1F15] | [#x1F18-#x1F1D] | [#x1F20-#x1F45] | [#x1F48-#x1F4D] | [#x1F50-#x1F57] | #x1F59 | #x1F5B | #x1F5D | [#x1F5F-#x1F7D] | [#x1F80-#x1FB4] | [#x1FB6-#x1FBC] | #x1FBE | [#x1FC2-#x1FC4] | [#x1FC6-#x1FCC] | [#x1FD0-#x1FD3] | [#x1FD6-#x1FDB] | [#x1FE0-#x1FEC] | [#x1FF2-#x1FF4] | [#x1FF6-#x1FFC] | #x2126 | [#x212A-#x212B] | #x212E | [#x2180-#x2182] | [#x3041-#x3094] | [#x30A1-#x30FA] | [#x3105-#x312C] | [#xAC00-#xD7A3]
[86]    Ideographic    ::=    [#x4E00-#x9FA5] | #x3007 | [#x3021-#x3029]
[87]    CombiningChar    ::=    [#x0300-#x0345] | [#x0360-#x0361] | [#x0483-#x0486] | [#x0591-#x05A1] | [#x05A3-#x05B9] | [#x05BB-#x05BD] | #x05BF | [#x05C1-#x05C2] | #x05C4 | [#x064B-#x0652] | #x0670 | [#x06D6-#x06DC] | [#x06DD-#x06DF] | [#x06E0-#x06E4] | [#x06E7-#x06E8] | [#x06EA-#x06ED] | [#x0901-#x0903] | #x093C | [#x093E-#x094C] | #x094D | [#x0951-#x0954] | [#x0962-#x0963] | [#x0981-#x0983] | #x09BC | #x09BE | #x09BF | [#x09C0-#x09C4] | [#x09C7-#x09C8] | [#x09CB-#x09CD] | #x09D7 | [#x09E2-#x09E3] | #x0A02 | #x0A3C | #x0A3E | #x0A3F | [#x0A40-#x0A42] | [#x0A47-#x0A48] | [#x0A4B-#x0A4D] | [#x0A70-#x0A71] | [#x0A81-#x0A83] | #x0ABC | [#x0ABE-#x0AC5] | [#x0AC7-#x0AC9] | [#x0ACB-#x0ACD] | [#x0B01-#x0B03] | #x0B3C | [#x0B3E-#x0B43] | [#x0B47-#x0B48] | [#x0B4B-#x0B4D] | [#x0B56-#x0B57] | [#x0B82-#x0B83] | [#x0BBE-#x0BC2] | [#x0BC6-#x0BC8] | [#x0BCA-#x0BCD] | #x0BD7 | [#x0C01-#x0C03] | [#x0C3E-#x0C44] | [#x0C46-#x0C48] | [#x0C4A-#x0C4D] | [#x0C55-#x0C56] | [#x0C82-#x0C83] | [#x0CBE-#x0CC4] | [#x0CC6-#x0CC8] | [#x0CCA-#x0CCD] | [#x0CD5-#x0CD6] | [#x0D02-#x0D03] | [#x0D3E-#x0D43] | [#x0D46-#x0D48] | [#x0D4A-#x0D4D] | #x0D57 | #x0E31 | [#x0E34-#x0E3A] | [#x0E47-#x0E4E] | #x0EB1 | [#x0EB4-#x0EB9] | [#x0EBB-#x0EBC] | [#x0EC8-#x0ECD] | [#x0F18-#x0F19] | #x0F35 | #x0F37 | #x0F39 | #x0F3E | #x0F3F | [#x0F71-#x0F84] | [#x0F86-#x0F8B] | [#x0F90-#x0F95] | #x0F97 | [#x0F99-#x0FAD] | [#x0FB1-#x0FB7] | #x0FB9 | [#x20D0-#x20DC] | #x20E1 | [#x302A-#x302F] | #x3099 | #x309A
[88]    Digit    ::=    [#x0030-#x0039] | [#x0660-#x0669] | [#x06F0-#x06F9] | [#x0966-#x096F] | [#x09E6-#x09EF] | [#x0A66-#x0A6F] | [#x0AE6-#x0AEF] | [#x0B66-#x0B6F] | [#x0BE7-#x0BEF] | [#x0C66-#x0C6F] | [#x0CE6-#x0CEF] | [#x0D66-#x0D6F] | [#x0E50-#x0E59] | [#x0ED0-#x0ED9] | [#x0F20-#x0F29]
[89]    Extender    ::=    #x00B7 | #x02D0 | #x02D1 | #x0387 | #x0640 | #x0E46 | #x0EC6 | #x3005 | [#x3031-#x3035] | [#x309D-#x309E] | [#x30FC-#x30FE]

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


C XML und SGML (nicht normativ)

XML wurde als Teilmenge von SGML entworfen, so dass 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].


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 Behandlung von Entities und Referenzen durch einen XML-Prozessor 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 (&#38;) oder mit einem allgemeinen
Entity (&amp;) 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:


E Deterministische Inhaltsmodelle (nicht normativ)

Wie in 3.2.1 Element-Inhalt erwähnt, ist es notwendig, dass Inhaltsmodell in Elementtyp-Deklarationen deterministisch sind. Diese Anforderung besteht zwecks Kompatibilität mit SGML (wo deterministische Inhaltsmodell »unzweideutig« genannt werden. 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 XML-Prozessor bei einem gegebenen initialen b nicht wissen kann, welches b im Inhaltsmodell dazu passt, 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 zusammengefasst werden: (b, (c | d)). Ein einleitendes b passt nun eindeutig zu einem Namen im Inhaltsmodell. Der Prozessor 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].


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, muss 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, dass 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.


F.1 Erkennung ohne externe Kodierungsinformation

Da jedes XML-Entity, das nicht durch externe Kodierungsinformationen begleitet wird und nicht in der UTF-8- oder UTF-16-Kodierung vorliegt, mit einer XML-Kodierungsdeklaration beginnen muss, 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, dass in UCS-4 das »<« die Kodierung »#x0000003C« und »?« die Kodierung »#x0000003F« hat und dass die Byte-Order-Markierung, die von UTF-16-Datenströmen benötigt wird, die Kodierung »#xFEFF« hat. Die Notation ## wird verwendet, um einen beliebigen Byte-Wert anzuzeigen, mit der Ausnahme, dass zwei aufeinanderfolgende ## nicht beide 00 sein können..

Mit Byte-Order-Markierung:

00 00 FE FF UCS-4, Big-endian-Maschine (Reihenfolge 1234)
FF FE 00 00 UCS-4, Little-endian-Maschine (Reihenfolge 4321)
00 00 FF FE UCS-4, ungewöhnliche Oktett-Reihenfolge (2143)
FE FF 00 00 UCS-4, ungewöhnliche Oktett-Reihenfolge (3412)
FE FF ## ## UTF-16, Big-endian
FF FE ## ## UTF-16, Little-endian
EF BB BF UTF-8

Ohne eine Byte-Order-Markierung:

00 00 00 3C UCS-4 oder eine andere Kodierung mit 32-Bit-Code und ASCII-Zeichen als ASCII-Werte kodiert, entweder in Big-endian (1234), Little-endian (4321) oder zwei ungewöhnlichen Byte-Reihenfolgen (2143 und 3412). Die Kodierungsdeklaration muss gelesen werden, um festzustellen, welche der UCS-4- oder anderer 32-Bit-Kodierungen gültig ist.
3C 00 00 00
00 00 3C 00
00 3C 00 00
00 3C 00 3F UTF-16BE oder Big-endian-ISO-10646-UCS-2 oder eine andere Kodierung mit einem 16-Bit-Code in Big-endian-Reihenfolge und ASCII-Zeichen kodiert in ASCII-Werten (die Kodierungsdeklaration muss gelesen werden, um festzustellen welche)
3C 00 3F 00 UTF-16LE oder Little-endian-ISO-10646-UCS-2 oder eine andere Kodierung mit einem 16-Bit-Code in Little-endian-Reihenfolge und ASCII-Zeichen kodiert in ASCII-Werten (die Kodierungsdeklaration muss gelesen werden, um festzustellen welche)
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 variabler Breite, die sicherstellt, dass ASCII-Zeichen ihre normale Postion, Breite und Werte haben. Die tatsächliche Kodierungsdeklaration muss gelesen werden, um festzustellen, welche davon gültig ist; da aber alle diese Kodierungen die gleichen Bitmuster für die relevanten ASCII-Zeichen verwenden, muss die Kodierungsdeklaration selbst zuverlässig gelesen werden können
4C 6F A7 94 EBCDIC (einige Arten; die gesamte Kodierungsdeklaration muss gelesen werden, um herauszufinden, welche Code-Page verwendet wird)
Other UTF-8 ohne Kodierungsdeklaration, oder der Datenstrom ist falsch gekennzeichnet (eine fehlende, notwendige Kodierungsdeklaration), beschädigt, nicht vollständig oder in irgendetwas eingebettet

Anmerkung:

In den oben genannten Fällen, die nicht verlangen, dass die Kodierungsdeklaration gelesen wird, um die Zeichenkodierung zu bestimmen, verlangt Abschnitt 4.3.3 Zeichenkodierung in Entities, dass die Kodierungsdeklaration, falls vorhanden, gelesen wird und dass geprüft wird, dass der Kodierungsname mit der tatsächlichen Kodierung des Entity übereinstimmt.

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 oben genannten 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. Zeichenkodierungen wie UTF-7, die übermässigen Gebrauch von ASCII-wertigen Bytes machen, mögen nicht zuverlässig erkannt werden.

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.


F.2 Priorisierung bei Vorhandensein von externer Kodierungsinformation

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. Im besonderen sei auf [IETF RFC 2376] oder dessen Nachfolger verwiesen, der die MIME-Typen text/xml und application/xml definiert und einen nützlichen Leitfaden darstellt. Im Interesse der Zusammenarbeit sei die folgende Regel empfohlen.

  • Falls ein XML-Entity in einer Datei steht, dann werden die Byte-Order-Markierung und die Kodierungsdeklaration verwendet (falls vorhanden), um die Zeichenkodierung zu bestimmen.


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, dass alle AG-Mitglieder dafür gestimmt haben. Die momentanen und ehemaligen Mitglieder der XML-AG sind:


H W3C XML Core -Gruppe (nicht normativ)

Die zweite Auflage dieser Spezifikation wurde von der W3C-XML-Arbeitsgruppe (AG) erstellt. Die Mitglieder der XML-AG sind zur Zeit der Veröffentlichung:


I Hinweise zur Produktion (nicht normativ)

Diese zweite Auflage wurde gemäß der XMLspec-DTD ausgezeichnet (wofür die Dokumentation verfügbar ist). Die HTML-Version wurde hergestellt mit einer Kombination der XSLT-StyleSheets xmlspec.xsl, diffspec.xsl und REC-xml-2e.xsl. Die PDF-Version wurde mit html2ps und einem Distiller-Programm hergestellt.

Anhänge zur Übersetzung (nicht normativ)


a Referenzen

Dieser Abschnitt enthält Angaben von Quellen, die für die Erstellung der Übersetzung verwendet wurden.

BeMi2000
Behme, Henning und Stefan Mintert. XML in der Praxis -- Professionelles Web-Publishing mit der Extensible Markup Language. München: Addison-Wesley, 2000
W3C1999
XSLT 1.0 Deutsche Übersetzung. Siehe http://www.edition-w3c.de/TR/1999/REC-xpath-19991116
Gold90
Goldfarb, Charles. The SGML Handbook. Oxford: Oxford University Press, 1990
Grosso97
Grosso, Paul. Entity Management -- OASIS Technical Resolution 9401:1997 (Amendment 2 to TR 9401). OASIS, 1997
Walsh2001
Walsh, Norman. XML Catalogs. Siehe http://www.oasis-open.org/committees/entity/spec-2001-08-06.html

b Hinweise zur Produktion

Diese Übersetzung wurde gemäß der TransSpec-DTD ausgezeichnet. Dabei handelt es sich um eine für Übersetzungen erweiterte Fassung der XMLSpec-DTD. Da zum Zeitpunkt der Texterstellung die genauen Abläufe der weiteren Produktion (z.B. Online- und Print-Ausgabe) noch nicht feststehen, wenden Sie sich bitte bei Interesse an den Übersetzer. Es ist beabsichtigt, Informationen Über die Produktion auf der Website http://www.edition-w3c.de anzubieten.


Anmerkungen

[1]

An dieser Stelle ein Dank an Martin Dürst (W3C) für die Hilfe bei der Übertragung eines Beispiels ins Deutsche.

Stichwortverzeichnis

Stichwort Art des Vorkommens
Allgemeines Entity Definition
Analysiertes Entity Wohlgeformtheitsbeschränkung
analysiertes Entity Definition
Anwendung Definition
Attribut-Name Definition
Attribut-Vorgaben Formale Produktion(en)
Attribut-Wert Definition
Attribute Definition
Attributlisten-Deklaration Formale Produktion(en)
Attributlisten-Deklarationen Definition
Attributtypen Formale Produktion(en)
Attributvorgabewert Definition
Aufzählung Gültigkeitsbeschränkung
Aufzählungs-Attribut Definition
Aufzählungs-Attributtypen Formale Produktion(en)
Bedingte Abschnitte Formale Produktion(en)
Bedingter Abschnitt Definition
benutzeroptional Definition
CDATA-Abschnitte Definition
CDATA-Abschnitte Formale Produktion(en)
Deklaration von Externen Entities Formale Produktion(en)
Deklaration von gemischtem Inhalt Formale Produktion(en)
Deklarierte Notation Gültigkeitsbeschränkung
Document Formale Produktion(en)
Dokument-Entity Definition
Dokumenttyp-Definition Formale Produktion(en)
Dokumenttyp-Deklaration Definition
dürfen Definition
Eindeutige Attributspezifikation Wohlgeformtheitsbeschränkung
Eindeutige Elementtyp-Deklarationen Gültigkeitsbeschränkung
Eindeutiger Notation-Name Gültigkeitsbeschränkung
Eine ID pro Elementtyp Gültigkeitsbeschränkung
Eine Notation pro Elementtyp Gültigkeitsbeschränkung
Element Definition
Element Formale Produktion(en)
Element-Inhalt Definition
Elementtyp-Deklaration Definition
Elementtyp-Deklaration Formale Produktion(en)
Elementtyp-Übereinstimmung Wohlgeformtheitsbeschränkung
End-Tag Definition
End-Tag Formale Produktion(en)
Entity Definition
Entity deklariert Wohlgeformtheitsbeschränkung
Entity deklariert Gültigkeitsbeschränkung
Entity Name Gültigkeitsbeschränkung
Entity-Deklaration Definition
Entity-Deklarationen Formale Produktion(en)
Entity-Referenz Definition
Entity-Referenz Formale Produktion(en)
Erlaubtes Zeichen Wohlgeformtheitsbeschränkung
Ersetzungstext Definition
externe Markup-Deklaration Definition
Externe Teilmenge Wohlgeformtheitsbeschränkung
Externe Teilmenge Formale Produktion(en)
externes Entity Definition
Fehler Definition
Feste Attribut-Vorgabe Gültigkeitsbeschränkung
gemischter Inhalt Definition
General Entity Reference Definition
gültig Definition
gültiges Element Gültigkeitsbeschränkung
Gültigkeitsbeschränkung Definition
ID Gültigkeitsbeschränkung
IDREF Gültigkeitsbeschränkung
In der DTD Wohlgeformtheitsbeschränkung
Inhalt Definition
Inhalt von Elementen Formale Produktion(en)
Inhaltsmodell Definition
inkludieren Definition
internes Entity Definition
Kein < in Attribut-Werten Wohlgeformtheitsbeschränkung
Keine doppelten Typen Gültigkeitsbeschränkung
Keine externen Entity-Referenzen Wohlgeformtheitsbeschränkung
Keine Notation für leere Elemente Gültigkeitsbeschränkung
Keine Rekursion Wohlgeformtheitsbeschränkung
Kodierungsdeklaration Formale Produktion(en)
Kommentar Definition
Kommentare Formale Produktion(en)
korrekte Attribut-Vorgabe Gültigkeitsbeschränkung
Kritischer Fehler Definition
leer Definition
Leeres-Element-Tag Definition
Leeres-Element-Tag Formale Produktion(en)
Leerraum Formale Produktion(en)
Literale Formale Produktion(en)
literaler Entity-Wert Definition
Markup Definition
Markup-Deklaration Definition
Modelle für Element-Inhalt Formale Produktion(en)
müssen Definition
Name Definition
Name-Token Gültigkeitsbeschränkung
Namen und Token Formale Produktion(en)
nicht-analysiertes Entity Definition
Notation Definition
Notation-Attribute Gültigkeitsbeschränkung
Notation-Deklaration Definition
Notation-Deklarationen Formale Produktion(en)
Notwendiges Attribut Gültigkeitsbeschränkung
Ordentliche Deklaration/PE-Verschachtelung Gültigkeitsbeschränkung
Ordentliche Gruppierung/PE-Verschachtelung Gültigkeitsbeschränkung
Ordentliche Verschachtelung von bedingten Abschnitten und PEs Gültigkeitsbeschränkung
Parameter-Entity Definition
Parameter-Entity-Referenzen Definition
passen Definition
PE zwischen Deklarationen Wohlgeformtheitsbeschränkung
PEs in interner Teilmenge Wohlgeformtheitsbeschränkung
Prolog Formale Produktion(en)
Public-Identifier Definition
schützen (escape) Definition
Standalone-Dokumentdeklaration Formale Produktion(en)
Standalone-Dokumentdeklaration Gültigkeitsbeschränkung
Start-Tag Definition
Start-Tag Formale Produktion(en)
System-Identifier Definition
Text Definition
Text-Deklaration Formale Produktion(en)
Typ des Attributwertes Gültigkeitsbeschränkung
Validierender Prozessor Definition
Vater/Kind Definition
Verarbeiten von Deklarationen Definition
Verarbeitungsanweisung Definition
Verarbeitungsanweisungen Formale Produktion(en)
Vorgabe für ID-Attribute Gültigkeitsbeschränkung
wohlgeformt Definition
Wohlgeformte, extern-analysierte Entities Formale Produktion(en)
Wohlgeformtheitsbeschränkung Definition
Wurzel-Elementtyp Gültigkeitsbeschränkung
Wurzelelement Definition
XML-Deklaration Definition
XML-Dokument Definition
XML-Prozessor Definition
Zeichen Definition
Zeichen Formale Produktion(en)
Zeichenbereich Formale Produktion(en)
Zeichendaten Definition
Zeichendaten Formale Produktion(en)
Zeichenreferenz Definition
Zeichenreferenz Formale Produktion(en)
zwecks Kompatibilität Definition
zwecks Zusammenarbeit Definition