Saxon

Here is the response that I sent by email:

This appears to be a continuation of the thread at https://saxonica.plan.io/issues/5652

The conclusion of that thread, from a quick reading, was that in order to load a non-standard version of the XLink schema you needed to use a SchemaURIResolver. Is that what you are doing? Unfortunately the comments on the thread aren't always clear which Saxon version they are talking about, in particular my final comment #12 indicates that I made a change but (mea culpa) it doesn't say which versions are affected by that change.

I would appreciate it if you raise this as a support issue on saxonica.plan.io. (You can still send us code privately.) Using the public forum makes it much easier for us to work as a team on bringing the issue to a resolution, and it also means (as we've just seen) that we can revisit the conversation two years later.

As indicated in the previous thread, we're constrained in this area by the need to avoid making changes that will disrupt other users, and by the fact that there are many different variants of the XLink schema in the wild.

When I reviewed this yesterday, I persuaded myself that this was a different (or potentially different) bug than the one in #5652.

Having now got it up in the debugger and worked my way through the code, I think I was mistaken. As Mike observes near the end of the comments on that bug, the XLink namespace is handled specially. This is done to avoid unnecessary requests for resources on the web (especially to w3.org which throttles requests dramatically) and to avoid errors that arise from incorrect redeclarations of items in the schema. (XLink is a little odd in that defines only attributes and has a non-normative XSD.)

Bottom line: Saxon intentionally ignores schema location hints for the XLink schema.

You can substitute your own by providing an explicit catalog entry for it, for example:

<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"
         prefer="system">

  <uri name="http://www.w3.org/1999/xlink"
       uri="xsd/test/xlink.xsd"/>

</catalog>

Sorry about my misunderstanding yesterday.

I've verified that the catalog solution works with both the v5 and v6 XML Resolver implementations.

An added note: my memory on this is a bit hazy, but I seem to remember that the original motivation for treating the XLink namespace specially was an application in which different parts of the application attempted to load incompatible versions of the XLink schema from different places. There's no way that can be made to work under the current architecture; though in Saxon 13 we are introducing some modularity which will make it possible provided the two schemas are kept well separate.

Hi Norm,

You didn't really verify the solution because in our use case the schema is in the classpath and needs to be resolved dynamically. I'm not sure the catalog will work. I believe this means we have to provide a custom resolver?

We will give that a try.

Well, I didn't try to add a catalog, but I also didn't consider that you might not be able to do that. Are you saying that the XSD file is in the classpath but you don't know where, you don't know what it's resource name is?

The suggestion to use our own schema resolver + upgrading to latest xml resolver (6.0.11) unblocked this particular issue. I'll close this.

We're now running into a separate problem during load and I'll create a separate ticket for that.

Actually, I do not see the option to change the status so I assume only Saxonica members can do it.

Thank you!