xml:id Version 1.0 (W3C)

1. Einleitung

[XML 1.0] und [XML 1.1] bieten einen Mechanismus, Elemente mit eindeutigen Identifikatoren zu versehen. Dieser Mechanismus besteht darin, den Typ eines Attributs als »ID« zu deklarieren, woraufhin der Parser validieren wird, dass

der ID-Wert der erlaubten lexikalischen Form entspricht,
der Wert innerhalb des XML-Dokuments eindeutig ist, und dass
jedes Element höchstens einen einzigen eindeutigen Bezeichner besitzt.

Deklarationen aus sowohl interner als auch externer DTD-Untermenge eines XML-Dokuments können Attribute vom Typ ID festlegen. Die Verarbeitung der externen DTD-Untermenge ist für konforme XML-Prozessoren jedoch optional, und manche Spezifikationen, insbesondere [SOAP], verbieten DTDs vollständig und geben damit keine Garantie, dass alle Konsumenten des XML-Dokuments in der Lage sind, die Identifikatoren zu ermitteln.

Identifikatoren können auch durch externe Mechanismen deklariert werden. Von besonderem Interesse ist [XML Schemas], das mit derselben Eindeutigkeit und denselben Gültigkeitsbeschränkungen wie XML den Typ xs:ID bietet. Es gibt jedoch keine Garantie, dass für Konsumenten das »richtige« Schema verfügbar ist oder dass sie es verarbeiten, wenn es verfügbar ist.

Ein Mechanismus, der es ermöglicht, dass eindeutige Elementbezeichner von allen konformen XML-Prozessoren erkannt werden, egal, ob diese validieren oder nicht, ist wünschenswert, um die Verknüpfung von XML-Unterressourcen robust zu machen. Diese Spezifikation erlaubt Autoren, Elemente mittels IDs zu identifizieren, die durch jeden Prozessor erkannt werden können, ungeachtet dessen, ob oder wie interne oder externe Deklarationen vorliegen.

Ein weiteres Problem besteht darin, dass auf DTD und XML Schema basierende Identifikatoren durch verschiedene konzeptionelle Mechanismen – durch die Attributstyp-Informationssatz-Eigenschaft bzw. die Typendefinition-Eigenschaften-Familie – hervorgehoben werden. Ein gleichartiger Mechanismus zur Erkennunung von Identifikatoren ist erstrebenswert.

Diese Spezifikation bietet einen solchen Mechanismus: Sie beschreibt die Semantik von xml:id-Attributen. Die Spezifikation wurde so entworfen, dass sie eine separate Verarbeitungsebene darstellt und mit existierenden Validierungstechnologien kompatibel ist. Implementierer werden ermutigt, die xml:id-Verarbeitung zu unterstützen und ID-Typenbestimmung zum Standardverhalten ihrer Prozessoren zu machen.

Es war eines der Grundprinzipien beim Entwurf dieser Spezifikation, dass das Ergebnis einer xml:id-Verarbeitung dasselbe sein sollte, wenn eine passende Deklaration vom Prozessor erkannt und verwendet wurde.

2. Terminologie

Definition: In dieser Spezifikation sind die Schlüsselwörter muss, darf nicht, notwendig, soll, soll nicht, sollte, sollte nicht, empfohlen, darf und optional zu verstehen wie in [IETF RFC 2119] beschrieben.

Definition: Ein xml:id-Prozessor entspricht einem Softwaremodul, das zusammen mit einem XML-Prozessor arbeitet, um Zugang zu den IDs in einem XML-Dokument zu bieten.

Definition: Ein xml:id-Fehler entspricht einem nicht-fatalen Fehler, der auftritt, wenn ein xml:id-Prozessor ermittelt, dass ein Dokument die Beschänkungen dieser Spezifikation missachtet.

Validierung ist der Prozess, ein XML-Dokument (oder einen Teil eines XML-Dokuments) mit einer Grammatik oder einem Satz von Regeln zu vergleichen, um zu ermitteln, ob die vorliegende Struktur des Dokuments die Beschränkungen der Grammatik oder der Regeln befriedigt. Manche Validierungstechnologien führen auch Typenbestimmungen durch und ermitteln nicht nur, ob das Dokument die spezifizierten Beschränkungen erfüllt, sondern beispielsweise auch, welche Elemente oder Attribute dem Typ »ID« entsprechen.

