XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

On Jan 17, 2005, at 8:55 AM, Elliotte Harold wrote:

> The XPath support is coming together faster than I expected. I've 
> written up a summary of the impedance mismatches between XOM and 
> XPath: namespace nodes, rootless documents, adjacent text nodes, etc., 
> and how XOM addresses these:
>
> http://www.xom.nu/xpath.xhtml

For clarification to the curious, here's how those cases are treated in 
Nux and Saxon.

> Document Type Declaration
>
> The XPath data model does not include any representation of the 
> document type declaration. Therefore no XPath expression will select a 
> DocType object. Furthermore, the DocType object is not considered when 
> counting the number or position of a document's children using 
> position(), last(), count(), or similar functions in XPath.

Same behaviour for Nux and Saxon.

> Contiguous Text Nodes
>
> The XPath data model does not allow contiguous text nodes, or empty 
> text nodes. XOM does allow one Text object to immediately follow 
> another. When XPath queries are made on XOM documents, all contiguous 
> Text objects are treated as a single XPath text node.

>  Empty Text Nodes
>
>  Empty text nodes are a related issue. They do not exist in the XPath 
> data model, and they cannot be individually selected by XPath 
> expressions.

A XOM Text object is treated as an XPath node. So the behaviour is 
slightly different than XOM's. If this is not the desired behaviour, 
use XQueryUtil.normalizeTexts to gain fully standards-compliant 
semantics in these uncommon corner cases.

> Namespace Nodes
>
> XPath defines a namespace node as a namespace in scope on an element. 
> XOM mostly works with namespace declarations instead. When evaluating 
> XPath expressions that use the namespace axis, XOM uses the XPath 
> definition. However, XOM will never return any results containing 
> XPath namespace nodes. Expressions like /descendant::*/namespace::* 
> and .//* | .//namespace::* throw an XPathException. You can use the 
> namespace axis inside a location path. You just can't use it as the 
> final step that returns the nodes.

Same behaviour for Nux and Saxon, except that the string value of the 
namespace is returned on XPath output, rather than throwing an 
exception. A future release may throw an exception instead, I'm not 
sure.

>  Documentless Trees
>
>  XPath implicitly assumes that all nodes belong to a document. In XOM 
> this is not necessarily true. Nonetheless it is still useful to be 
> able to execute queries on nodes (and particularly trees of nodes) 
> that don't belong to any document. When an absolute XPath expression 
> such as /root/child or // is evaluated, XOM supplies a fictitious root 
> node. The effect is the same as if the actual top-level node in the 
> tree were contained in a document. For example, consider this query:
>   Element test = new Element("test");
>   Nodes result = element.query("/*[1]");
>
>  result contains the test because it is the first child of this 
> fictitious root. However, the query  / throws an XPathException 
> because it is attempting to return this fictitious root.

Absolute navigation (starting with "/") such as "//*" are undefined in 
XPath on documentless trees. In Nux and Saxon you need to use relative 
navigation for documentless trees starting from a context node, e.g. 
".//*". In this light, the XOM behaviour is reasonable but considered 
unnecessary.

>  Document Order
>
> XPath node-sets are unordered (like any set) and do not contain 
> duplicates. The Nodes object returned by the query method also does 
> not contain duplicates. However, it orders all nodes in document 
> order. Generally this is the order in which nodes would be encountered 
> in a depth first traversal of the tree. Attributes appear after their 
> parent element in this order and before any child elements. However, 
> otherwise their order is not guaranteed.

Same behaviour for Nux and Saxon, except that the XPath 2.0 model 
allows for duplicates.

>  Expressions that return non node-sets
>
> XOM only supports expressions that return node-sets as queries. 
> Expressions that return numbers, booleans, or strings throw an 
> XPathException. Examples of such expressions include count(//), 1 + 2 
> + 3, name(/*), and @id='p12'. Note that all of these expressions can 
> be used in location path predicates. They just can't be the final 
> result of evaluating an XPath expression.

If an XPath result contains atomic values (rather than nodes) on final 
output, those atomic values are by default converted to XOM Element 
nodes containing a XOM text object having the string value of the 
atomic value.