1.1. Beziehung zu XLink

XInclude weicht von den Möglichkeiten eines Verweisaufbaus ab, die in der XML Linking Language [XLink] beschrieben sind, besonders von Verweisen mit dem Attributwert show="embed". Solche Verweise haben eine Syntax, die unabhängig vom Medientyp anzeigt, dass ein Quellmedium grafisch in die Darstellung eines Dokuments eingebunden werden soll. XLink gibt kein bestimmtes Verarbeitungsmodell an, sondern vereinfacht nur die Erkennung eines Verweises und die Ermittlung der bezüglichen Metadaten durch eine übergeordnete Anwendung.

XInclude, auf der anderen Seite, gibt eine Transformation an, die vom Medientypen abhängig ist (XML zu XML). Es bestimmt ein besonderes Verarbeitungsmodell, um Infosets zusammenzufassen. Die XInclude-Verarbeitung geschieht auf einem niedrigeren Level, oft durch einen generischen XInclude-Prozessor, der die erzeugten Informationen einer übergeordneten Anwendung zugänglich macht.

Einfache Knoteninklusion, wie in dieser Spezifikation beschrieben, unterscheidet sich von der Transklusion, die kontext-spezifische Informationen wie z.B. style erhält.

1.2. Beziehung zu XML External Entities

Es gibt zahlreiche Unterschiede zwischen XInclude und XML External Entities [XML], die sie zu ergänzenden Technologien machen.

Die Verarbeitung von externen Entities (wie auch des Rests der DTDs) geschieht beim Parsing. XInclude arbeitet mit Infosets und somit entgegengesetzt zum Parsing.

Die Deklaration externer Entities benötigt ein DTD oder ein internes Subset. Das hat einige Abhängigkeiten für die Inklusion zur Folge, zum Beispiel fordert die Syntax einer DOCTYPE-Deklaration, dass das Dokumentelement benannt ist, in vielen Fällen entgegengesetzt zur Inklusion. Validierende Programme müssen die Definition des gesamten Content Models kennen. XInclude verhält sich entgegengesetzt zur Validation und zum Namen des Dokumentelements.

Externe Entities sind indirekt - ein externes Entity muss deklariert und benannt, und separat aufgerufen werden. XInclude verwendet direkte Verweise. Anwendungen, die XML-Ausgaben inkrementell erzeugen, können davon profitieren, die Inklusionen nicht vorher deklarieren zu müssen.

Die Syntax interner Subsets ist für viele Autoren, die einfache, wohlgeformte XML-Dokumente schreiben möchten, zu unförmig. Die XInclude-Syntax basiert auf bekannten XML-Formen.

1.3. Beziehung zu DTDs

XInclude definiert keine Beziehung zur DTD-Verarbeitung. XInclude beschreibt eine Transformation "Infoset-zu-Infoset" und keine Veränderung im Bearbeitungsverhalten von XML 1.0. XInclude definiert keinen Mechanismus zur DTD-Verarbeitung der erzeugten Infosets.

1.4. Beziehung zu XML Schemata

XInclude definiert keine Beziehung zu einem aufgeforsteten Infoset, das durch die Anwendung eines XML-Schemas erzeugt wird. Solch ein erzeugtes Infoset kann als Eingabe-Infoset verwendet werden, bzw. kann so eine Aufforstung als Ergebnis einer angewendeten Inklusion entstehen.

1.5. Beziehung zu Grammatik-abhängigen Inklusionen

Besondere Inklusionsmechanismen wurden in bestimmten XML-Grammatiken eingeführt. XInclude besitzt einen generischen Mechanismus zur Erkennung und Verarbeitung von Inklusionen und setzt deshalb weniger Programmiererfahrung voraus. Es gewährleistet bessere Performance und weniger Programmcodeabhängigkeit.

4.1. Die Include Location

Der Wert des href-Attributs wird als IURI-Verweis interpretiert. [Definition: ]Ein internationalisierter URI-Verweis, oder IURI [IURI], ist ein URI-Verweis, der direkt Unicode-Zeichen verwendet [Unicode]. IURI references allow a superset of the characters of fully escaped URI references, jedoch müssen normal auftauchende Prozentzeichen ersetzt werden, da das Prozentzeichen das Anfangszeichen für Zeichenketten ist, mit denen andere Zeichen in URIs und IURIs ersetzt werden.

