Deutsche Übersetzung des Last Call Working Drafts
XML Inclusions (XInclude) Version 1.0

Achtung: Neuere Version in englischer Sprache beim W3C!
Die Candidate Recommendation wird wahrscheinlich nicht übersetzt. Einige Abschnitte sind in der neuen Version hinzugekommen, einige weggefallen. Die Aktualisierung erfolgt spätestens mit Erscheinen der Recommendation.

Die Originalversion in englischer Sprache ist zu finden unter:
http://www.w3.org/TR/2001/WD-xinclude-20010516

Diese Übersetzung ist zu finden unter:
http://www.schumacher-netz.de/TR/2001/WD-xinclude-20010516-de.html

Vorherige Übersetzung:
http://www.schumacher-netz.de/TR/2000/WD-xinclude-20001026-de.html

Die aktuelle Übersetzung ist zu finden unter:
http://www.schumacher-netz.de/TR/xinclude.html

Dieses Dokument ist ein Working Draft, ein Arbeitsdokument, das zur Diskussion um XInclude aufruft. Die Verwendung als normative Referenz ist in diesem Stadium nicht erlaubt. (siehe: Status dieses Dokuments)

Dieses Dokument kann Übersetzungsfehler enthalten. Kommentare oder Anregungen senden Sie bitte per Email an den Übersetzer. Sollten Sie Fragen zum Thema haben, schreiben Sie einfach.

Bedanken möchte ich mich hiermit bei Jonathan Marsh, der mir schnell (selbst im Email-Zeitalter noch sehr schnell) und freudig meine Fragen beantwortet hat.

Weitere Übersetzungen zum Thema XML finden Sie auf den Seiten des Übersetzers oder beim W3C

Übersetzer: Stefan Schumacher (sts@schumacher-netz.de)
Urheberrecht

W3C Logo

XML Inclusions (XInclude) Version 1.0

W3C Working Draft 16 May 2001

Diese Version:
http://www.w3.org/TR/2001/WD-xinclude-20010516
Aktuelle Version:
http://www.w3.org/TR/xinclude
Vorherige Version:
http://www.w3.org/TR/2000/WD-xinclude-20001026
Editoren:
Jonathan Marsh (Microsoft) <jmarsh@microsoft.com>
David Orchard (Jamcracker) <dorchard@jamcracker.com>

Vorwort

Dieses Dokument gibt ein Verarbeitungsmodell und eine Syntax für allgemein anzuwendende Inklusion an. Inklusion wird durch die Zusammenfassung verschiedener XML-Infosets in ein einzelnes zusammengesetztes Infoset erreicht. Die Spezifikation der XML-Dokumente (Infosets), die zusammengefasst werden sollen, und die Handhabung des Zusammenfassungsprozesses werden in XML-harmonischer Syntax (Elemente, Attribute, URI-Verweise) ausgedrückt.

Status dieses Dokuments

Die XML Core Working Group erwartet mit diesem "2001 May 16 XInclude Last Call working draft" Kommentare zu der Spezifikation. Der Zeitraum für diesen letzten Aufruf erstreckt sich vom 16. Mai bis zum 05. Juni 2001.

Die W3C-Mitglieder und andere Interessierte sind dazu eingeladen, diese Spezifikation zu überprüfen und über erste Implementierungserfahrungen zu berichten. Bitte senden Sie Kommentare (in englischer Sprache) an www-xml-xinclude-comments@w3.org. Archiv der Kommentare.

Obwohl wir Berichte über Implementierungserfahrungen begrüßen, wird die XML Core Working Group keine frühe Implementierung erlauben, um die Möglichkeit zu wahren, Veränderungen an dieser Spezifikation vornehmen zu können, bevor die endgültige Version verabschiedet wird.

Hintergrundinformationen zu dieser Arbeit finden Sie im XML Activity Statement.

Eine Liste der aktuellen W3C-Empfehlungen und andere technische Dokumente können unter http://www.w3.org/TR/ eingesehen werden.

Inhaltsverzeichnis