Obwohl sie oft zusammen durchgeführt werden, stellen Validierung und Typenbestimmung nicht denselben Prozess dar. So kann zum Beispiel ein XML-1.0-Prozessor, der nicht validiert, Typenbestimmungen durchführen, indem er lediglich Deklarationen aus dem internen »Subset« heranzieht, ohne jemals Informationen zur strukturellen Validität zur Verfügung stehen zu haben.

Definition: Der Prozess der ID-Typenbestimmung sorgt dafür, dass ein xml:id-Attribut einer ID entspricht. Oftmals wird dies erzielt, indem innerhalb des »Infosets« bzw. Post-Schema-Validierung-Infosets (PSVI) die Art des Attributs in »ID« geändert wird, auch wenn dies nicht den einzigen möglichen Weg darstellt.

Anmerkung: Die Verarbeitung von IDs auf Applikationsebene, die beinhaltet, welche Elemente tatsächlich von welchen IDs berücksichtigt werden können, ist nicht Gegenstand dieser Spezifikation.

3. Syntax

Gemäß [Namensräume in XML] (sowie [Namensräume in XML 1.1]) sind Präfixes, die mit xml beginnen, für die Verwendung von XML- und XML nahestehenden Spezifikationen reserviert. Diese Spezifikation lizenziert den Gebrauch des Attributs xml:id zur Verwendung als allgemeine Syntax für Identifikatoren in XML mitsamt der hier spezifizierten Semantik.

Autoren von XML-Dokumenten werden angeregt, ihre ID-Attribute xml:id zu nennen, um die Interoperabilität dieser Identifikatoren im Web zu fördern.

Bei namensraumgewahren XML-Prozessoren ist das xml-Präfix wie in »Namensräume in XML« ([Namensräume in XML] sowie [Namensräume in XML 1.1]) beschrieben an den Namensraumnamen http://www.w3.org/XML/1998/namespace gebunden. Beachten Sie, dass xml:id immer noch von XML-Prozessoren, die nicht auf Namensräume achten, verwendet werden kann.

4. Verarbeitung von `xml:id`-Attributen

Jedes xml:id-Attribut wird auf die folgende Art verarbeitet:

Der Attributswert wird gemäß den Regeln zur Attributswert-Normalisierung von Attributen des Typs ID normalisiert. Beachten Sie für weitere Details E. Attributswert-Normalisierung in IDs.
Die Infoset-Eigenschaft »normalisierter Wert« wird mit dem normalisierten Wert aktualisiert.
Mit dem normalisierten Wert wird eine ID-Typenbestimmung durchgeführt.

Ein xml:id-Prozessor muss sicherstellen, dass die folgenden Einschränkungen für alle xml:id-Attribute gelten:

Der normalisierte Wert des Attributs entspricht einem NCName gemäß der »Namensräume in XML«-Empfehlung, der dieselbe Version wie das Dokument hat, in dem das Attribut vorkommt (NCName in XML 1.0 oder NCName in XML 1.1).
Der deklarierte Typ des Attributs ist, sofern es einen besitzt, »ID«. Alle Deklarationen von ID-Attributen müssen »ID« als Typ des Attributs spezifizieren.

Ein xml:id-Prozessor sollte sicherstellen, dass die folgende Einschränkung gilt:

Die Werte aller Attribute des Typs »ID« (was alle xml:id-Attribute umfasst) innerhalb eines Dokuments sind einmalig.

Ein xml:id-Fehler tritt bei jedem xml:id-Attribut auf, das nicht diese Auflagen erfüllt.

Der xml:id-Prozessor führt eine ID-Typenbestimmung bei allen xml:id-Attributen durch, selbst bei denen, die keine Auflagen erfüllen.

Ein xml:id-Prozessor sollte die Infoset-Referenzen-Eigenschaft – wie in Abschnitt 2.3 von [XML Information Set] beschrieben – sowie jegliche implementierungsspezifischen Strukturen, die zur Querreferenzierung verwendet werden, aktualisieren, um die Ergebnisse der ID-Typenbestimmung wiederzugeben.

Viele Validierungstechnologien erlegen die Beschränkung auf, dass ein XML-Element über höchstens ein Attribut des Typs ID verfügen darf. Diese Einschränkung wird durch die xml:id-Verarbeitung nicht auferlegt.

