Table of contents

Appendices

4.5 Creating the Result Infoset

The result infoset is a copy of the source infoset, with each xi:include element processed as follows:

The information item for the xi:include element is found. The parent property of this item refers to an information item called the include parent. The children property of the include parent is modified by replacing the xi:include element information item with the top-level included items. The parent property of each included item is set to the include parent.

It is a fatal error to attempt to replace an xi:include element appearing as the document (top-level) element in the source infoset with something other than a list of zero or more comments, zero or more processing instructions, and one element.

Some processors may not be able to represent an element's in-scope namespaces property if it does not include bindings for all the prefixes bound in its parent's in-scope namespaces. Such processors Must, May, etc. therefore include additional namespace bindings inherited from the include parent in the in-scope namespaces of the included items.

The inclusion history of each top-level included items is recorded in the extension property include history. The include history property is a list of element information items, representing the xi:include elements for recursive levels of inclusion. If an include history property already appears on a top-level included items, the xi:include element information item is prepended to the list. If no include history property exists, then this property is added with the single value of the xi:include element information item.

The included items will all appear in the result infoset. This includes unexpanded entity reference information items if they are present.

Intra-document references within xi:include elements are resolved against the source infoset. The effect of this is that the order in which xi:include elements are processed does not affect the result.

In the following example, the second include always points to the first xi:include element and not to itself, regardless of the order in which the includes are processed. Thus the result of this inclusion is two copies of something.xml, and does not produce an inclusion loop error.

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

Unparsed Entities[top]

Any unparsed entity information item appearing in the references property of an attribute on the included items or any descendant thereof is added to the unparsed entities property of the result infoset's document information item, if it is not a duplicate of an existing member. Duplicates do not appear in the result infoset.

Unparsed entity items with the same name, system identifier, public identifier, declaration base URI, notation name, and notation are considered to be duplicate. An application Must, May, etc. also be able to detect that unparsed entities are duplicate through other means. For instance, the URI resulting from combining the system identifier and the declaration base URI is the same.

It is a fatal error to include unparsed entity items with the same name, but which are not determined to be duplicates.

Notations[top]

Any notation information item appearing in the references property of an attribute in the included items or any descendant thereof is added to the notations property of the result infoset's document information item, if it is not a duplicate of an existing member. Likewise, any notation referenced by an unparsed entity added as described in [Unparsed Entities], is added unless it is a duplicate. Duplicates do not appear in the result infoset.

Notation items with the same name, system identifier, public identifier, and declaration base URI are considered to be duplicate. An application Must, May, etc. also be able to detect that notations are duplicate through other means. For instance, the URI resulting from combining the system identifier and the declaration base URI is the same.

It is a fatal error to include notation items with the same name, but which are not determined to be duplicates.

references Property Fixup[top]

During inclusion, an attribute information item whose attribute type property is IDREF or IDREFS has a references property with zero or more element values from the source or included infosets. These values Must, May, etc. be adjusted to correspond to element values that occur in the result infoset. During this process, XInclude also corrects inconsistencies between the references property and the attribute type property, which might arise in the following circumstances:

• A document fragment contains an IDREF pointing to an element in the included document but outside the part being included. In this case there is no element in the result infoset that corresponds to the element value in the original references property.

• A document or document fragment is not self-contained. That is, it contains IDREFs which do not refer to an element within that document or document fragment, with the intention that these references will be realized after inclusion. In this case, the value of the references property is unknown or has no value.

• The result infoset has ID clashes - that is, more than one attribute with attribute type ID with the same normalized value. In this case, attributes with attribute type IDREF or IDREFS with the same normalized value might have different values for their references properties.

In resolving these inconsistencies, XInclude takes the attribute type property as definitive. In the result infoset, the value of the references property of an attribute information item whose attribute type property is IDREF or IDREFS is adjusted as follows:

For each token in the normalized value property, the references property contains an element information item with the same properties as the element information item in the result infoset with an attribute with attribute type ID and normalized value equal to the token. The order of the elements in the references property is the same as the order of the tokens appearing in the normalize value. If for any of the token values, no element or more than one element is found, the references property has no value.

Namespace Fixup[top]

The in-scope namespaces property ensures that namespace scope is preserved through inclusion. However, after inclusion, the namespace attributes property might not provide the full list of namespace declarations necessary to interpret qualified names in attribute or element content in the result. It is therefore not recommended that XInclude processors expose namespace attributes in the result. If this is unavoidable, the implementation Must, May, etc. add attribute information items to the namespace attributes property in order to approximate the information conveyed by in-scope namespaces.

Base URI Fixup[top]

The base URI property of the acquired infoset is not changed as a result of merging the infoset, and remains unchanged after merging. Thus relative URI references in the included infoset resolve to the same URI despite being included into a document with a potentially different base URI in effect. xml:base attributes are added to the result infoset to indicate this fact.

Each element information item in the top-level included items which has a different base URI than its include parent has an attribute information item added to its attributes property. This attribute has the following properties:

1. A namespace name of http://www.w3.org/XML/1998/namespace.

2. A local name of base.

3. A prefix of xml.

4. A normalized value equal to either the base URI of the element, or an equivalent URI reference relative to the base URI of the include parent. The circumstances in which a relative URI is desirable, and how to compute such a relative URI, are implementation-dependent.

5. A specified flag indicating that this attribute was actually specified in the start-tag of its element.

6. An attribute type of CDATA.

7. A references property with no value.

8. An owner element of the information item of the element.

If an xml:base attribute information item is already present, it is replaced by the new attribute.

Language Fixup[top]

While the xml:lang attribute is described as inherited by XML, the XML Information Set makes no provision for preserving the inheritance of this property through document composition such as XInclude provides. This section introduces a language property which records the scope of xml:lang information in order to preserve it during inclusion.

An XInclude processor Must, May, etc. augment the source infoset and the acquired infoset by adding the language property to each element information item. The value of this property is the normalized value of the xml:lang attribute appearing on that element if one exists, with xml:lang="" resulting in no value, otherwise it is the value of the language property of the element's parent element if one exists, otherwise the property has no value.

Each element information item in the top-level included items which has a different value of language than its include parent (taking case-insensitivity into account per [RFC3066]), or that has a value if its include parent is a document information item, has an attribute information item added to its attributes property. This attribute has the following properties:

1. A namespace name of http://www.w3.org/XML/1998/namespace.

2. A local name of lang.

3. A prefix of xml.

4. A normalized value equal to the language property of the element. If the language property has no value, the normalized value is the empty string.

5. A specified flag indicating that this attribute was actually specified in the start-tag of its element.

6. An attribute type of CDATA.

7. A references property with no value.

8. An owner element of the information item of the element.

If an xml:lang attribute information item is already present, it is replaced by the new attribute.

NOTE: 

The xml:space attribute is not treated specially by XInclude.

Properties Preserved by the Infoset[top]

As an infoset transformation, XInclude operates on the logical structure of XML documents, not on their text serialization. All properties of an information item described in [XMLIS] other than those specifically modified by this specification are preserved during inclusion. The include history and language properties introduced in this specification is also preserved. Extension properties such as [XMLSchemas] Post Schema Validation Infoset (PSVI) properties are discarded by default. However, an XInclude processor Must, May, etc., at user option, preserve these properties in the resulting infoset if they are correct according to the specification describing the semantics of the extension properties.

For instance, the PSVI validity property describes the conditions of ancestors and descendants. Modification of ancestors and descendants during the XInclude process can render the value of this property inaccurate. By default, XInclude strips this property, but by user option the property could be recalculated to obtain a semantically accurate value. Precisely how this is accomplished is outside the scope of this specification.