1. Einleitung
  1.1. Beziehung zu XLink
  1.2. Beziehung zu XML External Entities
  1.3. Beziehung zu DTDs
  1.4. Beziehung zu XML Schemata
  1.5. Beziehung zu Grammatik-abhängigen Inklusionen
2. Terminologie
3. Syntax
4. Verarbeitungsmodell
  4.1. Die Include Location
  4.2. Included Items bei parse="xml"
    4.2.1. Document Information Items
    4.2.2. Mehrfachknoten
    4.2.3. Bereiche
    4.2.4. Element, Comment und Processing Instruction Information Items
    4.2.5. Attribute und Namespace Declaration Information Items
    4.2.6. Inklusions-Schleife
  4.3. Included Items bei parse="text"
  4.4. Erzeugen des Ergebnis-Infoset
    4.4.1. Unparsed Entities
    4.4.2. Notationen
    4.4.3. Bleibende Eigenschaften des Infosets
5. Konformität
  5.1. Markup-Konformität
  5.2. Anwendungs-Konformität
  5.3. Konformität gegenüber XML Information Set

Anhänge

A. Verweise
B. Verweise (nicht-normativ)
C. Beispiele (nicht-normativ)
  C.1. Grundlegende Inklusions-Beispiele
  C.2. Beispiel einer Bereichs-Inklusion
  C.3. Beispiel einer Text-Inklusion

1. Einleitung

Viele Programmiersprachen besitzen einen Inklusionsmechanismus, um Modularität zu vereinfachen. Bezeichnersprachen bedürfen ebenfalls oft eines solchen Mechanismusses. Dieses Dokument schlägt einen generischen Mechanismus vor, um XML-Dokumente (wie in ihren Information Sets niedergelegt) für die Anwendungen zusammenzufassen, die eine solche Vereinfachung fordern. Die Syntax entspricht vorhandenen XML-Formen: Elemente, Attribute und URI-Verweise.

Die Anforderungen, an denen sich die Entwicklung von XInclude orientieren soll, können im XML Inclusion Proposal, W3C Note vom 23. November 1999 [XInclude] eingesehen werden.

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.

2. Terminologie

[Definition: ] Die Schlüsselworte müssen, nicht dürfen, erforderlich, können, empfehlen und optional in dieser Spezifikation sind zu verstehen, wie in RFC 2119 [IETF RFC 2119] beschrieben.

3. Syntax

XInclude definiert einen Namensraum, der mit dem URI http://www.w3.org/1999/XML/xinclude verbunden ist. Der XInclude-Namensraum enthält ein einziges Element mit dem lokalen Namen include. Zur Vereinfachung wird dieses Element innerhalb dieser Spezifikation als xi:include bezeichnet.

Das Element xi:include hat die folgenden Attribute:

href
Einen URI-Verweis, der den Ort der Quelle angibt, die inkludiert werden soll. Dieses Attribut ist erforderlich.
parse
Eine Aufzählung, die angibt, ob die Quelle als verarbeitetes XML oder als Text inkludiert werden soll. Der Wert "xml" zeigt an, dass die Quelle als XML verarbeitetet werden muss und die Infosets zusammengefügt werden müssen. Der Wert "text" zeigt an, dass die Quelle als der Inhalt eines Textknotens eingefügt werden muss. Dieses Attribut ist optional. Wenn kein Wert angegeben ist, wird der Wert "xml" angenommen (auch ohne die Deklaration eines Default-Wertes). Andere Werte als "xml" und "text" sind Fehler.
encoding
Wenn parse="text" gesetzt ist, ist es eventuell nicht möglich, die Verschlüsselung der Textdatei richtig zu ermitteln. Das Attribut encoding gibt an, wie die Quelle übersetzt werden muss. Der Wert dieses Attributs ist ein EncName wie in der XML 1.0 Spezifikation, Abschnitt 4.3.3, Regel [81] beschrieben ist. Das Attribut encoding wird nicht berücksichtigt, wenn parse="xml" gesetzt ist.

Attribute aus anderen Namensräumen können vom Element xi:include verwendet werden. Unqualified attribute names sind für zukünftige Versionen dieser Spezifikation reserviert und müssen von XInclude 1.0 Prozessoren ignoriert werden.

