Most pain-free way to add XPath 3.0 to a codebase using dom4j

3
votes

From what I understand, SAXON is the only library which supports XPath 3.0 in Java. Its JAXP implementation only supports XPath 2.0. Its XPath 3.0 implementation should be called this way and requires me to build the document in the first place with its own API rather than using a JAXP-compliant API like DOM4J.

This is a pain because I'd been careful to abstract away everything that uses XPath to a proxy interface taking a JAXP node and xpath string as parameters, but this seems pointless if I have to refactor everything to use SAXON nodes from the top down.

Am I misunderstanding something? Is there a less painful way?

1
xpathsaxonjaxp
There are various XQuery 3.0 implementations in Java and XPath 3.0 is a subset of XQuery 3.0. As for JAXP, I don't know whether BaseX or eXist expose that API. As for Saxon, why do you think that XPath 2.0 is possible with Saxon and JAXP, but XPath 3.0 not? I think both versions can end up with results that JAXP can't handle, but in general I don't see a restriction to XPath 2.0. JAXP is pretty much geared towards XPath 1.0, that is all that makes having sequences of atomic values of a rich type system and of nodes difficult with an API that wants to return a node set or a single primitive val – Martin Honnen
saxonica.com/html/documentation9.6/conformance/jaxp.html – user291699
I have tried Saxon 9.7 HE and JAXP XPath with some sample expressions using XPath 3.0 and 3.1 features like ! or let or json-to-xml and they work fine. Some features like higher order functions or inline functions are not supported in HE but work in EE. – Martin Honnen

1 Answers

3
votes

I'm increasingly trying to encourage users to use the s9api API in preference to JAXP for XPath processing. There are a variety of reasons: the JAXP interface only gives very half-hearted support to tree models other than DOM; it really struggles with the extended type system of XPath 2.0 and now 3.0, and in the case of Saxon, it doesn't interoperate at all well with other XML technologies and APIs.

However, Saxon continues to support the JAXP XPath API, with all its limitations, both against its own tree model and against third-party tree models such as DOM4J.

One thing that we have dropped is support for the XPath services interface, whereby an application using the XPathFactory.newInstance() method will pick up Saxon if it's on the classpath. The reason for that is that you really need to know when you're writing an application whether you want an XPath 1.0 or 2.0 processor, and the JAXP mechanism gives you no way of saying which you want, or discovering which you have been given. The result was that a lot of applications were experiencing hard-to-diagnose failures when deployed with an incorrect classpath. If you want Saxon as your JAXP XPath provider you now have to ask for it explicitly.

It would be useful if you could be more specific about what you are trying to do, and how it is failing.