mstaal
mstaal

Reputation: 630

Saxon representation of XPath evalutions

In Apache Xalan and the .NET XSLT processor, XPath evaluations can be represented by a DTMNodeIterator and an XPathNodeIterator, respectively. Does Saxan have an equivalent to these?

Upvotes: 0

Views: 208

Answers (1)

Michael Kay
Michael Kay

Reputation: 163322

The design in Saxon is different, but there are many points of similarity.

In Saxon, at the system programming level, which most users will not need to concern themselves with, the Expression object has a method Expression.iterate(context) which returns a SequenceIterator. Because this is XPath 2.0/3.1 rather than 1.0, the SequenceIterator can return any items (nodes, atomic values, or functions), not just nodes. There are many internal implementations of SequenceIterator; one of the most important is AxisIterator which is always used for navigation of XDM trees, typically using the XPath axes.

At the s9api level, which is designed as an API for typical user applications, an executable XPath expression is represented by an XPathSelector object. This is an Iterable so you can use for (Item item : selector) syntax rather than using the iterator explicitly; if you do use the iterator method then it actually returns an XdmSequenceIterator<XdmItem> but for all practical purposes you can use this as a java.util.Iterator<XdmItem>, where an XdmItem is a node, atomic value, or function.

Saxon 9.9 also introduces a streams-based API which has similarities to Linq. This allows you to navigate a tree using Java functional interfaces: you can now write things like:

for (XdmNode pack : testInput.select(
            child("package").where(attributeEq("role", "secondary"))).asListOfNodes() {
           ...
}

which completely hides the underlying iterators. This is equivalent to iterating over the result of XPath expression package[@role='secondary'], but it saves the cost of compiling the expression, which is often much greater than the execution cost.

Upvotes: 1

Related Questions