Der Inhalt des Elements xi:include wird nicht durch diese Spezifikation vorgegeben.

Das folgende (nicht normative) XML Schema veranschaulicht das Inhaltsmodell für das Element xi:include:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns:xi="http://www.w3.org/2001/XInclude"
           targetNamespace="http://www.w3.org/2001/XInclude">

  <xs:element name="include">
    <xs:complexType mixed="true">
      <xs:attribute name="href" type="xs:anyURI" use="required"/>
      <xs:attribute name="parse">
        <xs:simpleType>
          <xs:restriction base="xs:string">
            <xs:enumeration value="xml"/>
            <xs:enumeration value="text"/>
          </xs:restriction>
        </xs:simpleType>
      </xs:attribute>
      <xs:attribute name="encoding" type="xs:string"/>
      <xs:anyAttribute />
    </xs:complexType>
  </xs:element>

</xs:schema>

Das folgende (nicht normative) DTD-Fragment zeigt eine Beispiel-Deklaration für das Element xi:include:

<!ELEMENT xi:include EMPTY>
<!ATTLIST xi:include
    xmlns:xi   #FIXED   "http://www.w3.org/2001/XInclude"
    href       CDATA                                   #REQUIRED
    parse      (xml|text)                              "xml"
    encoding   CDATA                                   #IMPLIED
>

4. Verarbeitungsmodell

Inklusion, wie in diesem Dokument definiert, ist ein bestimmter Typ der 'XML Information Set' [XML Infoset] Transformation.

[Definition: ] Die Ausgangsdatei für die Inklusionstransformation besteht aus einem Quell-Infoset. [Definition: ] Die Ausgabe, Ergebnis-Infoset genannt, besteht aus einem neuen Infoset, welches aus dem Quell-Infoset und den Infosets zusammengesetzt wird, deren Quellen durch URI-Verweise in xi:include-Elementen identifiziert werden. Folglich wird ein Mechanismus zur Auflösung von URIs vorausgesetzt, der die identifizierten Quellen als Infoset zurückgeben kann. Wohlgeformte XML-Entities, die keine Infoset-Definition besitzen (z.B. eine externe Entity-Datei mit mehreren Top-Level-Elementen), liegen außerhalb des Rahmens dieser Spezifikation, sowohl in Bezug auf die Verwendung als Quell-Infoset als auch in Bezug auf die Verwendung als Ergebnis-Infoset.

Inklusion wird durch die Anwesenheit von xi:include-Elementen im Quell-Infoset angezeigt. [Definition: ] Die Information Items, deren Ort vom Element xi:include angezeigt wird, werden Included Items genannt. Das Ergebnis-Infoset ist im Wesentlichen eine Kopie des Quell-Infoset, in dem alle Include-Elemente durch ihre korrespondierenden Included Items ersetzt worden sind.

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.

Anmerkung: Die Einzelheiten, wie ein Infoset erzeugt wird, bleiben absichtlich unspezifiziert, um Flexibilität in Implementationen zu erlauben und um zu vermeiden, ein bestimmtes Verarbeitungsmodell für Komponenten der XML-Architektur zu definieren. Einzelheiten zur Validierung über eine DTD oder ein XML Schema werden von dieser Spezifikation zum Beispiel nicht vorgeschrieben.

Anmerkung: Die Zeichenverschlüsselung der einschließenden und der eingeschlossenen Quelle kann unterschiedlich sein. Das beeinflusst jedoch nicht das daraus hervorgehende Infoset, muss aber eventuell bei jeder späteren Serialisation berücksichtigt werden.

