Converting 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, that is, as instances of
net.sf.saxon.om.NodeInfo
.
Saxon recognizes methods that expect nodes in an external object model (DOM, DOM4J, JDOM, or XOM). In all four cases, if the XPath node is actually a view of a DOM, DOM4J, 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, 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.
Note that it is generally not recommended to use extension functions that expect DOM nodes,
since the quirks of the DOM interface are such that a mapping from XDM to DOM is always
going to have odd behaviour in edge cases. The only real reason for using it is to interface
existing code that already uses the DOM. In general it is better to write extension functions
to use the NodeInfo
interface.