XInclude differs from the linking features described in the , specifically links with the attribute value show="embed". Such links provide a media-type independent syntax for indicating that a resource is to be embedded graphically within the display of the document. XLink does not specify a specific processing model, but simply facilitates the detection of links and recognition of associated metadata by a higher level application.

XInclude, on the other hand, specifies a media-type specific (XML into XML) transformation. It defines a specific processing model for merging information sets. XInclude processing occurs at a low level, often by a generic XInclude processor which makes the resulting information set available to higher level applications.

Simple information item inclusion as described in this specification differs from transclusion, which preserves contextual information such as style.

There are a number of differences between XInclude and or external entities which make them complementary technologies.

Processing of external entities (as with the rest of DTDs) occurs at parse time. XInclude operates on information sets and thus is orthogonal to parsing.

Declaration of external entities requires a DTD or internal subset. This places a set of dependencies on inclusion, for instance, the syntax for the DOCTYPE declaration requires that the document element be named - orthogonal to inclusion in many cases. Validating parsers must have a complete content model defined. XInclude is orthogonal to validation and the name of the document element.

External entities provide a level of indirection - the external entity must be declared and named, and separately invoked. XInclude uses direct references. Applications which generate XML output incrementally can benefit from not having to pre-declare inclusions.

Failure to load an external entity is normally a fatal error. XInclude allows the author to provide default content that will be used if the remote resource cannot be loaded.

The syntax for an internal subset is cumbersome to many authors of simple well-formed XML documents. XInclude syntax is based on familiar XML constructs.

XInclude defines no relationship to DTD validation. XInclude describes an infoset-to-infoset transformation and not a change in XML parsing behavior. XInclude does not define a mechanism for DTD validation of the resulting infoset.

XInclude defines no relationship to the augmented infosets produced by applying an XML schema. Such an augmented infoset can be supplied as the input infoset, or such augmentation might be applied to the infoset resulting from the inclusion.

Special-purpose inclusion mechanisms have been introduced into specific XML grammars. XInclude provides a generic mechanism for recognizing and processing inclusions, and as such can offer a simpler overall authoring experience, greater performance, and less code redundancy.

The xi:include element has the following attributes:

Attributes other than those listed above may be placed on the xi:include element. Unprefixed attribute names are reserved for future versions of this specification, and must be ignored by XInclude 1.0 processors.

The children property of the xi:include element may include a single xi:fallback element; the appearance of more than one xi:fallback element, an xi:include element, or any other element from the XInclude namespace is a fatal error. Other content (text, processing instructions, comments, elements not in the XInclude namespace, descendants of child elements) is not constrained by this specification and is ignored by the XInclude processor, that is, it has no effect on include processing, and does not appear in the children properties of the result infoset. Such content might be used by applications analyzing a pre-inclusion infoset, or be made available to an application post-inclusion through means other than the normal infoset properties.

The following (non-normative) DTD fragment illustrates a sample declaration for the xi:include element:

The xi:fallback element appears as a child of an xi:include element. It provides a mechanism for recovering from missing resources. When a resource error is encountered, the xi:include element is replaced with the contents of the xi:fallback element. If the xi:fallback element is empty, the xi:include element is removed from the result. If the xi:fallback element is missing, a resource error results in a fatal error.

The xi:fallback element can appear only as a child of an xi:include element. It is a fatal error for an xi:fallback element to appear in a document anywhere other than as the direct child of the xi:include (before inclusion processing on the contents of the element.) It is a fatal error for the xi:fallback element to contain any elements from the XInclude namespace other than xi:include.

Attributes may be placed on the xi:fallback element. Unprefixed attribute names are reserved for future versions of this specification, and must be ignored by XInclude 1.0 processors.

The following (non-normative) DTD fragment illustrates a sample declaration for the xi:fallback element:

The value of the href attribute, after escaping according to , is interpreted as either a URI reference or an IRI reference. The base URI for relative URIs or IRIs is the base URI of the xi:include element as specified in . The URI or IRI resulting from resolution of the normalized value of the href attribute (or the empty string if no attribute appears) to absolute URI or IRI form is called the include location.

The absence of a value for the href attribute, either by the appearance of href="" or by the absence of the href attribute, represents a case which may be incompatible with certain implementation strategies. For instance, an XInclude processor might not have a textual representation of the source infoset to include as parse="text", or it may be unable to access another part of the document using parse="xml" and an xpointer because of streamability concerns. An implementation may choose to treat any or all absences of a value for the href attribute as resource errors. Implementations should document the conditions under which such resource errors occur.

When parse="xml", the include location is dereferenced, the resource is fetched, and an infoset is created by parsing the resource as if the media type were application/xml (including character encoding determination).

Resources that are unavailable for any reason (for example the resource doesn't exist, connection difficulties or security restrictions prevent it from being fetched, the URI scheme isn't a fetchable one, the resource is in an unsupported encoding, or the resource is determined through implementation-specific mechanisms not to be XML) result in a resource error. Resources that contain non-well-formed XML result in a fatal error.

xi:include elements in this infoset are recursively processed to create the acquired infoset. For an intra-document reference (via xpointer attribute) the source infoset is used as the acquired infoset.

The portion of the acquired infoset to be included is called the inclusion target. The document information item of the acquired infoset serves as the inclusion target unless the xpointer attribute is present and identifies a subresource. XPointers of the forms described in and must be supported. XInclude processors optionally support other forms of XPointer such as that described in . An error in the XPointer is a resource error.

The is not specified in terms of the , but instead is based on the Data Model, because the XML Information Set had not yet been developed. The mapping between XPath node locations and information items is straightforward. However, xpointer() assumes that all entities have been expanded. Thus it is a fatal error to attempt to resolve an xpointer() scheme on a document that contains unexpanded entity reference information items.

The set of top-level included items is derived from the acquired infoset as follows.

When parse="text", the include location is dereferenced and the resource is fetched and transformed to a set of character information items. This feature facilitates the inclusion of working XML examples, as well as other text-based formats.

Resources that are unavailable for any reason (for example the resource doesn't exist, connection difficulties or security restrictions prevent it from being fetched, the URI scheme isn't a fetchable one, or the resource is in an unsupported encoding) result in a resource error.

The encoding of such a resource is determined by:

Byte sequences outside the range allowed by the encoding are a fatal error. Characters that are not permitted in XML documents also are a fatal error.

Each character obtained from the transformation of the resource is represented in the top-level included items as a character information item with the character code set to the character code in ISO 10646 encoding, and the element content whitespace set to false.

The discusses normalization of included text.

XInclude processors must perform fallback behavior in the event of a resource error, as follows:

If the children of the xi:include element information item in the source infoset contain exactly one xi:fallback element, the top-level included items consist of the information items corresponding to the result of performing XInclude processing on the children of the xi:fallback element. It is a fatal error if there is zero or more than one xi:fallback element.

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 may 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 item 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 item, 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.

An element information item conforms to this specification if it meets the structural requirements for include elements defined in this specification. This specification imposes no particular constraints on DTDs or XML schemas; conformance applies only to elements and attributes.

An application conforms to XInclude if it:

Support for the is not mandatory for full XInclude conformance. Authors are advised that use of xpointer() and other XPointer schemes than element() might not be supported by all conformant XInclude implementations.

This specification conforms to the . The following information items must be present in the input infosets to enable correct processing:

Additionally, XInclude processing might generate the following kinds of information items in the result:

XInclude extends the infoset with the property include history, which may appear on the following types of information items in the result:

XInclude also extends the infoset with the property language, which may appear on element information items in the result.