BTW: Just to note that Saxon 11.3 has been working fine for me under Basex 9.x, But it requires including the included xmlresolver files in the class path:
export CLASSPATH=/usr/local/Cellar/saxon/11.3/libexec/saxon-he-11.3.jar:/usr/local/Cellar/saxon/11.3/libexec/lib/*.jar
But I haven’t done any special testing using the resolver from either Saxon or BaseX — Just running my current development code without noticing any problems.
( If you only include saxon-he-11.3.jar, xslt:processor() and xslt:version() will make it appear that it’s working under BaseX, but xslt:transform() will fail on not finding resolver classes. )
I’ve had my share of resolver issues in the past, and happily discovered that by upgrading JDK, I could get resolver to work in some apps without any code change, just by adding '-Djavax.xml.catalog.files=…’ to the command line. But I spent a lot of effort trying to get resolver to work in cases where it apparently wasn’t intended to work ( like for XInclude’s ). I think Norm’s replacement does try to provide a lot more functionality — I’ll have to try intentionally using it!
— Steve M.
On Jul 7, 2022, at 5:26 AM, Christian Grün christian.gruen@gmail.com wrote:
Hi Vincent,
XML catalogs and Java 8 are an ungrateful combination indeed. As you know, support for catalogs will improve a lot with BaseX 10, as JDK 11 comes with its own catalog resolver. With BaseX 10, we’ll also support Norm’s XML resolver, as you’ve already discovered (we’ll update our documentation soon).
Due to limited resources, we decided to focus on the new version exclusively. It’s interesting to hear, though, that your code is working with BaseX 9 and Java 17. Maybe it’s the inbuilt XML resolver that’s used by Java 17, no matter if an external resolver is added to the classpath? All I can do is guess …
Maybe JDK developers would be able to answer that question if we managed to create some self-contained code in Java?
Best, Christian