RE: Is schemaLocation just a hint in schema import?

> Having said all that, I find the case for making 
> schemaLocation a hint on the instance to be more compelling 
> than on import.  We did try to keep them parallel, but 
> perhaps that was a mistake.  Maybe we should have provided a 
> mode in which the schemaLocation on import was mandatory, but 
> the processor could decline to validate at all if it was 
> unhappy using it.

I quite like the formula that we now use in XSLT (3.10.1):

"After resolving against the base URI, the way in which the URI reference is
used to locate a representation of a stylesheet module, and the way in which
the stylesheet module is constructed from that representation, are
implementation-defined. In particular, it is implementation-defined which
URI schemes are supported, whether fragment identifiers are supported, and
what media types are supported. Conventionally, the URI is a reference to a
resource containing the stylesheet module as a source XML document, or it
may include a fragment identifier that selects an embedded stylesheet module
within a source XML document; but the implementation is free to use other
mechanisms to locate the stylesheet module identified by the URI reference."

This makes clear, I think, that the intent of the spec is that the URI
should be used to locate the stylesheet module, but leaves plenty of room
for implementations to use catalogs or URIResolvers to define indirection
mechanisms, or to cache stylesheet modules in a pre-compiled format. Unlike
the "hint" formulation, it sends a strong message that whatever algorithm is
used to find the module, the URI is expected to be the primary input to that
algorithm, and I think it gives implementors and users a much clearer idea
of what behaviour to expect by default and how this might be configurable in
practice.

Michael Kay

Received on Tuesday, 10 October 2006 07:40:33 UTC