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 Medientypen 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 Restes 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 document-Element benannt ist, in vielen Fällen offensichtlich 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 document-Elements.

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

3.1. Die Include Location

Der Wert des href-Attributs wird als URI-Verweis interpretiert. Die erlaubten Zeichen für den Wert des href-Attributs entsprechen denen für XML, mit anderen Worten [Unicode]. Einige Unicode-Zeichen sind jedoch nicht innerhalb eines URI-Verweises erlaubt, deshalb müssen Prozessoren diese Zeichen kodieren und ersetzen, um einen gültigen URI-Verweis aus dem Attributwert zu erhalten.

Nicht erlaubt sind alle Nicht-ASCII-Zeichen, sowie die in Abschnitt 2.4 der [IETF RFC 2396] ausgeschlossenen Zeichen, mit Ausnahme des Rautezeichens (#), des Prozentzeichens (%) und der eckigen Klammern, die in [IETF RFC 2732] wieder erlaubt werden. Nicht erlaubte Zeichen müssen wie folgt ersetzt werden:

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

2. Jedes Oktett, das einem nicht erlaubten Zeichen zugeordnet ist, wird durch den für URIs vorgeschriebenen Mechanismus 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.

Der Basis-URI für relative URIs ist der Basis-URI des include-Elements wie in XML Base [XML Base] definiert. [Definition: ] Der URI, der durch die Auflösung zu einem absoluten URI entsteht, wird Include Location genannt.

3.2. Included Items bei parse="xml"

Ist parse="xml" gesetzt, wird die Include Location aufgelöst und die Quelle wird geladen. Diese Quelle wird als XML-Quelle behandelt und in ein Information Set verarbeitet. [Definition: ] 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.

Ein Fragment des URI-Verweises wird als XPointer [XPointer] interpretiert, wenn parse="xml" gesetzt ist. Der XPointer zeigt an, dass eine untergeordnete Quelle oder ein Teil der erhaltenen Quelle das Ziel der Inklusion ist.

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

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

[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 wie folgt in Included Items konvertiert:

• Ein Entity Start Marker Information Item. Die [entity]-Eigenschaft wird zu einem Entity Declaration Information Item mit den folgenden Eigenschaftswerten:

  • [entity type] ist External General Entity.

    Issue (XInclude-66-entity-type): Das scheint etwas unwahr. Sollten wir nicht einen neuen Entity-Typ schaffen, anstatt einen alten zu verwenden?

  • [name] ist Null.

  • [system identifier] ist die Include Location für include.

  • [public identifier] ist Null.

  • [base URI] ist die Include Location für include.

  • [notation] ist Null.

  • [content] ist Null.

  • [charset] Der Name der Zeichenverschlüsselung, in der das Entity ausgedrückt wird.

    Issue (XInclude-62-text-encoding): Wie wird die Zeichenkodierung für Text erschlossen? Wir wollen nicht im Text nach einem formatspezifischen Hinweis sehen. Ist es angemessen zu schreiben, "Diese Eigenschaft wurde aus einem MIME-Header abgeleitet"?

• Für jedes Zeichen im ausgewählten Bereich wird ein Character Information Item erzeugt. Der Zeichenkode wird zu dem Zeichenkode, der das Zeichen laut ISO 10646 repräsentiert. Die [element content whitespace]-Flag wird auf false gesetzt.

• Ein Entity End Marker Information Item. Die [entity]-Eigenschaft wird auf die [entity]-Eigenschaft des korrespondierenden Entity Start Markers gesetzt.

Quellen, die in etwas anderes als Text auflösen, wenn parse="text" gesetzt ist, erzeugen einen Fehler.

3.4. Erzeugen des Ergebnis-Infosets

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

Das Information Item für das 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 ihm das "include-Element Information Item" genommen wird. Anstelle des include-Elements werden die folgenden Information Items in dieser Reihenfolge eingefügt:

• Ein Include Start Marker Information Item. Die [parent]-Eigenschaft dieses Items wird für das Include Parent gesetzt. Die [include element]-Eigenschaft wird für das Information Item gesetzt, welches das include-Element repräsentiert.

• Die Included Items. Die [parent]-Eigenschaft eines jeden Included Items wird für das jeweilige Include Parent gesetzt.

• Ein Include End Marker Information Item. Die [parent]-Eigenschaft dieses Items wird für das Include Parent gesetzt. Die [include element]-Eigenschaft wird für das Information Item gesetzt, welches das include-Element repräsentiert.

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

Im folgenden Beispiel zeigt die zweite Inklusion immer auf das erste <xinclude:include>-Element und nicht auf sich selbst, unabhängig von der Reihenfolge, in der die Inklusionen verarbeitet werden.

<x xmlns:xinclude="http://www.w3.org/1999/XML/xinclude">

  <xinclude:include href="something.xml"/>

  <xinclude:include href="#xpointer(x/xinclude:include[1])"

             parse="text"/>

</x>

<foo xmlns:x="uri1">

 <xinclude:include href="common.xml#xptr(a/b)"/>

</foo>

<a xmlns:x="uri2">

  <b>

    <x:a/>

  </b>

</a>

<foo xmlns:x="uri1">

  <b xmlns:x="uri2">

    <x:a/>

  </b>

</foo>

3.5. Infoset-Erweiterungen

5.1. Markup-Konformität

Ein Element Information Item ist XInclude-konform, wenn es die syntaktischen Anforderungen für include-Elemente erfüllt, die in dieser Spezifikation definiert wurden. Diese Spezifikation legt den DTDs keine besonderen Zwänge auf; 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.