edition W3C.de

Extensible Markup Language (XML) 1.1

Deutsche Übersetzung

5. Februar 2004

Diese Version:
http://www.edition-w3c.de/TR/2004/REC-xml11-20040204/
Übersetzer:
Stefan Mintert, Linkwerk.com <stefan.mintert (AT) 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. 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.

Hinweis:

Dies ist eine in Arbeit befindliche Vorveröffentlichung.

W3C

Extensible Markup Language (XML) 1.1

W3C Recommendation 04. February 2004

Diese Version:
http://www.w3.org/TR/2004/REC-xml11-20040204/
Aktuelle Version:
http://www.w3.org/TR/xml11
Vorherige Version:
http://www.w3.org/TR/2003/PR-xml11-20031105/
Editoren:
Tim Bray , Textuality and Netscape <tbray@textuality.com>
Jean Paoli , Microsoft <jeanpa@microsoft.com>
C. M. Sperberg-McQueen , W3C <cmsmcq@w3.org>
Eve Maler , Sun Microsystems, Inc. <eve.maler@east.sun.com>
François Yergeau <fyergeau@alis.com>
John Cowan <cowan@ccil.org>

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

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document is a Recommendation of the W3C. It has been reviewed by W3C Members and other interested parties, and has been endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited as a normative reference from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.

This document specifies a syntax created by subsetting an existing, widely used international text processing standard (Standard Generalized Markup Language, ISO 8879:1986(E) as amended and corrected) for use on the World Wide Web. It is a product of the W3C XML Activity. The English version of this specification is the only normative version. However, for translations of this document, see http://www.w3.org/2003/03/Translations/byTechnology?technology=xml11.

Documentation of intellectual property possibly relevant to this recommendation may be found at the Working Group's public IPR disclosure page.

An implementation report for XML 1.1 is available at http://www.w3.org/XML/2002/09/xml11-implementation.html.

Please report errors in this document to xml-editor@w3.org; archives are available. The errata list for this edition is available at http://www.w3.org/XML/xml-V11-1e-errata.

A Test Suite is maintained to help assessing conformance to this specification.

Inhaltsverzeichnis

1 Einführung
    1.1 Herkunft und Ziele
    1.2 Terminologie
    1.3 Begründung und Liste der Änderungen in XML 1.1
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 Processing Instructions
    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
    2.13 Normalization Checking
3 Logical Structures
    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.3.4 Version Information 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 Other References
