Saxon Documentation

Full Contents

About Saxon

Changes in this Release

Conditions of Use

Using XSLT 2.0

Using XQuery

Handling Source Documents

XML Schema Processing

XPath API for Java

Saxon on .NET

Extensibility
	Introduction
	Writing extension functions in Java
»	Converting Arguments to Java Extension Functions
	Converting the Result of a Java Extension Function
	Writing extension functions for .NET
	Converting Arguments to .NET Extension Functions
	Converting the Result of a .NET Extension Function
	Writing XSLT extension instructions
	Customizing Serialization
	Implementing a collating sequence
	Localizing numbers and dates
	Adding an output encoding
	Writing a URI Resolver for Input Files
	Writing a URI Resolver for Output Files

Saxon Extensions

Sample Saxon Applications

The Saxon SQL Extension

XSLT Elements

XPath 2.0 Expression Syntax

Function Library

Standards Conformance

Converting Nodes and Sequences of Nodes

If the expected type is a generic collection type, or an array of the Saxon class NodeInfo, or a Value or SequenceIterator, Saxon will pass the nodes supplied in the call in their native Saxon representation.

Saxon recognizes methods that expect nodes in an external object model (DOM, JDOM, or XOM) only if the supporting JAR file is on the classpath (that is, saxon8-dom.jar, saxon8-jdom.jar, or saxon8-xom.jar). In all three cases, if the XPath node is actually a view of a DOM, JDOM, or XOM node, then the underlying node will be passed to the method. If the XPath node is a text node that maps to a sequence of adjacent text and/or CDATA nodes in the underlying model, the first node in this sequence will be passed to the extension function.

In addition, in the case of DOM only (but only if saxon8-dom.jar is on the classpath), if the XPath node is not a view of a DOM node, Saxon will create a DOM wrapper for the native Saxon node, and pass this wrapper. This is also done if the required type is a DOM NodeList. Note that the wrapper is a read-only DOM implementation: any attempt to update nodes through the wrapper interface will throw an exception. A consequence of the way the wrapping works is that it's not safe to rely on object identity when testing node identity - the same node can be represented by more than one Java object. Use the DOM method isSameNode() instead.