[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.2.1. Document Information Items

Eine Include Location kann das Document Information Item identifizieren (zum Beispiel einen URI-Verweis ohne einen XPointer, oder ein XPointer der genau auf die Dokumentenwurzel zeigt). In diesem Fall sind die Included Items die [children] des Document Information Items des betreffenden Acquired Infosets, außer für das Document Type Declaration Information Item-Kind, sofern eines existiert.

Bemerkung: Die Spezifikation XML Information Set trägt keine Vorsorge zur Erhaltung von Leerzeichen außerhalb des Dokumentelements. XInclude sieht keine weitergehende Möglichkeit vor, diese Leerzeichen zu erhalten.

4.2.2. Mehrfachknoten

Eine Include Location mit einem XPointer kann Unterquellen identifizieren, die aus mehr als einem Knoten bestehen. In diesem Fall ist die Zusammenfassung der Included Items die Zusammenfassung der Information Items des Acquired Infoset, abhängig von den Knoten, auf die vom XPointer verwiesen wird, und zwar in der Reihenfolge, in der sie im Acquired Infoset erscheinen.

Ist das Dokumentelement (Top Level Element) im Quell-Infoset ein xi:include-Element, ist es ein Fehler zu versuchen, es durch mehr als ein einzelnes Element zu ersetzen.

4.2.3. Bereiche

Eine Include Location mit einem XPointer kann eine Bereichszusammenfassung identifizieren, die einen Bereich oder mehrere Bereiche repäsentiert.

Jeder Bereich entspricht einer Zusammenfassung von Information Items in dem Acquired Infoset. [Definition: ] Ein Information Item wird bezeichnet als von einem Bereich ausgewählt, wenn es (in der Dokumentreihenfolge) nach dem Startpunkt des Bereichs und vor dem Endpunkt des Bereichs auftaucht. [Definition: ] Ein Information Item wird bezeichnet als von einem Bereich teilweise ausgewählt, wenn es nur den Startpunkt des Bereichs oder den Endpunkt des Bereichs enthält. Laut Definition kann ein Charakter Information Item nicht teilweise ausgewählt sein.

Der Satz der Included Items ist die Gesamtheit, in Dokumentreihenfolge mit entfernten Duplikaten, der durch den Bereich ausgewählten oder teilweise ausgewählten Information Items. Die [children]-Eigenschaft der ausgewählten Information Items wird nicht verändert. Die [children]-Eigenschaft der teilweise ausgewählten Information Items ist der Satz der Information Items die entweder ausgewählt oder teilweise ausgewählt sind, und so weiter.

4.2.4. Element, Comment, und Processing Instruction Information Items

Eine Include Location, die einen XPointer enthält, kann einen Elementknoten, einen Kommentarknoten oder einen Verarbeitungsanweisungsknoten indentifizieren, beziehungsweise ein Element Information Item, ein Comment Information Item oder ein Processing Instruction Information Item repräsentieren. In diesem Fall besteht der Satz der Included Items aus dem Information Item des korrespondierenden Element-, Kommentar- oder Verarbeitungsanweisungs-Knotens in dem Acquired Infoset.

4.2.5. Attribute und Namespace Declaration Information Items

Eine Include Location, die einen XPointer enthält, könnte einen Attributknoten oder einen Namensraumknoten identifizieren. Der Versuch, einen solchen Knoten zu inkludieren, resultiert in einem Fehler.

4.2.6. Inklusions-Schleife

Wenn ein xi:include-Element rekursiv verarbeitet wird, wird es als Fehler angesehen, wenn ein anderes xi:include-Element mit einer Include Location verarbeitet wird, die schon in der Inklusionskette verarbeitet wurde.

Mit anderen Worten, das Folgende ist erlaubt:

  • Ein xi:include-Element kann auf das Dokument verweisen, das dieses Include-Element enthält, wenn parse="text" gesetzt ist.

  • Ein xi:include-Element kann einen anderen Teil der gleichen lokalen Quelle identifizieren.

  • Zwei nicht verschachtelte xi:include-Elemente können eine Quelle identifizieren, die selbst ein Include-Element enthält.

Das Folgende ist nicht erlaubt:

  • Ein xi:include-Element, das auf sich selbst oder irgendeinen seiner Nachfahren zeigt, wenn parse="xml" gesetzt ist.

  • Ein xi:include-Element, das auf irgendein Include-Element oder Nachfahren davon zeigt, die bereits in einer höheren Ebene verarbeitet wurden.

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:

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.

Beachte: Es gibt zur Zeit keinen Standard, der Fragment Identifier für den Medientyp text/plain definiert.

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>

4.4.1. Unparsed Entities

Jedes Unparsed Entity Information Item, das in der [references]-Eigenschaft eines Attributs der Included Items auftaucht, wird zu der [unparsed entities]-Eigenschaft des Document Information Items des Quell-Infosets hinzugefügt, sofern es kein Duplikat eines existierenden Mitglieds ist.

Unparsed Entity Items mit gleichen Eigenschaften in Bezug auf [name], [system identifier], [public identifier], [declaration base URI], [notation name] und [notation] werden als Duplikate betrachtet. Eine Anwendung kann auch durch die Erkennung anderer Eigenschaften feststellen, dass Unparsed Entities Duplikate sind. Zum Beispiel, wenn der URI gleich ist, der durch die Kombination von System Identifier und Deklaration Base URI entsteht.

Es ist möglich, dass die entstehende [unparsed entities]-Eigenschaft Unparsed Entity Information Items mit dem gleichen Namen enthält. Diese können mit Hilfe der [references]-Eigenschaft des Attribute Information Item, das auf dieses Unparsed Entity verweist, auseinander gehalten werden. Die Serialisation eines solchen Ergebnis-Infoset kann anwendungsspezifische Eingriffe erfordern (zum Beispiel, Umbenennung).

4.4.2. Notationen

Jedes Notation Information Item, das in der [references]-Eigenschaft eines Attributs der Included Items auftaucht, wird zu der [notations]-Eigenschaft des Document Information Item des Quell-Infosets hinzugefügt, sofern es nicht ein Duplikat eines existierenden Mitglieds ist. Ebenso wird jede Notation hinzugefügt, die von einem Unparsed Entity referenziert wird, das wie in Unparsed Entities beschrieben, hinzugefügt wurde, es sei denn, es handelt sich um ein Duplikat.

Notation Items mit den gleichen Eigenschaften in Bezug auf [name], [system identifier], [public identifier] und [declaration base URI] werden als Duplikate angesehen. Eine Anwendung kann auch durch die Erkennung anderer Eigenschaften feststellen, dass Notationen Duplikate sind. Zum Beispiel, wenn der URI gleich ist, der durch die Kombination von System Identifier und Deklaration Base URI entsteht.

Es ist möglich, dass die entstehende [notations]-Eigenschaft [notations] mit dem gleichen Namen enthält. Diese können mit Hilfe der [references]-Eigenschaft auseinander gehalten werden. Die Serialisation eines solchen Ergebnis-Infoset kann anwendungsspezifische Eingriffe erfordern (zum Beispiel, Umbenennung).

4.4.3. Bleibende Eigenschaften des Infosets

Als eine Infoset-Transformation arbeitet XInclude mit der logischen Struktur eines XML-Dokuments, nicht mit ihrer Text-Serialisation. Alle anderen Eigenschaften eines Information Items, die nicht von diesem Proposal modifiziert werden, bleiben bei der Inklusion erhalten.

Bemerkung: Eigenschaften, die Merkmale über Vorfahren, Nachfahren, usw. (zum Beispiel die PSVI [validity]-Eigenschaft) beschreiben, werden eventuell nicht durch die Inklusion eines Dokumentteils validiert. Diese Spezifikation schreibt nicht vor, wie Prozessoren solche Eigenschaften behandeln sollten.

Bemerkung: Die Attribute xml:lang und xml:space werden nicht gesondert von XInclude verarbeitet.

4.4.3.1. Namensraum-Deklarationen

Die [in-scope namespaces]-Eigenschaft stellt sicher, dass der Namensraum bei der Inklusion erhalten bleibt. Jedoch beschreibt die [namespace attributes]-Eigenschaft nach der Inklusion eventuell nicht alle Namensraum-Deklarationen, die nötig sind, um das Ergebnis zu serialisieren. Wenn das Ergebnisinfoset serialisiert wird, können zusätzliche Namensraum-Deklarationen notwendig werden.

Zum Beispiel, ergibt das folgende Dokument:

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

mit einem Knoten aus common.xml inkludiert:

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

ein Dokument, das so serialisiert werden könnte:

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

Achtung, die Namensraum-Deklaration xmlns:x="uri2" wurde während der Serialisation hinzugefügt, und nicht vom XInclude-Prozessor der [namespace attributes]-Eigenschaft des Elements b zugeordnet. Wird dieses Infoset serialisiert und dann zurückverarbeitet, kann das entstehende Infoset von dem Infoset, das aus der Inklusionsverarbeitung entstanden ist, in der Form abweichen, dass die [namespace attributes]-Eigenschaft die Addition dieser Attribute wiederspiegelt.

Die Serialisation des Ergebnis-Infosets und besonders die Anordnung und Form von Namensraum-Deklarationen, wird von dieser Spezifikation nicht vorgeschrieben.

4.4.3.2. Base URI

Die Eigenschaft des Base URI des Acquired Infosets wird durch die Zusammenführung des Infosets nicht geändert, und bleibt nach der Verarbeitung unverändert. So werden relative URI-Verweise im Included Infoset zum gleichen URI aufgelöst, auch wenn sie eventuell in ein Dokument mit einer anderen Base URI inkludiert wurden. Ein serialisiertes Ergebnis-Infoset muss eventuell xml:base-Attribute hinzufügen, um diesen Umstand anzuzeigen.

5. Konformität

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:

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:

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:


Anhänge

A. Verweise

Character Model
Martin J. Dürst, François Yergeau, Misha Wolf, Asmus Freytag, Tex Texin. Character Model for the World Wide Web 1.0. World Wide Web Consortium, 2001. (Siehe http://www.w3.org/TR/charmod/.)
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.)
IETF RFC 2279
RFC 2279: UTF-8, a transformation format of ISO 10646. Internet Engineering Task Force, 1998. (Siehe http://www.ietf.org/rfc/rfc2279.txt.)
IETF RFC 2396
RFC 2396: Uniform Resource Identifiers. Internet Engineering Task Force, 1995. (Siehe http://www.ietf.org/rfc/rfc2396.txt.)
IETF RFC 2732
RFC 2732: Format for Literal IPv6 Addresses in URL's. Internet Engineering Task Force, 1999. (Siehe http://www.ietf.org/rfc/rfc2732.txt.)
IETF RFC 3023
RFC 3023: XML Media Types. Internet Engineering Task Force, 2001. (Siehe http://www.ietf.org/rfc/rfc3023.txt.)
Unicode
The Unicode Consortium. The Unicode Standard. (Siehe http://www.unicode.org/unicode/standard/standard.html.)
XML
Tim Bray, Jean Paoli, and C.M. Sperberg-McQueen, Editoren. Extensible Markup Language (XML) 1.0. World Wide Web Consortium, 1998. (Siehe http://www.w3.org/TR/REC-xml.)
XML Base
Jonathan Marsh, Editor. XML Base. World Wide Web Consortium, 1999. (Siehe http://www.w3.org/TR/xmlbase.)
XML Infoset
John Cowan and David Megginson, Editoren. XML Information Set. World Wide Web Consortium, 1999. (Siehe http://www.w3.org/TR/xml-infoset.)
XML Names
Tim Bray, Dave Hollander, and Andrew Layman, Editoren. Namespaces in XML. Textuality, Hewlett-Packard, and Microsoft. World Wide Web Consortium, 1999. (Siehe http://www.w3.org/TR/REC-xml-names/.)
XPointer
Steve DeRose, Ron Daniel, Eve Maler, Editoren. XML Pointer Language (XPointer). World Wide Web Consortium, 1999. (Siehe http://www.w3.org/TR/xptr.)

B. Verweise (nicht-normativ)

IURI
Internationalized URIs. Internet Engineering Task Force, 2000. Expired Internet-Draft. (Siehe http://www.w3.org/International/2000/03/draft-masinter-url-i18n-05.txt.)
XInclude
Jonathan Marsh, David Orchard, Editoren. XML Inclusion Proposal (XInclude). World Wide Web Consortium, 1999. (Siehe http://www.w3.org/TR/1999/NOTE-xinclude-19991123.)
XLink
Steve DeRose, Eve Maler, David Orchard, and Ben Trafford, Editoren. XML Linking Language (XLink). World Wide Web Consortium, 2000. (Siehe http://www.w3.org/TR/xlink/.)

C. Beispiele (nicht-normativ)

C.1. Grundlegendes Inklusions-Beispiel

Das folgende XML-Dokument enthält ein xi:include-Element, das zu einem externen Dokument zeigt.

<?xml version='1.0'?>
<document xmlns:xi="http://www.w3.org/1999/XML/xinclude">
  <p>120 Mz ist ausreichend für einen durchschnittlichen Benutzer.</p>
  <xi:include href="disclaimer.xml"/>
</document>

disclaimer.xml enthält:

<?xml version='1.0'?>
<disclaimer>
  <p>Die hier dargestellten Meinungen sind die eines
  Individuums und sollten nicht als offizielle Aussage dieser
  Organisation interpretiert werden.</p>
</disclaimer>

Das resultierende Infoset, das aus der Auflösung der Inklusionen in diesem Dokument entsteht, ist das gleiche wie im folgenden Dokument:

<?xml version='1.0'?>
<document xmlns:xi="http://www.w3.org/1999/XML/xinclude">
  <p>120 Mz ist ausreichend für einen durchschnittlichen Benutzer.</p>
  <disclaimer>
  <p>Die hier dargestellten Meinungen sind die eines 
  Individuums und sollten nicht als offizielle Aussage dieser 
  Organisation interpretiert werden.</p>
</disclaimer>
</document>

C.2. Beispiel einer Bereichs-Inklusion

Das Folgende stellt das Ergebnis einer Inklusion dar, die einen Bereich inkludiert, der von einem XPointer angegeben wird.

<?xml version='1.0'?>
<document>
  <p>Der relevante Auszug ist:</p>
  <zitat>
    <include xmlns="http://www.w3.org/1999/XML/xinclude"
       href="quell.xml#xpointer(string-range(kapitel/p[1],'Satz 2')  
                        /range-to (string-range(kapitel/p[2]/i,'3.',1,7)))"/>
  </zitat>
</document>

quell.xml enthält:

<kapitel>
  <p>Satz 1.  Satz 2.</p>
  <p><i>Satz 3.  Satz 4.</i>  Satz 5.</p>
</kapitel>

Das resultierende Infoset, das aus der Auflösung der Inklusionen in diesem Dokument entsteht, ist das gleiche wie im folgenden Dokument:

<?xml version='1.0'?>
<document>
  <p>Der relevante Auszug ist:</p>
  <zitat>
    <p>Satz 2.</p>
  <p><i>Satz 3.</i></p>
  </zitat>
</document>

C.3. Beispiel einer Text-Inklusion

Das folgende XML-Dokument inkludiert ein Arbeitsbeispiel in ein Dokument.

<?xml version='1.0'?>
<document xmlns:xi="http://www.w3.org/1999/XML/xinclude">
  <p>Das Folgende ist der Quelltext der Datei "data.xml":</p>
  <beispiel><xi:include href="data.xml" parse="text"/></beispiel>
</document>

data.xml enthält:

<?xml version='1.0'?>
<data>
  <item><![CDATA[Brooks & Sheilds]]></item>
</data>

Das resultierende Infoset, das aus der Auflösung der Inklusionen in diesem Dokument entsteht, ist das gleiche wie im folgenden Dokument:

<?xml version='1.0'?>
<document xmlns:xi="http://www.w3.org/1999/XML/xinclude">
  <p>Das Folgende ist der Quelltext der Datei "data.xml":</p>
  <beispiel>&lt;?xml version='1.0'?&gt;
&lt;data&gt;
  &lt;item&gt;&lt;![CDATA[Brooks &amp; Sheilds]]&gt;&lt;/item&gt;
&lt;/data&gt;</beispiel>
</document>