Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] XPath Data Model Mapping

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Wolfgang Hoschek <whoschek AT lbl.gov>
  • To: Elliotte Harold <elharo AT metalab.unc.edu>
  • Cc: xom-interest <xom-interest AT lists.ibiblio.org>
  • Subject: Re: [XOM-interest] XPath Data Model Mapping
  • Date: Mon, 17 Jan 2005 10:10:21 -0800

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.





Archive powered by MHonArc 2.6.24.

Top of Page