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

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

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

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.

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

Namen und Token

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

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 »&« (Ampersand, et-Zeichen) bzw. »<«(kleiner-als, less-than) geschehen. Die schließende spitze Klammer (>) kann durch die Zeichenkette »>«(größer-als, greater-than) dargestellt werden. Sie muss zwecks Kompatibilität durch »>« 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 »'« und das doppelte Anführungszeichen (") als »"« dargestellt werden.

Zeichendaten

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

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

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

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 »<« bzw. »&« 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

[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

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.

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

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

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.

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.

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

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.

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

Ein Beispiel eines End-Tags:

</termdef>

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

Inhalt von Elementen

[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

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

Hierbei bezeichnet der Name den zu deklarierenden Elementtyp.

Beispiel für Elementtyp-Deklarationen:

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

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

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

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.

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

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

a="

xyz"

a="&d;&d;A&a;&a;B&da;"

a=
"

A

B
"

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

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

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

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

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.

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

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

<?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 % JN '"Ja"' >
<!ENTITY WasErSagte "Er sagte %JN;" >

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

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 »<« und »&« 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

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