Diese Spezifikation definiert die Verarbeitung von xml:id, aber es liegt an der Anwendung, zu ermitteln, wann eine solche Verarbeitung vorgenommen wird. Benutzer von Applikationen, die Mittel dazu bieten, XML-Dokumente zu modifizieren, dürfen normalerweise erwarten, dass eine xml:id-Verarbeitung vorgenommen wird, sobald ein ID-Wert verändert wird.

5. Benachrichtigung von Applikationen

Bei Durchführung einer ID-Typenbestimmung muss der xml:id-Prozessor die zugewiesenen xml:id-Attribute der Anwendung mitteilen. Wie dies mitgeteilt wird, ist implementierungsabhängig.

Für Anwendungen, die konzeptionell auf dem Informationssatz operieren, kann ein xml:id-Prozessor die Attributstyp-Eigenschaft des Infosets verwenden:
Der xml:id-Prozessor darf die Ergebnisse der ID-Typenbestimmung auf eine DTD-kompatible Art weitergeben, indem er die Infoset-Attributstyp-Eigenschaft des Attributs auf »ID« setzt.
Für Anwendungen, die konzeptionell auf dem PSVI arbeiten, kann ein xml:id-Prozessor die Typendefinition-Familie der PSVI-Eigenschaft gebrauchen:
Der xml:id-Prozessor darf die Ergebnisse der ID-Typenbestimmung auf eine XML-Schema-kompatible Weise weitergeben, indem er die PSVI-Typendefinition-Eigenschaft des Attributs auf xs:ID setzt.
Bei Anwendungen, die mit mittels anderer Methoden definierten Datenmodellen arbeiten, sind die Mechanismen implementierungsabhängig:
Der xml:id-Prozessor darf die Ergebnisse der ID-Typenbestimmung auf eine (beliebige) andere Art weitergeben.

Die Schlüsselanforderung ist, dass die Ergebnisse der ID-Typenbestimmung der Applikation mitgeteilt werden.

6. Fehler

Eine Verletzung der Bestimmungen dieser Spezifikation führt zu einem xml:id-Fehler. Solche Fehler sind nicht fatal, sollten aber durch den xml:id-Prozessor mitgeteilt werden. Im Interesse der Interoperabilität wird empfohlen, dass xml:id-Fehler nicht »still« ignoriert werden.

7. Konformität

7.1 Konformität mit `xml:id`

Konformität mit xml:id beruht für Applikationen, die auf XML-Prozessoren mittels Validierungstechnologien setzen, auf dem Gebrauch des xml:id-Konstrukts wie in »Verarbeitung von xml:id-Attributen« beschrieben sowie Konformität mit sowohl den Bestimmungen dieser Spezifikation als auch den Regeln der Validierungstechnologie.

Konformität mit xml:id wird für Applikationen, die auf nicht-validierenden XML-Prozessoren aufsetzen, sowohl durch die Erkennung von xml:id-Attributen wie in »Verarbeitung von xml:id-Attributen« erklärt als auch durch Konformität mit den Bestimmungen dieser Spezifikation definiert.

Konformität mit Bestimmungen, die erfüllt werden »müssen«, ist obligatorisch. Es wird empfohlen, dass Anwendungen die anderen Bestimmungen ebenfalls erfüllen. Diese Spezifikation definiert keine einfachen optionalen Vorgaben.

Ein Dokument ist zu dieser Spezifikation konform, wenn es keine xml:id-Fehler generiert.

7.2 Konformität mit XML-Informationssatz

Diese Spezifikation unterliegt dem [XML Information Set]. Die folgenden Informationsbestandteile müssen in den Eingabeinformationssätzen vorhanden sein, um eine korrekte Verarbeitung zu ermöglichen:

Element Information Items mit Eigenschaft für Attribute.
Attribute Information Items mit Eigenschaften für Namensraumname, lokaler Name und normalisierter Wert.

Zusätzlich können die folgenden Eigenschaften im Ausgabe-Informationssatz verfügbar sein:

Eigenschaften für Attributstypen in Attribute Information Items.

8. Erweiterbarkeit

Diese Spezifikation ist nicht erweiterbar. Es gibt keine Vorkehrungen für Anwendungsdesigner, den Namen des xml:id-Attributs, den Attributssatz von Werten, die als IDs angesehen werden, oder die Orte, an denen diese vorkommen können, zu verändern oder andere Erweiterungen vorzunehmen.

