<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet href="../make-menu.xsl" type="text/xsl"?><html>
<head>
<this-is section="sourcedocs" page="thirdparty" subpage=""/>
<!--
Generated at 2011-12-09T20:47:22.916Z--><title>Saxonica: XSLT and XQuery Processing: Third-party Object Models: DOM, JDOM, XOM, and DOM4J</title>
<meta name="coverage" content="Worldwide"/>
<meta name="copyright" content="Copyright Saxonica Ltd"/>
<meta name="title"
content="Saxonica: XSLT and XQuery Processing: Third-party Object Models: DOM, JDOM, XOM, and DOM4J"/>
<meta name="robots" content="noindex,nofollow"/>
<link rel="stylesheet" href="../saxondocs.css" type="text/css"/>
</head>
<body class="main">
<h1>Third-party Object Models: DOM, JDOM, XOM, and DOM4J</h1>
<p><i>This section is relevant to the Java platform only.</i></p>
<p>In the case of DOM, all Saxon editions support DOM access "out of the box", and no special
configuration action is necessary.</p>
<p>Support for JDOM, XOM, and DOM4J is not available "out of the box"
with Saxon-HE, but the source code is open source (in sub-packages of <code>net.sf.saxon.option</code>)
and can be compiled for use with Saxon-HE if required.</p>
<div class="boxed"
style="border: solid thin; background-color: #B1CCC7; padding: 2px">In general, use of a third party tree implementation is much less efficient than using Saxon's
native <code>TinyTree</code>. These models should only be used if your application
needs to construct them for other reasons. Transforming a DOM can take up to 10 times longer than transforming the equivalent
<code>TinyTree</code>.</div>
<p>A support module for JDOM2 has been created, but is not released with Saxon 9.4 because JDOM2 at the time of
release was not yet sufficiently stable.</p>
<p>In addition, Saxon allows various third-party object models to be used to supply the input to a transformation or query.
Specifically, it supports JDOM, XOM, and DOM4J in addition to DOM. Since Saxon 9.2 the support code for these three models
is integrated into the main JAR files for Saxon-PE and Saxon-EE, but (unlike the case of DOM) it is not activated
unless the object model is registered with the <a class="bodylink" href="../javadoc/net/sf/saxon/Configuration.html"><code>Configuration</code></a>, which can be done either by including it in the
relevant section of the configuration file, or by nominating it using the method <a class="bodylink"
href="../javadoc/net/sf/saxon/Configuration.html#registerExternalObjectModel"><code>registerExternalObjectModel()</code></a>.
</p>
<p>For DOM input, the source can be supplied by wrapping a <code>DOMSource</code> around the DOM
Document node. For JDOM, XOM, and DOM4J the approach is similar, except that the wrapper classes are supplied
by Saxon itself: they are <a class="bodylink"
href="../javadoc/net/sf/saxon/option/jdom/DocumentWrapper.html"><code>net.sf.saxon.option.jdom.DocumentWrapper</code></a>,
<a class="bodylink" href="../javadoc/net/sf/saxon/option/xom/DocumentWrapper.html"><code>net.sf.saxon.option.xom.DocumentWrapper</code></a>, and
<a class="bodylink"
href="../javadoc/net/sf/saxon/option/dom4j/DocumentWrapper.html"><code>net.sf.saxon.option.dom4j.DocumentWrapper</code></a>, and
respectively. These wrapper classes implement
the Saxon <a class="bodylink" href="../javadoc/net/sf/saxon/om/NodeInfo.html"><code>NodeInfo</code></a> interface (which means that they also implement <code>Source</code>).</p>
<div class="boxed"
style="border: solid thin; background-color: #B1CCC7; padding: 2px">Note that the Xerces DOM implementation is not thread-safe, even for read-only access. Never use
a <code>DOMSource</code> in several threads concurrently, unless you have checked that the DOM
implementation you are using is thread-safe.</div>
<p>Saxon supports these models by wrapping each DOM, JDOM, XOM, or DOM4J node in a wrapper that implements
the Saxon <a class="bodylink" href="../javadoc/net/sf/saxon/om/NodeInfo.html"><code>NodeInfo</code></a> interface. When nodes are returned by the XQuery or XPath API, these
wrappers are removed and the original node is returned. Similarly, the wrappers are generally removed when
extension functions expecting a node are called.</p>
<p>In the case of DOM only, Saxon also supports a wrapping the other way around: an object implementing
the DOM interface may be wrapped around a Saxon <a class="bodylink" href="../javadoc/net/sf/saxon/om/NodeInfo.html"><code>NodeInfo</code></a>. This is done when Java methods expecting a
DOM Node are called as extension functions, if the <code>NodeInfo</code> is not itself a wrapper for a DOM <code>Node</code>.</p>
<p>You can also send output to a DOM by using a <code>DOMResult</code>, or to a JDOM tree by
using a <code>JDOMResult</code>, or to a XOM document by using a <code>XOMWriter</code>.
In such cases it is a good idea to set
<code>saxon:require-well-formed="yes"</code> on <code>xsl:output</code> to ensure that the
transformation or query result is a well-formed document (for example, that it does not contain
several elements at the top level).</p>
<table width="100%">
<tr>
<td>
<p align="right"><a class="nav" href="choosingmodel.xml">Next</a></p>
</td>
</tr>
</table>
</body>
</html>
