Up until now, Windward software has only provided support for XPath 1.0 functionality. By implementing the Saxon API we will have additional support for XPath 2.0.
What is Saxon?
Saxon is an API for processing XML documents that has been developed for both .NET and Java applications. The Saxon library allows evaluation of XPath expressions in the same sense as other libraries such as DOM or SAX do.
But Saxon provides a higher-level processing model than the other interfaces. For example, the DOM interface has the application traverse the relationship between nodes – often referred to as a tree-like model – whereas Saxon evaluates XPath expressions during processing rather than raw navigation of the object model.
Why is this important?
Because through Windward’s implementing the Saxon API, customers will be able to create better, more powerful XPath queries.
What is the difference between XPath 1.0 and XPath 2.0?
One of the largest differences between the two languages is the data model that they use. In XPath 1.0 the results are stored in a nodeset, which can only contain nodes. The nodeset data model always returns the results in the order they appear in the document. However, XPath 2.0 generalizes and expands on nodesets to form what is known as the sequence data model.
This data model allows for both nodes and atomic values to be stored. Now, the order in which the elements appear in the sequence is the order that they will be returned, which allows for custom ordering. Also, nodesets, by definition, cannot contain the same node more than once, whereas sequences allow for duplicate elements.
The type system in XPath 2.0 has also improved because it mixes strong and weak typing. Arithmetic and Boolean comparisons require operands that are atomic values. Therefore, if any one of the operands are nodes, then the node is atomized and the atomic value is extracted to be used in the comparison.
If the input document has been validated against a schema, the node may have a type annotation which will be used as the atomic value, otherwise the node is untyped and the atomic value will be set to untypedAtomic. Untyped atomic values will be converted to the appropriate type for the operation, following a weak typing method.
- XPath 2.0 is more powerful since it supports a larger set of data types. For example, XPath 1.0 supports four expression types: nodesets, Booleans, numbers, and strings. On the other hand, XPath 2.0 supports those four as well as many more including atomic values such as dates and URIs.
- XPath 2.0 also includes functions and operators for processing and constructing the different data types.
- In addition, nodes in XPath 2.0 such as elements and attributes can be associated with and processed as XML Schema types.
How will this affect existing customers?
Current Windward customers who are used to and have templates using XPath 1.0 will still have working templates because there is a backwards-compatibility mode. This is provided to ensure that XPath 2.0 expression results are the same as they were in XPath 1.0.
In addition, all that has to be done to use XPath 1.0 logic is add “version=1.0” as an attribute on the xsl:stylesheet element. Otherwise XML datasources will use XPath 2.0 logic, which includes more customization of data through functions and sequences.
Can you show a short example of using Saxon?
Sure. To implement Saxon, a document and an XPath expression need to be constructed. For example, the following creates a new document:
DocumentBuilderFactory docBuilderFactory = DocumentBuilderFactory.newInstance();
DocumentBuilder docBuilder = docBuilderFacory.newDocumentBuilder();
Document doc = docBuilder.newDocument();
and the following creates a new XPath expression:
XPathFactory xpathFactory = XPathFactory.newInstance();
XPath xpath = xpathFactory.newXPath();
Next, the created XPath object can be evaluated and the data can be accessed and returned from the document.
Got questions or comments?
Please let us know in the comments section below!
Author: Kylie Dale
Kylie is working toward a B.S. degree in Computer Science at the University of Colorado, Boulder. Originally from Northern California, she moved to Colorado partly for the snowboarding and the hiking. Kylie has a passion for programming, but if there’s any way for her to be outside that’s where you’d find her!
Other posts by Kylie Dale