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?
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.