XML.com

XInclude Processing in XSLT
by Erik Wilde | Pages: 1, 2

This XPointer child sequence is equivalent to the XPath /*[1]/*[2]/*[4]/*[6] and identifies the sixth child (the xml-included-items div2) of the fourth child (the div1) of the second child (the body) of the second child (the spec) of the root node. The advantage of child sequences is that they work for elements that do not have an ID. The obvious disadvantage is that they are rather brittle and break easily when the document is modified. For somewhat improved stability of XPointers using child sequences, the ID mechanism and the child sequences can be combined, resulting in XPointers like this one:

http://www.w3.org/TR/2006/REC-xinclude-20061115/REC-xinclude-20061115.xml#element(xml-included-items/1)

In this case, the XPointer selects the fragment, which is located by first finding an element with the specified ID and then navigating the child sequence relative to that element (in this example, this fragment consists of the head of the identified part of the XML document).

Using XInclude

While a longer article about XInclude has already looked at how to use XInclude [2], the following examples briefly illustrate its main usages:

<xi:include href="example.xml"/>	Include the XML document `example.xml` from the same location as the source document.
<xi:include href="example.xml" xpointer="element(id754)"/>	Include the `element(id754)` fragment (i.e., the element with the ID `id754`) of the XML document `example.xml` from the same location as the source document.
<xi:include href="example.txt" parse="text" [ encoding="US-ASCII" ] />	Include the text document `example.txt` from the same location as the source document; if necessary, the character encoding of the text document can be explicitly specified.
<xi:include href="example.xml"> <xi:fallback>could not include "example.xml"</xi:fallback> </xi:include>	Include the XML document `example.xml` from the same location as the source document. If the document cannot be included, use the content of the `fallback` element instead. (Without `fallback`, failure to include a resource results in a fatal error.)

Using XIPr

XIPr is implemented as a single standalone XSLT 2.0 stylesheet. It can be used as a standalone XSLT implementation of XInclude, or it can be integrated into XSLT code for integrated XInclude processing. XIPr contains a template that by default initiates XInclude processing starting at the document element of the input document:

<xsl:template match="/*">
  <xsl:apply-templates select="." mode="xipr"/>
</xsl:template>

When using XIPr within other stylesheets, it should be imported so that XSLT's conflict resolution assigns a lower import precedence to XIPr's templates. XInclude processing can then be initiated at any node at any time, by following the pattern of XIPr's built-in template:

<xsl:template match="/*">
  <!-- do something ... -->
  <xsl:apply-templates select="$xinclude-candidates" mode="xipr"/>
  <!-- do something else ... -->
</xsl:template>

XIPr produces messages using XSLT's message instruction, which produces messages on the console or some similar output device (not in the result document, though). When encountering fatal errors (as defined by the XInclude specification), XIPr terminates processing using message as well.

XIPr depends on the stylesheet processor's ability to access and retrieve documents, so if documents other than files in the filesystem have to be accessed, it is important to check that the XSLT processor of choice supports the required URI schemes.

The important thing to notice is that XIPr processing has to be initiated using the xipr mode so that the templates in the XIPr stylesheet are used for processing the selected nodes.

Using XInclude

Using XIPr

Resources

Recommended for You

About O'Reilly

Community

Partner Sites

Shop O'Reilly