B Definitions for Character Normalization
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 Working Group (Nicht normativ)
I Production Notes (Nicht normativ)
J Suggestions for XML Names (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.

Anmerkung der Übersetzer:

Innerhalb dieses Textes wird des öfteren von »Grammatiken« gesprochen; SGML und XML sind »Sprachen« (Language). Der Grund dafür ist der folgende: Der theorethische Hintergrund aus der Informatik sind »formale Sprachen«. Dieser Begriff geht zurück auf einen US-amerikanischen Linguisten namens Noam Chomsky, der bereits in den fünfziger Jahren des zwanzigsten Jahrhunderts versucht hat, natürliche Sprache mit formalen Modellen zu beschreiben. In der Informatik führten diese Arbeiten zu mehreren Modellen (»Chomsky-Hierarchie« der Grammatiken). Ohne weiter darauf einzugehen, sollen diese Ausführungen erklären, woher im Kontext von XML der Begriff der Sprache stammt.

SGML und XML sind nun in diesem Sinne keine Sprachen, sondern Metasprachen; sie dienen dazu, Sprachen zu definieren. Eine solche Definition nimmt dann die Form einer DTD an. Wie DTDs aufgebaut sind, beschreibt u.a. diese Spezifikation. Bekannteste Vertreter für SGML- und XML-Sprachen sind HTML und XHTML. HTML ist eine Sprache, die Grammatik ist in der HTML-DTD beschrieben.

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.

Anmerkung der Übersetzer:

Im einfachsten Fall kann man sich unter einem solchen oben genannten Entity eine Datei vorstellen. XML-Dokumente können aus mehreren Datei bestehen. In der Praxis »importiert« dann eine zentrale Datei die anderen (wie das geht wird später bei den Parameter-Entities erklärt). Die begriffliche Verallgemeinerung (Entity) wird hier verwendet, weil es bei der Verarbeitung nicht darauf ankommt, ob die XML-Daten aus einer Datei stammen oder zum Beispiel in einer Datenbank, einem XML Content Managament System o.ä. gespeichert sind.

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

Anmerkung der Übersetzer:

In der Praxis handelt es sich bei einem XML-Prozessor um einen Parser. Eine Übersicht über Software und viele weitere Informationen sind auf den XML Cover Pages zu finden.

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.

Anmerkung der Übersetzer:

Ein RFC ist ein Request for Comments. RFCs stellen die Grundlage für die de-facto-Standards der Internet-Protokolle dar. Weitere Informationen sind unter der Adresse http://www.rfc-editor.org/ zu finden. Als Teilmenge der RFCs gibt es die Reihe FYI (For Your Interest); sie sei dem Internet-Neuling an's Herz gelegt.

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

1.3 Begründung und Liste der Änderungen in XML 1.1

Die XML-1.0-Empfehlung des W3C, zuerst ausgegeben im Jahre 1998, blieb trotz der zahlreichen Errata, die zu einer zweiten Auflage im Jahre 2000 führten, in Bezug auf die Frage, was ist wohlgeformtes XML und was nicht, (bewusst) unverändert. Die Stabilität war für die Interoperatibilität besonders wertvoll. Dennoch, der Unicode-Standard, auf dem die Zeichenspezifikationen von XML 1.0 basieren, blieb nicht unverändert, sondern entwickelte sich von Version 2.0 zu Version 4.0 und darüber hinaus. Zeichen, die in Unicode 2.0 nicht vorhanden sind, dürfen bereits in Zeichendaten in XML 1.0 verwendet werden. Sie sind jedoch nicht in XML-Namen, wie Elementtypnamen, Attributnamen, Aufzählungswerten von Attributen, Zielnamen von Verabeitungsanweisungen usw. erlaubt. Darüber hinaus sind einige Zeichen, die in XML-Namen zugelassen sein sollten, aufgrund von Versehen und Inkonsistenzen in Unicode 2.0 nicht zugelassen.

Die gesamte Philosophie von Namen hat sich seit XML 1.0 verändert. Während XML 1.0 eine strenge Definition von Namen vorgeschrieben hat, worin alles, was nicht erlaubt war, verboten war, sind XML-1.1-Namen so entworfen, dass alles, was nicht (aus bestimmten Gründen) verboten ist, erlaubt ist. Da sich Unicode über Version 4.0 hinaus entwickeln wird, können zukünftige Änderungen an XML vermieden werden, indem fast alle Zeichen in Namen erlaubt werden, einschließlich jener, die noch nicht zugewiesen sind.

Des weiteren versucht XML 1.0 die Zeilenende-Konventionen der verschiedenen modernen Computer-Systeme zu berücksichtigen, diskriminiert aber die Konventionen, die auf IBM- und IBM-kompatiblen Mainframes verwendet werden. In Folge dessen sind XML-Dokumente auf Mainframes keine reinen Textdateien gemäß den lokalen Konventionen. XML-1.0-Dokumente, die auf Mainframes erzeugt wurden, müssen entweder die lokalen Zeilenende-Konventionen verletzen, oder sie erfordern unnötige Übersetzungsphasen vor dem Parsing und nach der Erzeugung. Eine unmittelbare Interoperabilität ist besonders wichtig, wenn gespeicherte Daten zwischen Mainframe und Nicht-Mainframe-Systemen gemeinsam benutzt werden (im Gegensatz zum Kopieren von einem zum anderen). Daher ergänzt XML 1.1 NEL (#x85) zur Liste der Zeilenende-Zeichen. Der Vollständigkeit halber wird auch das Unicode-Zeilentrennzeichen #x2028 unterstützt.

Schließlich besteht hinreichend viel Bedarf für eine standardisierte Darstellung beliebiger Unicode-Zeichen in XML-Dokumenten. Deshalb erlaubt XML 1.1 die Verwendung von Zeichenreferenzen für die Steuerzeichen #x1 bis #x1F, von denen die meisten in XML 1.0 verboten sind. Aus Gründen der Robustheit können diese Zeichen jedoch immer noch nicht direkt in Dokumenten verwendet werden. Um die Zuverlässigkeit der Erkennung von Zeichenkodierungen zu verbessern, dürfen die zusätzlichen Steuerzeichen #x7F bis #x9F, die in XML-1.0-Dokumenten beliebig erlaubt waren, nun auch ausschließlich als Zeichenreferenzen auftreten. (Eine Ausnahme sind selbstverständlich Leerraumzeichen.) Die kleine Verletzung der Abwärtskompatibilität wird als nicht bedeutend erachtet. Wegen potentieller Probleme mit APIs ist #x0 weiterhin verboten, sowohl direkt als auch als Zeichenreferenz.

Schließlich definiert XML 1.1 eine Menge von Beschränkungen mit dem Namen "volle Normalisierung" von XML-Dokumenten, an die sich Dokumenturheber halten sollten und die Dokumentprozessoren überprüfen sollten Die Verwendung von voll normalisierten Dokumenten stellt sicher, dass der Vergleich auf Identität von Namen, Attributwerten und Zeicheninhalt durch einen einfachen binären Vergleich von Unicode-Zeichenketten korrekt durchgeführt werden kann.

Es wurde eine neue Version von XML, im Gegensatz zu einer Sammlung von Errata veröffentlicht, weil die Veränderungen die Definition von wohlgeformten Dokumenten betreffen. XML-1.0-Prozessoren müssen weiterhin solche Dokumente zurückweisen, die neue Zeichen in XML-Namen, neue Zeilenendekonventionen einhalten und neue Steuerzeichen verwenden. Die Unterscheidung zwischen XML-1.0- und XML-1.1-Dokumenten wird durch die Versionsnummer in der XML-Deklaration zu Beginn jedes Dokuments angezeigt.

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 Processing Instructions, die innerhalb des Dokuments durch explizites Markup ausgezeichnet sind. Logische und physikalische Strukturen müssen korrekt verschachtelt sein, wie in 4.3.2 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.

Anmerkung der Übersetzer:

Alle Anwender von SGML sollten beachten, dass der Begriff der Wohlgeformtheit in dieser Form für SGML nicht besteht. Wohlgeformte XML-Dokumente können ohne DTD auskommen. Bei SGML muss es immer eine DTD geben.

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

Anmerkung der Übersetzer:

Regeln dieser Art, die aufgrund ihrer Herkunft (formale Sprachen) auch Produktionen (oder Prdouktionsregeln) genannt werden, lassen sich einfach von links nach rechts lesen: »Ein document ist gleich der Folge von einem prolog, einem element und optional mehreren Misc.« Grundsätzlich werden durch eine Produktion die so genannten Nicht-Terminale auf der linken Seite definiert.

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    ::=    [#x1-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] /* jedes Unicode-Zeichen, ausgenommen die Ersatzblöcke FFFE und FFFF. */
[2a]    RestrictedChar    ::=    [#x1-#x8] | [#xB-#xC] | [#xE-#x1F] | [#x7F-#x84] | [#x86-#x9F]

Anmerkung der Übersetzer:

Nummerische Angaben von Zeichen finden hier grundsätzlich in hexadezimaler Notation statt.

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.

Anmerkung der Übersetzer:

Für deutschsprachige Anwender ist wichtig, dass die in Westeuropa verbreitete Kodierung ISO-8859-1 (Latin-1), die auch die deutschen Umlaute enthält, durch UTF-8 abgedeckt ist.

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

Anmerkung:

The presence of #xD in the above production is maintained purely for backward compatibility with the First Edition. As explained in 2.11 Behandlung des Zeilenendes, all #xD characters literally present in an XML document are either removed or replaced by #xA characters before any other processing is done. The only way to get a #xD character to match this production is to use a character reference in an entity value literal.

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

The first character of a Name MUST be a NameStartChar, and any other characters MUST be NameChars; this mechanism is used to prevent names from beginning with European (ASCII) digits or with basic combining characters. Almost all characters are permitted in names, except those which either are or reasonably could be used as delimiters. The intention is to be inclusive rather than exclusive, so that writing systems not yet encoded in Unicode can be used in XML names. See J Suggestions for XML Names for suggestions on the creation of names.

Document authors are encouraged to use names which are meaningful words or combinations of words in natural languages, and to avoid symbolic or white space characters in names. Note that COLON, HYPHEN-MINUS, FULL STOP (period), LOW LINE (underscore), and MIDDLE DOT are explicitly permitted.

The ASCII symbols and punctuation marks, along with a fairly large group of Unicode symbol characters, are excluded from names because they are more useful as delimiters in contexts where XML names are used outside XML documents; providing this group gives those contexts hard guarantees about what cannot be part of an XML name. The character #x037E, GREEK QUESTION MARK, is excluded because when normalized it becomes a semicolon, which could change the meaning of entity references.

Names and Tokens
[4]    NameStartChar    ::=    ":" | [A-Z] | "_" | [a-z] | [#xC0-#xD6] | [#xD8-#xF6] | [#xF8-#x2FF] | [#x370-#x37D] | [#x37F-#x1FFF] | [#x200C-#x200D] | [#x2070-#x218F] | [#x2C00-#x2FEF] | [#x3001-#xD7FF] | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF]
[4a]    NameChar    ::=    NameStartChar | "-" | "." | [0-9] | #xB7 | [#x0300-#x036F] | [#x203F-#x2040]
[5]    Name    ::=    NameStartChar (NameChar)*
[6]    Names    ::=    Name (#x20 Name)*
[7]    Nmtoken    ::=    (NameChar)+
[8]    Nmtokens    ::=    Nmtoken (#x20 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, Processing Instructions, 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.]

Anmerkung der Übersetzer:

Zur Erklärung der aus dem Englischen übernommenen Begriffe: Ein »tag« dient zur Markierung, zur Kennzeichnung von Textdaten. Der Vergleich mit einem »price tag«, einem Preisschild zur Auszeichnung von Waren, erklärt auch, weshalb der Oberbegriff »tagging language« normalerweise mit »Auszeichnungssprache« übersetzt wird.

Das et-Zeichen (&) und die öffnende spitze Klammer (<) dürfen in ihrer literalen Form ausschließlich als Markup-Begrenzungen, innerhalb eines Kommentars, einer Processing Instruction, oder eines CDATA-Abschnitts benutzt werden. 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 Markupstehen. 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, muss aber nicht, der Anwendung eine Möglichkeit einräumen, den Text eines Kommentars zu lesen. Zwecks Kompatibilität darf die Zeichenkette »--« (zwei Trennstriche) nicht innerhalb eines Kommentars erscheinen.] 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 --->

Anmerkung der Übersetzer:

Diejenigen, die HTML kennen, sehen, dass XML-Kommentare mit denen von HTML übereinstimmen. Für SGML-Kenner ist zu beachten, dass XML-Kommentare ein Sonderfall von SGML-Kommentaren sind.

2.6 Processing Instructions

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

Processing Instructions
[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 Processing Instructions nicht erkannt.

Anmerkung der Übersetzer:

Processing Instructions sind eine nicht ganz ungefährliche Sache. Sie erlauben Dinge, die anders mit XML nicht zu regeln sind; deshalb kann man nicht immer auf sie verzichten. Allerdings kann es leicht passieren, mit PIs die Philosophie von XML zu torpedieren und Befehle für die Verarbeitung in die Dokumente einzubauen, die deren Mehrfachnutzung verhindern. Beispiel:

<?meinprogramm tue-irgendetwas?>

Diese PI wird nur von dem Programm meinprogramm verstanden. Andere Programme werden die Anweisung nicht verstehen und deshalb das Dokument möglicherweise nicht korrekt verarbeiten. Es ist deshalb sehr darauf zu achten, dass man mit PIs nicht die Vorteile von XML zunichte macht.

Charles Goldfarb, der als Vater von SGML gilt, hat diese Problematik in folgender Weise ausgedrückt: »Die Verwendungsmöglichkeiten für SGML umfassen ein Kontinuum: Auf der einen Seite steht die Zukunft, ausgerichtet auf Informationen, welche aus Datenbanken entnommen, zusammengetragen für einen bestimmten Zweck und verarbeitet zu jedem Zweck, von jedem beliebigen System in Übereinstimmung mit Regeln, die auf die Struktur reagieren, die den gespeicherten Informationen innewohnt. Auf der anderen Seite ist die Vergangenheit, aufgebaut auf nicht-regelbasierter, einmaliger Formatierung von Text und Bildern auf einzelne Seiten. In gewissem Sinne können SGML Processing Instructions als ein Rückgriff auf die Vergangenheit angesehen werden, da sie dem Benutzer die Möglichkeit geben, system-spezifische Auszeichungen an ein Anwendungsprogramm in seiner eigenen Sprache zu übermitteln. [...] In einer perfekten Welt wären [Processing Instructions] nicht notwendig, aber, wie Sie vielleicht bemerkt haben, die Welt ist nicht perfekt.« [Gold90]

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

Anmerkung der Übersetzer:

Anders ausgedrückt: In einem CDATA-Abschnitt können beliebige Zeichen in ihrer natürlichen Form stehen. Mann muss nicht darauf achten, ob sie in XML irgendeine besondere Bedeutung haben. Nur »]]>« hat eine besondere Bedeutung.

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.

XML 1.1 processors SHOULD accept XML 1.0 documents as well. If a document is well-formed or valid XML 1.0, and provided it does not contain any control characters in the range [#x7F-#x9F] other than as character escapes, it may be made well-formed or valid XML 1.1 respectively simply by changing the version number.

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 Beipsiel für eine XML-Dekaration mit einer Standalone-Dokumentdeklaration:

<?xml version="1.1" 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, muss sich der XML-Prozessor so verhalten, als ob alle Zeilenumbrüche in externen analysierten Entities (einschließlich des Dokument-Entity) beim Einlesen, noch vor dem Parsing, alle folgenden Zeichen in ein einzelnes #xA-Zeichen umgewandelt werden:

  1. the two-character sequence #xD #xA

  2. the two-character sequence #xD #x85

  3. the single character #x85

  4. the single character #x2028

  5. any #xD character that is not immediately followed by #xA or #x85.

The characters #x85 and #x2028 cannot be reliably recognized and translated until an entity's encoding declaration (if present) has been read. Therefore, it is a fatal error to use them within the XML declaration or text declaration.

Anmerkung der Übersetzer:

Das Zeilenende wird auf unterschiedlichen Systemen (z.B. Unix, DOS usw.) unterschiedlich gekennzeichnet. Auf Unix-Systemen dient in der Regel das Zeilenvorschubzeichen (Dezimal 10, Hexadezimal A) als Zeilenende, während unter DOS und Windows die Kombination aus Carriage-return und Line-feed das Zeilenende markiert. Um diese Unterschiede vor einem Anwendungsprogramm zu verbergen, muss der XML-Prozessor wie oben beschrieben immer einen Zeilenvorschub am Zeilenende ausgeben.

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>

Anmerkung der Übersetzer:

Man beachte in obigem Beispiel die Unterscheidung zwischen deutschem und schweizerischem Deutsch. Die Sprachkennzeichnung dient nicht dazu, Dialekte (z.B. Bayrisch, Schwäbisch usw.) zu unterscheiden.[1]

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

2.13 Normalization Checking

All XML parsed entities (including document entities) SHOULD be fully normalized as per the definition of B Definitions for Character Normalization supplemented by the following definitions of relevant constructs for XML:

  1. The replacement text of all parsed entities

  2. All text matching, in context, one of the following productions:

    1. CData

    2. CharData

    3. content

    4. Name

    5. Nmtoken

However, a document is still well-formed even if it is not fully normalized. XML processors SHOULD provide a user option to verify that the document being processed is in fully normalized form, and report to the application whether it is or not. The option to not verify SHOULD be chosen only when the input text is certified, as defined by B Definitions for Character Normalization.

The verification of full normalization MUST be carried out as if by first verifying that the entity is in include-normalized form as defined by B Definitions for Character Normalization and by then verifying that none of the relevant constructs listed above begins (after character references are expanded) with a composing character as defined by B Definitions for Character Normalization. Non-validating processors MUST ignore possible denormalizations that would be caused by inclusion of external entities that they do not read.

Anmerkung:

The composing character are all Unicode characters of non-zero combining class, plus a small number of class-zero characters that nevertheless take part as a non-initial character in certain Unicode canonical decompositions. Since these characters are meant to follow base characters, restricting relevant constructs (including content) from beginning with a composing character does not meaningfully diminish the expressiveness of XML.

If, while verifying full normalization, a processor encounters characters for which it cannot determine the normalization properties (i.e., characters introduced in a version of Unicode [Unicode] later than the one used in the implementation of the processor), then the processor MAY, at user option, ignore any possible denormalizations caused by these characters. The option to ignore those denormalizations SHOULD NOT be chosen by applications when reliability or security are critical.

XML processors MUST NOT transform the input to be in fully normalized form. XML applications that create XML 1.1 output from either XML 1.1 or XML 1.0 input SHOULD ensure that the output is fully normalized; it is not necessary for internal processing forms to be fully normalized.

The purpose of this section is to strongly encourage XML processors to ensure that the creators of XML documents have properly normalized them, so that XML applications can make tests such as identity comparisons of strings without having to worry about the different possible "spellings" of strings which Unicode allows.

When entities are in a non-Unicode encoding, if the processor transcodes them to Unicode, it SHOULD use a normalizing transcoder.

3 Logical Structures

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

Anmerkung der Übersetzer:

Obwohl (oder weil) der Begriff des »Elements« so zentral ist, wird er (und das »Tag« u.a.) insbesondere in deutschsprachigen Veröffentlichungen sehr ungenau behandelt. Aus diesem Grund hier noch einmal eine Erklärung am Beispiel eines Elements aus (X)HTML.

<h1 class="vorwort">Liebe Leser!</h1>

Dieses Beispiel zeigt ein vollständiges Element, das besteht aus dem Start-Tag (<h1 class="vorwort">), dem Inhalt (Liebe Leser!) sowie dem End-Tag (</h1>). Der Typ des Elements ist h1.

Oft werden die Begriffe Elementtyp und Element synonym verwendet. Der Typ bezeichnet die Gattung, die Art des Elements. Ein Element ist ein Vertreter des entsprechenden Typs; so kann es in einem Dokument zwanzig h1-Elemente geben, aber den Typ h1 gibt es nur einmal (je DTD). Auch ist darauf zu achten, dass ein Tag nur ein Teil eines Elements ist, während häufig das gesamte Element damit fälschlich bezeichnet wird (der Sonderfall des leeren Elements sei hier übergangen). So gibt es Veröffentlichungen, in denen in einem Absatz dreimal »Tag« in drei unterschiedlichen Bedeutungen (Tag, Element, Elementtyp) vorkommt; und die Verwirrung ist perfekt!

Nebenbei sei bemerkt, dass obiges Beispiel noch das Attribut class mit dem Wert »vorwort« enthält.

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 entscheident 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 dazu3.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 w, 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.] ie 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, Processing Instructions oder verschachtelte bedingte Abschnitte, vermischt mit Leerraum, enthalten.

Wenn das Schlüsselwort des bedingten Abschnitts INCLUDE heißt, dann wird der Inhalt des bedingten Abschnitts als Teil der DTD angesehen. Wenn das Schlüsselwort des bedingten Abschnitts IGNORE heißt, dann ist der Inhalt des bedingten Abschnitts kein logischer Teil der DTD. 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 demselben 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

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

Anmerkung der Übersetzer:

Die Referenz eines Parameter-Entity, wie im letzten Beispiel, bedeutet praktisch, dass die Datei (die hier durch einen URL adressiert wird) an der Stelle »eingefügt« wird, an der die Referenz %ISOLat2; steht. Voraussetzung ist, dass (in diesem Beispiel) der XML-Prozessor in der Lage ist, den System-Identifier zu verwenden. Wie das geschieht, ist durch XML nicht definiert. Hier könnte er eine HTTP-Verbindung zu dem angegebenen Rechner aufbauen und versuchen, die Datei zu laden. Siehe auch 4.2.2 Externe Entities.

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 anders aussagen (z.B. ein besonderes XML-Element, das von einer bestimmten DTD definiert wird, oder eine Processing Instruction, die durch eine bestimmte Anwendungsspezifikation definiert wird), beziehen sich relative URIs auf die Adresse der Quelle, in der die Entity-Deklaration steht. Ein URI kann damit relativ zum Dokument-Entity, zum Entity, das die externe DTD-Teilmenge enthält, oder zu irgendeinem anderen externen Parameter-Entity sein.

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 >

Anmerkung der Übersetzer:

Das Verweisen auf externe Entities mit System- und Public-Identifier ist keine triviale Angelegenheit. Bei der Diskussion der Frage, wie man externe Entities (z.B. Grafiken) in einem Dokument referenziert, würde man vielleicht als ersten naiven Ansatz wählen: »Ich verweise auf die Grafikdatei durch Angabe des Dateinamens.« Diese Vorgehensweise ist aber einer Reihe von Problemen unterworfen, z.B.:

  • Vom Betriebssystem abhängige Vorgaben (Stichwort »8+3«, Klein/Großschreibung)

  • Wie werden Verzeichnisstrukturen angegeben (Backslash (DOS) versus Slash (Unix))?

  • Was passiert beim Austausch von XML-Dokumenten? Per Dateiname angegebene Entities müssen auf dem Zielsystem an der gleichen Stelle im Dateisystem liegen.

Bei all diesen Beispielen handelt es sich um einen Dateinamen als System-Identifier. Probleme entstehen u.a. aus der Tatsache, dass es unterschiedliche (Datei)Systeme gibt. Bereits zu SGML-Zeiten wurde deshalb das Konzept des Public-Identifier eingeführt (s.a. [Gold90]). Die Idee ist folgende: Es wird ein (prinzipiell weltweit) eindeutiger Name für das Entity festgelegt, der in einer festgelegten Syntax notiert wird (Beispiel oben: -//Textuality//TEXT Standard open-hatch boilerplate//EN. Bei der Verarbeitung muss dieser Name dann auf eine i.d.R. lokal vorhandene Datei abgebildet. Dies passiert üblicherweise über sogenannte Kataloge (SGML Open Catalog); siehe dazu auch [Grosso97] und [Walsh2001].

Auf den ersten Blick löst die Benutzung eines Web-URLs das Problem. Eine solche Adresse ist zwar ein System-Identifier, aber das System ist in diesem Fall ein de-facto weltweit anerkanntes und in diesem Punkt einheitliches. Jedoch ist es nicht akzeptabel, wenn bei ausschließlich lokaler Datenverarbeitung z.B. bei jedem Parsing eine HTTP-Verbindung geöffnet wird, um eine DTD mit einem entsprechenden System-Identifier zu laden. Hier sind sicher andere Mechanismen wünschenswert; dies kann ein Cache oder wiederum die Verwendung eines Katalogs sein. Die beiden genannten Literaturquellen führen die Frage der Kataloge weiter aus.

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, Processing Instruction, 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.

Anmerkung der Übersetzer:

Wie zuvor erwähnt, ist ISO-8859-1 (deckt die meisten westeuropäische Zeichen ab, insbesondere deutsche Umlaute) in UTF-8 enthalten.

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.3.4 Version Information in Entities

Each entity, including the document entity, can be separately declared as XML 1.0 or XML 1.1. The version declaration appearing in the document entity determines the version of the document as a whole. An XML 1.1 document may invoke XML 1.0 external entities, so that otherwise duplicated versions of external entities, particularly DTD external subsets, need not be maintained. However, in such a case the rules of XML 1.1 are applied to the entire document.

If an entity (including the document entity) is not labeled with a version number, it is treated as if labeled as version 1.0.

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 Processing Instruction richtet.]

Anmerkung der Übersetzer:

Ein Beispiel für eine Notation-Deklaration, eine Entity-Deklaration und die spätere Entity-Referenz im Dokument:

<!NOTATION eps		PUBLIC 
"+//ISBN 0-201-18127-4::Adobe//NOTATION PostScript Language Ref. Manual//EN">
<!ENTITY konzeptzeichnung SYSTEM "konzept.eps" NDATA eps>
...
<!-- im Dokument: -->
&konzeptzeichnung;

Hier wird offensichtlich eine Abbildung im Format EPS in das Dokument eingefügt.

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

matches any 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.
XML-1.0
W3C. Extensible Markup Language (XML) 1.0 (Third Edition). Tim Bray, Jean Paoli, C.M. Sperberg-McQueen, Eve Maler, François Yergeau (editors) (Siehe http://www.w3.org/TR/REC-xml)

A.2 Other References

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.
Charmod
W3C Working Draft. Character Model for the World Wide Web 1.0. Martin J. Dürst, François Yergeau, Richard Ishida, Misha Wolf, Tex Texin. (Siehe http://www.w3.org/TR/2003/WD-charmod-20030822/)
Clark
James Clark. Comparison of SGML and XML. Siehe http://www.w3.org/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.w3.org/TR/REC-xml-names/)

B Definitions for Character Normalization

This appendix contains the necessary definitions for character normalization. For additional background information and examples, see [Charmod].

[Definition: Text is said to be in a Unicode encoding form if it is encoded in UTF-8, UTF-16 or UTF-32.]

[Definition: Legacy encoding is taken to mean any character encoding not based on Unicode.]

[Definition: A normalizing transcoder is a transcoder that converts from a legacy encoding to a Unicode encoding form and ensures that the result is in Unicode Normalization Form C (see UAX #15 [Unicode]).]

[Definition: A character escape is a syntactic device defined in a markup or programming language that allows one or more of:]

  1. expressing syntax-significant characters while disregarding their significance in the syntax of the language, or

  2. expressing characters not representable in the character encoding chosen for an instance of the language, or

  3. expressing characters in general, without use of the corresponding character codes.

[Definition: Certified text is text which satisfies at least one of the following conditions:]

  1. it has been confirmed through inspection that the text is in normalized form

  2. the source text-processing component is identified and is known to produce only normalized text.

[Definition: Text is, for the purposes of this specification, Unicode-normalized if it is in a Unicode encoding form and is in Unicode Normalization Form C, according to a version of Unicode Standard Annex #15: Unicode Normalization Forms [Unicode] at least as recent as the oldest version of the Unicode Standard that contains all the characters actually present in the text, but no earlier than version 3.2.]

[Definition: Text is include-normalized if:]

  1. the text is Unicode-normalized and does not contain any character escapes or includes whose expansion would cause the text to become no longer Unicode-normalized; or

  2. the text is in a legacy encoding and, if it were transcoded to a Unicode encoding form by a normalizing transcoder, the resulting text would satisfy clause 1 above.

[Definition: A composing character is a character that is one or both of the following:]

  1. the second character in the canonical decomposition mapping of some primary composite (as defined in D3 of UAX #15 [Unicode]), or

  2. of non-zero canonical combining class (as defined in Unicode [Unicode]).

[Definition: Text is fully-normalized if:]

  1. the text is in a Unicode encoding form, is include-normalized and none of the relevant constructs comprising the text begin with a composing character or a character escape representing a composing character; or

  2. the text is in a legacy encoding and, if it were transcoded to a Unicode encoding form by a normalizing transcoder, the resulting text would satisfy clause 1 above.

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 Working Group (Nicht normativ)

The present edition of this specification was prepared by the W3C XML Core Working Group (WG). The participants in the WG at the time of publication of this edition were:

I Production Notes (Nicht normativ)

This edition was encoded in a slightly modified version of the XMLspec DTD, 2.5. The XHTML versions were produced with a combination of the xmlspec.xsl, diffspec.xsl, and REC-xml-3e.xsl XSLT stylesheets.

J Suggestions for XML Names (Nicht normativ)

The following suggestions define what is believed to be best practice in the construction of XML names used as element names, attribute names, processing instruction targets, entity names, notation names, and the values of attributes of type ID, and are intended as guidance for document authors and schema designers. All references to Unicode are understood with respect to a particular version of the Unicode Standard greater than or equal to 3.0; which version should be used is left to the discretion of the document author or schema designer.

The first two suggestions are directly derived from the rules given for identifiers in the Unicode Standard, version 3.0, and exclude all control characters, enclosing nonspacing marks, non-decimal numbers, private-use characters, punctuation characters (with the noted exceptions), symbol characters, unassigned codepoints, and white space characters. The other suggestions are mostly derived from [XML-1.0] Appendix B.

  1. The first character of any name should have a Unicode General Category of Ll, Lu, Lo, Lm, Lt, or Nl, or else be '_' #x5F.

  2. Characters other than the first should have a Unicode General Category of Ll, Lu, Lo, Lm, Lt, Mc, Mn, Nl, Nd, Pc, or Cf, or else be one of the following: '-' #x2D, '.' #x2E, ':' #x3A or '·' #xB7 (middle dot). Since Cf characters are not directly visible, they should be employed with caution and only when necessary, to avoid creating names which are distinct to XML processors but look the same to human beings.

  3. Ideographic characters which have a canonical decomposition (including those in the ranges [#xF900-#xFAFF] and [#x2F800-#x2FFFD], with 12 exceptions) should not be used in names.

  4. Characters which have a compatibility decomposition (those with a "compatibility formatting tag" in field 5 of the Unicode Character Database -- marked by field 5 beginning with a "<") should not be used in names. This suggestion does not apply to #x0E33 THAI CHARACTER SARA AM or #x0EB3 LAO CHARACTER AM, which despite their compatibility decompositions are in regular use in those scripts.

  5. Combining characters meant for use with symbols only (including those in the ranges [#x20D0-#x20EF] and [#x1D165-#x1D1AD]) should not be used in names.

  6. The interlinear annotation characters ([#xFFF9-#xFFFB) should not be used in names.

  7. Variation selector characters should not be used in names.

  8. Names which are nonsensical, unpronounceable, hard to read, or easily confusable with other names should not be employed.

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
Becker2001
Becker, Oliver. 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 erweitere 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.


Anmerkungen

[1]

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

Stichwortverzeichnis

Stichwort Art des Vorkommens
Analysiertes Entity Wohlgeformtheitsbeschränkung
Application Definition
At user option Definition
Attribut-Vorgaben Formale Produktion(en)
Attribute Definition
Attribute Default Definition
Attribute Name Definition
Attribute Value Definition
Attribute-List Declaration Definition
Attributlisten-Deklaration Formale Produktion(en)
Attributtypen Formale Produktion(en)
Aufzählung Gültigkeitsbeschränkung
Aufzählungs-Attributtypen Formale Produktion(en)
Bedingte Abschnitte Formale Produktion(en)
CDATA Section Definition
CDATA-Abschnitte Formale Produktion(en)
certified Definition
Character Definition
Character Data Definition
character escape Definition
Character Reference Definition
Comment Definition
composing character Definition
conditional section Definition
Content Definition
Content model Definition
Deklaration von Externen Entities Formale Produktion(en)
Deklaration von gemischtem Inhalt Formale Produktion(en)
Deklarierte Notation Gültigkeitsbeschränkung
Document Formale Produktion(en)
Document Entity Definition
Document Type Declaration Definition
Dokumenttyp-Definition Formale Produktion(en)
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 content Definition
Element Type declaration Definition
Elementtyp-Deklaration Formale Produktion(en)
Elementtyp-Übereinstimmung Wohlgeformtheitsbeschränkung
Empty Definition
empty-element tag Definition
End Tag Definition
End-Tag Formale Produktion(en)
Entity Definition
entity declaration Definition
Entity deklariert Wohlgeformtheitsbeschränkung
Entity deklariert Gültigkeitsbeschränkung
Entity Name Gültigkeitsbeschränkung
Entity Reference Definition
Entity-Deklarationen Formale Produktion(en)
Entity-Referenz Formale Produktion(en)
Enumerated Attribute Values Definition
Erlaubtes Zeichen Wohlgeformtheitsbeschränkung
Error Definition
escape Definition
External Entity Definition
External Markup Declaration Definition
Externe Teilmenge Wohlgeformtheitsbeschränkung
Externe Teilmenge Formale Produktion(en)
Fatal Error Definition
Feste Attribut-Vorgabe Gültigkeitsbeschränkung
For Compatibility Definition
For interoperability Definition
fully normalized Definition
general entity Definition
General Entity Reference Definition
gültiges Element Gültigkeitsbeschränkung
ID Gültigkeitsbeschränkung
IDREF Gültigkeitsbeschränkung
In der DTD Wohlgeformtheitsbeschränkung
Include Definition
include-normalized Definition
Inhalt von Elementen Formale Produktion(en)
Internal Entity Replacement Text 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)
Kommentare Formale Produktion(en)
korrekte Attribut-Vorgabe Gültigkeitsbeschränkung
Leeres-Element-Tag Formale Produktion(en)
Leerraum Formale Produktion(en)
legacy encoding Definition
Literal Entity Value Definition
Literale Formale Produktion(en)
Markup Definition
markup declaration Definition
match Definition
May Definition
Mixed Content Definition
Modelle für Element-Inhalt Formale Produktion(en)
Must Definition
Name Definition
Name-Token Gültigkeitsbeschränkung
Names and Tokens Formale Produktion(en)
normalizing transcoder Definition
Notation Definition
Notation Declaration Definition
Notation-Attribute Gültigkeitsbeschränkung
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 reference Definition
Parent/Child Definition
PE zwischen Deklarationen Wohlgeformtheitsbeschränkung
PEs in interner Teilmenge Wohlgeformtheitsbeschränkung
Process Declarations Definition
Processing instruction Definition
Processing Instructions Formale Produktion(en)
Prolog Formale Produktion(en)
Public identifier Definition
Replacement Text Definition
Root Element 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 Entity Definition
Text-Deklaration Formale Produktion(en)
Typ des Attributwertes Gültigkeitsbeschränkung
Unicode encoding form Definition
Unicode-normalized Definition
Unparsed Entity Definition
Validating Processor Definition
Validity Definition
Validity constraint Definition
Vorgabe für ID-Attribute Gültigkeitsbeschränkung
Well-Formed Definition
Well-formedness constraint Definition
Wohlgeformte, extern-analysierte Entities Formale Produktion(en)
Wurzel-Elementtyp Gültigkeitsbeschränkung
XML Declaration Definition
XML Document Definition
XML Processor Definition
Zeichenbereich Formale Produktion(en)
Zeichendaten Formale Produktion(en)
Zeichenreferenz Formale Produktion(en)