XML Resolver 6.0.8

As I’ve reported previously, the XML Resolver is coming along well. I’ve been busy on other things (and other things) (and other things) so, while I was aware that a few issues had accumulated, I hadn’t actually done anything about them. Now that Balisage 2024 is behind me, and before I dive back into SaxonJS, I thought it best to try to address them.

Good news all around, really: new users, new issues (some quite interesting), a couple of nice patches, and I was able to resolve all of the open issues. I’ve pushed a few releases out over the last couple of days:

1. I adopted JFK-DXML’s patch to fix some concurrency problems. (Thank you!)
2. I reworked how the feature for dealing with backslashes in Windows system identifiers works. This also allowed me to finally write some tests for Windows UNC paths which seem to work as expected.
3. I refactored the way the SAX EntityResolver and EntityResolver2 interfaces are implemented. I’d previously put them both on the same object, which had the unfortunate consequence that if you instantiated a SAX1 EntityResolver and subsequently asked if it was an instance of a SAX2 EntityResolver2, it would report true. That interacted badly with a bug in the SAX2 getExternalSubset API that was problematic. The getExternalSubset bug is fixed also.
4. The LSResourceAdapter API for validation of DOM documents didn’t support XML Schema validation. It didn’t even try to correctly resolve the schema based on the namespace URI. Now it does.
5. I removed the SLF4J and Apache HTTP Client APIs as dependencies. Neither were necessary and having fewer dependencies makes everything easier for integrators.
6. I added the NamespaceResolver interface back in as a deprecated API.

Removing the external dependencies and restoring the NamespaceResolver API makes XML Resolver 6.0.8 a drop-in replacement for the 5.x resolver, at least in the common cases. (It works, for example, with Saxon 12.5.)

If you have tried to use the 6.x resolvers and been unsuccessful, please try with 6.0.8 and report any problems that you have. I’ll give them a couple of weeks to settle, and I need to review the C# API to see if any of these fixes need to be ported there. Then I’m hoping to make a non-beta release.

I hope that the 5.x resolver API is on the glide path towards replacement, but since it’s still what I’d recommend for “production” use, I also published a 5.2.5 release that includes the concurrency and LSResourceAdpater fixes.