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