RE: Is schemaLocation just a hint in schema import?

["Antoli, Leo" <Leo.Antoli@Misys.com>]

Thank you for all the responses, they were very useful.


If everything is up to the implementation, you can not make
platform-independent schemas; you'll need to change schemaLocation values
depending on the schema parser / XML tools you're using.

Shouldn't it be better to have some common requirements (e.g. absolute http
paths are required to be understood in schemaLocation, and they'll point to
the schema file)? And implementations could provide extra mechanisms.

I'm talking about schemaLocation in imports, agreed that schemaLocation in
XML instances to validate it should be typically ignored and apply your own
schema information, you don't want to rely on external party schemas.



-----Original Message-----
From: Michael Kay [mailto:mike@saxonica.com] 
Sent: 10 October 2006 08:41
To: noah_mendelsohn@us.ibm.com; 'Xan Gregg'
Cc: Antoli, Leo; xml-dev@lists.xml.org; xmlschema-dev@w3.org
Subject: 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