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.gr...@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
smime.p7s
Description: S/MIME cryptographic signature