A. Referenzen

IETF RFC 2119: RFC 2119: Key Words for Use in RFCs to Indicate Requirement Levels. Internet Engineering Task Force, 1997. (Siehe http://www.ietf.org/rfc/rfc2119.txt.)
XML 1.0: Tim Bray, Jean Paoli, C. M. Sperberg-McQueen et al., Herausgeber. Extensible Markup Language (XML) 1.0 (Third Edition). World Wide Web Consortium, 2004. (Siehe https://www.w3.org/TR/REC-xml/.)
XML 1.1: Tim Bray, Jean Paoli, C. M. Sperberg-McQueen et al., Herausgeber. Extensible Markup Language (XML) 1.1. World Wide Web Consortium, 2004. (Siehe https://www.w3.org/TR/xml11/.)
XML Information Set: John Cowan und Richard Tobin, Herausgeber. XML Information Set (Second Edition). World Wide Web Consortium, 2004. (Siehe https://www.w3.org/TR/xml-infoset/.)
Namespaces in XML: Tim Bray, Dave Hollander und Andrew Layman, Herausgeber. Namespaces in XML. World Wide Web Consortium, 1999. (Siehe https://www.w3.org/TR/REC-xml-names/.)
Namespaces in XML 1.1: Tim Bray, Dave Hollander, Andrew Layman und Richard Tobin, Herausgeber. Namespaces in XML 1.1. World Wide Web Consortium, 2004. (Siehe https://www.w3.org/TR/xml-names11/.)

B. Referenzen (non-normativ)

XML Schemas: Henry S. Thompson, David Beech, Murray Maloney und Noah Mendelsohn, Herausgeber. XML Schema Part 1: Structures. World Wide Web Consortium, 2001. (Siehe https://www.w3.org/TR/xmlschema-1/.)
SOAP: Martin Gudgin, Marc Hadley, Noah Mendelsohn et al., Herausgeber. SOAP Version 1.2 Part 1: Messaging Framework. World Wide Web Consortium, 2003. (Siehe https://www.w3.org/TR/soap12-part1/.)

C. Einfluss auf Kanonisierung (non-normativ)

Die Spezifikation Canonical XML Version 1.0 beschreibt einen Prozess, in dem Attribute aus dem xml:-Namensraum in einem »kanonisierten« Dokument vererbt werden. Während dies zu akzeptablen Ergebnissen mit xml:lang- oder xml:space-Attributen führt, ergibt die Verarbeitung von xml:id-Attributen – besonders die von xml:id-Attributen, die nicht einmalig sind – auf diese Weise Dokumente, die wahrscheinlich xml:id-Fehler beinhalten.

Dies ist eine augenscheinliche Schwachstelle im Design von Canonical XML. Die Spezifikation Exclusive XML Canonicalization Version 1.0 umfasst diese Funktion nicht und mag für Dokumente, die IDs beinhalten, angebrachter sein.

D. Validierungstechnologien (non-normativ)

Dieser Anhang beschreibt, wie die Verarbeitung von xml:id mit ausgewählten Validierungstechnologien interagiert.

D.1 DTD-Validierung

Autoren von DTDs werden ermutigt, xml:id-Attribute zu verwenden, wenn in ihren DTDs deklarierte Identifikatoren für Elemente eingesetzt werden.

Das folgende DTD-Fragment illustriert eine Beispieldeklaration des xml:id-Attributs:


<!ATTLIST someElement
  xml:id  ID  #IMPLIED
>

DTD-Autoren werden ermutigt, Attribute mit dem Namen xml:id als Typ ID zu deklarieren. Ein Dokument, das xml:id-Attribute gebraucht, die einen anderen Typ als ID deklariert haben, werden immer xml:id-Fehler erzeugen.

Konsumenten von Dokumenten, die bei Verwendung sauber deklarierter xml:id-Attribute validiert wurden, können IDs durch die Attributstyp-Eigenschaft erkennen.

D.2 XML-Schema-Validierung

XML-Schema-Autoren werden angeregt, xml:id-Attribute zu gebrauchen, wenn sie Identifikatoren für Elemente bestimmen, die in ihren Schemata deklariert werden. Beachten Sie, dass dies am einfachsten erreicht werden kann, indem das Schema für den XML-Namensraum importiert und die dort beinhaltete Attributsdeklaration verwendet wird.

Das folgende XML-Schema-Fragment für den XML-Namensraum illustriert eine Beispieldeklaration des xml:id-Attributs:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
  targetNamespace="http://www.w3.org/XML/1998/namespace">
  <xs:attribute name="id" type="xs:ID" />
</xs:schema>

XML-Schema-Autoren werden ermutigt, Attribute mit dem Namen xml:id mit dem Typ xs:ID zu deklarieren. Ein Dokument, das xml:id-Attribute gebraucht, die mit einem anderen Typ als xs:ID deklariert wurden, wird immer xml:id-Fehler erzeugen.

Konsumenten von Dokumenten, die xml:id-Attribute gegen ein für den XML-Namensraum geeignetes Schema validieren, können IDs durch die Typendefinition-Familie der PSVI-Eigenschaften erkennen.

Anwendungen können xml:id-Attribute als IDs erkennen, indem sie konzeptionell einen minimal konformen Schema-Prozessor sowie das obige Schema verwenden.

Beachten Sie, dass die Ergebnisse eines minimal konformen Schema-Prozessors, der das obige Schema verarbeitet, angenähert werden, indem nur nach Attributen mit Namen xml:id gesucht, sich der korrekten lexikalischen Form (NCName) solcher Attribute vergewissert und die Einmaligkeit des Werts sichergestellt wird.

D.3 RELAX-NG-Schema-Validierung

Autoren von RELAX-NG-Grammatiken werden ermutigt, xml:id-Attribute zu verwenden, wenn sie Identifikatoren für Elemente bestimmen, die in ihren Schemata deklariert werden.

Das folgende RELAX-NG-Fragment stellt eine Beispieldeklaration des xml:id-Attributs dar:

<optional xmlns="http://relaxng.org/ns/structure/1.0"
  datatypeLibrary="https://www.w3.org/2001/XMLSchema-datatypes">
  <attribute name="xml:id">
    <data type="ID" />
  </attribute>
</optional>

RELAX-NG-Grammatik-Autoren werden angeregt, Attribute vom Namen xml:id mit dem Typ xs:ID zu deklarieren. Ein Dokument, das xml:id-Attribute gebraucht, die als anderer Typ als xs:ID deklariert wurden, wird immer xml:id-Fehler erzeugen.

E. Attributswert-Normalisierung in IDs (non-normativ)

[XML 1.0] verlangt von Parsern, alle Attributswerte zu normalisieren. Die Normalisierung erweitert Zeichen- und Entitätsreferenzen und bereinigt Zeilenende-Zeichen. Attribute vom Typ ID sind Ziel zusätzlicher Normalisierungsregeln wie dem Entfernen voran- und nachstehender Leerstellenzeichen und dem Ersetzen von Sequenzen von Leerraum durch ein einziges Leerzeichen.

Ein xml:id-Prozessor muss sicherstellen, dass bei allen xml:id-Attributen beide Normalisierungsschritte ausgeführt werden. So darf der Parser nicht die zusätzlichen Normalisierungschritte ausführen, die für Attribute des Typs ID gefordert werden, da dieses Attribut nicht als ID deklariert werden muss.

Bedenken Sie das folgende Dokument:

<!DOCTYPE doc [
  <!ATTLIST doc xml:id ID #IMPLIED>
]>

<doc xml:id="  eins
">
<para xml:id="  zwei
"></para>
</doc>

Der initiale Wert von xml:id auf doc wird »eins« sein, da der Parser wusste, dass er einer ID entspricht. Der initiale Wert auf para wird » zwei « sein, da der Parser nicht wusste, dass es sich um eine ID handelt und nicht die verlangte zusätzliche Normalisierung ausführt.

Nach der xml:id-Verarbeitung wird der Wert der xml:id-Attribute auf doc und para »eins« bzw. »zwei« entsprechen. Diese ordnungsgemäß normalisierten Werte werden in der »normalisierter Wert«-Infoset-Eigenschaft hinterlegt. Die Ausführung der xml:id-Verarbeitung verändert den Infoset, wenn es unvollständig normalisierte xml:id-Attribute gibt.

Anmerkung: Zwecks Interoperabilität sollten Dokumentersteller vollständig normalisierte Werte verwenden, die legalen NCName-Namen in xml:id-Attributen entsprechen.