Saxon

Just to qualify the last paragraph: I think that when a schema imports the XML namespace, Saxon will always use its built-in version of the schema for that namespace, rather than fetching it via a resolver. This schema is "pre-cooked" in Saxon, we don't load it from a lexical schema document at all. Trying to provide a modified version of this schema will, I think, have no effect.

The reason for this is that it would be completely undefined what should happen if you modified some of the built-in declarations of attributes such as xml:space and xml:base. Those are things that users shouldn't be allowed to tamper with.

Added screenshot.

Thanks Jorge, now that we know we're talking about Saxon 10 this makes more sense. We made a lot of changes in this area in Saxon 11, so that tends to be our mindset at the moment.

Answering questions about the rationale of the change is a little difficult as it's so long ago (5 years?). As far as I can see the code you're looking at in Saxon 10 was unchanged from 9.8 and 9.9, but there was a change between 9.7 and 9.8 - in 9.7 if you imported the XLink schema with a different location hint, we respected the location hint.

Can I assume you're migrating from 9.7 or an earlier version?

This seems to have been documented as a change made in response to bug 3092, which states: "In addition, for 9.8 I have changed the handling of the XLink namespace so that the version issued with Saxon is used, regardless of the supplied schemaLocation URI. Users wanting a different version of the XLink schema, for example the old OpenGIS version, will then need to supply their own SchemaURIResolver."

I suspect the problem that motivated the change was dealing with the situation where different versions of the XLink schema are loaded concurrently. This would typically lead to Saxon rejecting the schema as invalid. Because different application-level standards have issued their own copy of the XLink schema with variations, this would otherwise make these schemas incompatible with each other.

I don't think the position is unreasonable that if you want a non-standard version of the XLink schema, you have to use your own schema resolver to supply it. (Alternatively, you could pre-load the schema into the Saxon Configuration). And I'm afraid any change would be hard to contemplate: we're managing the 10.x branch for maximum stability now, and a change in behaviour that might affect other users would be undesirable indeed. Your other option would be to move forward to Saxon 11, where the whole resolver architecture has been redesigned.

No we didn't upgrade from 9.7. The issue was moving to resolver from https://xmlresolver.org/

The scenario where different XLink schema can be loaded concurrently can apply to any other standard schema. Why would your platform provide a special case for XLink over anything else? It would be good to understand how Saxon uses XLink to understand the impact of our changes to the schema. Ultimately as users of your platform, it's our responsibility to ensure that that schemas we choose work well together.

I understand not wanting to make a change in 10.x -- makes sense.

Taking a quick look at your code for version 11.4, it seems the behavior is still there. You ignore all locations for XLink. I don't think upgrading will fix the issue.

Hey Norm,

1 Saxon contains a standard schema resolver that given the xlink namespace uses its own copy and completely ignores our modified one.

Is that true even if you put an entry in the catalog you’re using that points to the version you want to use?

Correct. The catalog will never be consulted. Look at the code in Saxon 10.6 for the Standard Schema Resolver. XLink is inserted and the URLHandler is never consulted, so catalog resolution will never occur.

I can understand the rationale behind caching xml.xsd -- but you are actually not doing that. You are caching xlink.xsd -- and we don't understand why. Also, this is totally undocumented we had to decompile the standard schema resolver to figure out that you were doing that.

The rationale was to avoid stalling requests to www.w3.org.

If the rationale is to avoid stalling requests in w3.org then I believe you should not do this in the Standard Schema Resolver (com.saxonica.ee.config.StandardSchemaResolver) to resolve XLink.xsd. The way things are written in 10.x, the URL resolver is completely bypassed. We're stuck with what you give us no matter what.

In 11.x you don't by-pass the URL Resolver, but you still completely ignore our location, so you force us to use a Catalog -- even though we tell the validator specifically which XSD to use. Why do this for XLink?

Is it possible to provide a small test case that demonstrates the problem?

It's difficult, because the worse part of the issue (the stalling) is env specific and probably related to a bug in xmlresolver

Having said this, if you remove the special case for XLink in com.saxonica.ee.config.StandardSchemaResolver the issue will go away. You should consider doing this in 11.x I don't understand why you need the special case, it doesn't sound like you need it especially if you have xmlresolver in the mix.

I've been doing some tests in this area (on the 11.x branch).

Firstly, I confirmed that if you supply a SchemaURIResolver, you can intercept a request for the XLink namespace, and return any schema document you like.

Secondly, I confirmed that if you import the XLink namespace supplying a location hint, without a SchemaURIResolver, the location hint is ignored. That is certainly conformant behaviour - processors are allowed (and even encouraged) to ignore the location hint if they already have built-in knowledge of the schema for the namespace. I think it's also desirable behaviour, because a lot of people are going to specify a location such as http://www.w3.org/..., and a local hard-baked copy should take precedence. Moreover, if we changed the behaviour, the change would be very disruptive.

Thirdly, I've confirmed that if we remove the special-case code in StandardSchemaResolver, it will attempt to use the location hint on the xs:import declaration. That immediately tells us that removing this code would be disruptive to other users; it might cause the schema document to be fetched over the web unnecessarily, or it might cause a failure, or it might cause a different version of the XLink schema to be loaded.

Fourthly: is it possible to map the XLink namespace to a user-supplied version of the XLink schema using a user-supplied catalog? Yes, I've tried this and it works.

So: if you try and pick up a local variant of the Xlink schema using a location hint, you won't succeed, but if you do it using a SchemaURIResolver or a catalog, it seems to work fine. I don't intend to change that behaviour, but I will try to make sure it is documented.

I've done yet more testing, and I've established that while you can use a SchemaUriResolver to get a non-standard XLink schema loaded, you can't use the processor-level resolver, at least not in the expected way. The StandardSchemaResolver is issuing a ResourceRequest to the processor-level resolver for the standard W3C location https://www.w3.org/1999/xlink.xsd, whereas I think it should be issuing a request for the target namespace http://www.w3.org/1999/xlink. Changed this. This could have an impact on anyone currently using a resolver or catalog that expects to see the URI https://www.w3.org/1999/xlink.xsd rather than http://www.w3.org/1999/xlink