custom nodeinfo implementation with saxon 97 - HE

Question

I have a custom NodeInfo, DocumentInfo and ExternalObjectModel implementation written with saxon 8.7.

I also need to support few custom functions. My understanding is that saxon 9.7 HE has better support, so trying to migrate from 8.7 based implementation to 9.7 HE.

1. Is there a way to switch off xslt functionality ? I don't need it for now.

Is s9api the recommended api to get the following features :

• To work with custom datamodels (I dont have xml documents)
• To support custom functions
• To provide custom implementation for current() function

current implementation has this pattern.

     XPathEvaluator eval = new XPathEvaluator(docw);
     eval.setNamespaceContext(new NamespaceContext() {
        // stripped off
     });
     List<DataNode> res = eval.evaluate(xpath);

Now, the XPathEvaluator is not accepting the 'NodeInfo' implementor. the evaluate is returning a string.

what are the relevant new api/classes in 9.7 ?

also, there is no saxon-xpath. I think that functionality is now part of Saxon-HE.

Answer 1

A lot has changed between 8.7 and 9.7 - you are talking about two releases separated by about 10 years, with 10 major releases and perhaps 100 maintenance releases intervening. While the changes to the NodeInfo interface between any two major releases will be very minor, they will accumulate over time to a significant difference.

Saxon 9.7 changed the DocumentInfo interface, replacing it (in effect) with a new TreeInfo object to hold information about a tree whether or not the root node is a document node.

A question like "what are the new api/classes in 9.7" is much too broad. We publish detailed change information at each major release, and the online interactive documentation has a change history which allows you to list changes by category between any two selected releases. With two releases as far apart as 8.7 and 9.7 it is a very long list, and there's no point even starting to summarise it here.

saxon-xpath was once a separate JAR file, I think the reason was probably so that you could keep it off your classpath to avoid JAXP applications picking it up by accident. The functionality is now in the main JAR file - except that Saxon no longer advertises itself as a JAXP XPath provider, to avoid this problem.

I would generally recommend use of the s9api interface to anyone writing Saxon applications especially if they need to transcend XSLT, XPath, XSD, and XQuery. The JAXP equivalents are much messier: they don't integrate well across tools, they are often not type-safe, they don't provide access to functionality in the latest W3C standards, etc. But if you're doing deep integration, e.g. defining your own object models and replacing system functions, then you're going to have to dig below s9api into internal lower-level APIs.

A great deal is possible here, but it's not 100% stable from one release to the next, and it's not always very well documented. We're happy to answer technical questions but we expect you to have a high level of technical competence if you tackle such integration.