Der Base URI für relative IURIs ist der Base URI des Elements xi:include, wie in XML Base [XML Base] angegeben ist. [Definition: ]Der IURI, der durch die Auflösung zur absoluten IURI-Form entsteht, wird die Include Location genannt.

Der Zeichensatz, der im Attribut href erlaubt ist, ist der gleiche wie für XML, nämlich [Unicode]. Jedoch sind einige Unicode-Zeichen in URI-Verweisen nicht erlaubt. Deshalb müssen die nicht erlaubten Zeichen verschlüsselt und ersetzt werden, damit Software zur Auflösung von URI-Verweisen in der Lage ist, diese Zeichen zu verarbeiten.

Nicht erlaubte Zeichen sind alle nicht-ASCII-Zeichen, einschließlich den ausgeschlossenen Zeichen aus Abschnitt 2.4 von [IETF RFC 2396], außer dem Zahlenzeichen (#) und dem Prozentzeichen (%), sowie den eckigen Klammern, die in [IETF RFC 2732] wieder erlaubt werden. Nicht erlaubte Zeichen werden wie folgt ersetzt:

1. Jedes nicht erlaubte Zeichen wird in UTF-8 [IETF RFC 2279], in ein Byte oder mehrere Bytes, umgewandelt.

2. Alle Bytes, die einem nicht erlaubten Zeichen zugeordnet sind, werden durch den für URIs vorgeschriebenen Eresetzungsmechanismus ersetzt (Wandlung in %HH, wobei HH der hexadezimale Wert für den Byte-Wert ist).

3. Das originale Zeichen wird durch die erzeugte Zeichenkette ersetzt.

4.2. Included Items bei parse="xml"

Ist parse="xml" gesetzt, wird die Include Location aufgelöst, die Quelle wird geladen und ein Infoset wird erzeugt.

[Definition: ] xi:include-Elemente in diesem Infoset werden rekursiv verarbeitet, um das Acquired Infoset zu erhalten.

Quellen, die aus irgendeinem Grund nicht zugänglich sind (weil die Quelle vielleicht nicht existiert, Verbindungsschwierigkeiten oder Sicherheitsbeschränkungen den Zugriff verhindern, auf das URI-Schema nicht zugegriffen werden kann oder ein Syntaxfehler in einem XPointer besteht), resultieren in einem Fehler. Quellen, die nicht-wohlgeformtes XML enthalten, resultieren in einem Fehler.

Bei einer Verarbeitung als XML wird ein Teil des URI-Verweises als XPointer [XPointer] interpretiert, unabhängig vom Medientyp der Quelle. Der XPointer gibt eine untergeordnete Quelle als Ziel der Inklusion an.

Die Included Items werden aus dem Acquired Infoset wie folgt gewonnen:

4.3. Included Items bei parse="text"

Wenn parse="text" gesetzt wird, wird die Include Location aufgelöst und die Quelle wird übertragen. Diese Quelle wird als reiner Text behandelt und in einen Satz von Character Information Items konvertiert ohne den Versuch, diese Quelle als XML zu verarbeiten. Diese Eigenschaft ermöglicht die Inkludierung von XML-Arbeitsbeispielen und anderen Text-basierten Formaten.

Die Verschlüsselung einer solchen Quelle wird erkannt durch:

• externe Verschlüsselungsinformation, sofern verfügbar, ansonsten

• wenn der Medientyp der Datei text/xml, bzw. application/xml ist oder die Konventionen für text/*+xml oder application/*+xml erfüllt werden, wie in XML Medien Typen [IETF RFC 3023] beschrieben ist, die Verschlüsselungserkennung, wie in XML 1.0 angegeben ist, ansonsten

• den Wert des Attributs encoding, sofern einer existiert, ansonsten

• UTF-8.

Byte-Folgen außerhalb des erlaubten Verschlüsselungsbereichs resultieren in einem Fehler. Zeichen, die nicht innerhalb eines XML-Dokuments erlaubt sind, resultieren ebenfalls in einem Fehler.

[Definition: ] Ein Zeichenbereich (der ausgewählte Bereich) kann durch einen Fragment Identifier identifiziert werden. Die Syntax des Fragment Identifiers wird nach der Syntax für Fragment Identifier für den Medientyp text/plain interpretiert. Ist kein Fragment Identifier vorhanden, enthält der ausgewählte Bereich alle Zeichen in dem Dokument.

Die Zeichen im ausgewählten Bereich werden in Included Items konvertiert durch die Erzeugung eines Charakter Information Item, dessen [charakter code] auf den Zeichencode gesetzt wird, der das Zeichen laut ISO 10646 repräsentiert, und das [element content whitespace] wird auf false gesetzt.

Gemäß dem Character Model [Character Model], sofern das Textformat eine Unicode-Verschlüsselung ist, muss der XInclude-Prozessor die Inklusion verweigern, wenn der Text im ausgewählten Bereich nicht normalisiert ist. Sollen Zeichen von einer anderen Verschlüsselung in Unicode-Verschlüsselung transformiert werden, muss ein normalisierender Transcoder verwendet werden.

4.4. Erzeugen des Ergebnis-Infosets

Das Ergebnis-Infoset ist eine Kopie des Quell-Infosets, in dem jedes xi:include-Element wie folgt ersetzt wird:

Das Information Item für das xi:include-Element ist gefunden. [Definition: ] Die [parent]-Eigenschaft dieses Items bezieht sich auf ein Information Item, das Include Parent genannt wird. Die [children]-Eigenschaft des Include Parent wird verändert, indem das xi:include-Element Information Item durch die Included Items ersetzt wird. Die [parent]-Eigenschaft eines jeden Included Item wird auf Include Parent gesetzt.

Interne Dokumentverweise innerhalb von xi:include-Elementen müssen gegen das Quell-Infoset aufgelöst werden. Die Folge davon ist, dass die Reihenfolge, in der die xi:include-Elemente verarbeitet werden, das Ergebnis nicht beeinflusst.

Im folgenden Beispiel zeigt die zweite Inklusion immer auf das erste xi:include-Element und nicht auf sich selbst, unabhängig von der Reihenfolge, in der die Inklusionen verarbeitet werden. Folglich sind zwei Kopien von something.xml das Ergebnis der Inklusion, und es wird kein Inklusionsschleifenfehler erzeugt.

<x xmlns:xinclude="http://www.w3.org/2001/XInclude">
  <xi:include href="something.xml"/>
  <xi:include href="#xmlns(xi=http://www.w3.org/2001/XInclude)
                     xpointer(x/xi:include[1])"
              parse="xml"/>
</x>

<foo xmlns:x="uri1">
  <xi:include href="common.xml#xpointer(a/b)"
              xmlns:xi="http://www.w3.org/2001/XInclude"/>
</foo>

<a xmlns:x="uri2">
  <b>
    <x:a/>
  </b>
</a>

<foo xmlns:x="uri1">
  <b xmlns:x="uri2">
    <x:a/>
  </b>
</foo>

5.1. Markup-Konformität

Ein Element Information Item ist konform zu dieser Spezifikation, wenn es die strukturellen Anforderungen für Include-Elemente erfüllt, die in dieser Spezifikation definiert sind. Diese Spezifikation legt DTDs oder XML Schemas keine besonderen Zwänge auf; die Konformität bezieht sich nur auf Elemente und Attribute.

5.2. Anwendungs-Konformität

Eine Anwendung ist konform zu XInclude, wenn sie:

• XML 1.0, XML Namespaces, das XML Information Set, und XML Base unterstützt

• die obligatorischen Bedingungen befolgt (muss), die in dieser Spezifikation festgeschrieben sind und alle optionalen Bedingungen (kann), die sie befolgen möchte, so unterstützt, wie es vorgeschrieben ist

• Markup-Konformitätstests durchführt, entsprechend allen Konformitätsrichtlinien, die in dieser Spezifikation genannt sind.

5.3. XML Information Set Konformität

Diese Spezifikation ist konform zu XML Information Set [XML Infoset]. Die folgenden Information Items müssen im Quell-Infoset vorhanden sein, um eine korrekte Verarbeitung zu ermöglichen:

• Document Information Items mit den Eigenschaften [children] und [base URI].

• Element Information Items mit den Eigenschaften [namespace name], [local name], [children], [attributes], [base URI] und [parent].

• Attribute Information Items mit den Eigenschaften [namespace name], [local name] und [normalized value].

Information Items und Eigenschaften des Quell-Infosets werden etweder in Übereinstimmung mit dieser Spezifikation verarbeitet, oder durchlaufen die Inklusionstransformation unverändert. Zusätzlich kann die XInclude-Verarbeitung folgende Information Items im Ergebnis erzeugen:

• Character Information Items mit den Eigenschaften [character code], [element content whitespace] und [parent].