RE: Versioning of XML Schema and namespaces

>>I think in practice the question comes down to either requiring the use 
of schemaLocation and ensuring that it is respected for the processing 
you care about (and can control or influence) or ignoring 
schemaLocation, if present, and using some external mechanism to bind 
namespaces to schemas on a case-by-case basis.<<

XBRL requires a sophisticated taxonomy (actually DTS - "discoverable
taxonomy set") discovery process involving traversing Xlink arcs through
linkbases as well as the ususal schema discovery issues. Accordingly we
leveraged the XML Linking specification (which we use already in defining
taxonomies) and defined our own schema (and linkbase) discovery elements'
syntax and semantics. See http://tinyurl.com/974bh and
http://tinyurl.com/974bh - the schemaRef and linkbaseRef elemets kick off
the process.

Hugh Wallis
XBRL International Inc.
  

-----Original Message-----
From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org] On
Behalf Of Eliot Kimber
Sent: Wednesday, May 04, 2005 10:37 PM
To: xmlschema-dev@w3.org
Subject: Re: Versioning of XML Schema and namespaces


Biron,Paul V wrote:
> 
> Remember, however, the xsi:schemaLocation [1] is just a hint...schema
> processors are not required to honor it.  In a similar vein, the
> presence of <!DOCTYPE> in an instance does not mean that processors
> must perform DTD validation, although most processors do so by
> default.

Of course I realize this. But in the case where schemaLocation is not 
respected, you are simply back to the case where there is no 
schemaLocation, in which case it's up to the processor to select the 
appropriate schema by whatever means.

In practice your documents are almost certainly going to be processed in 
an environment over which you have enough control to determine exactly 
how schemaLocation is handled and what happens when there is no explicit 
schemaLocation.

So the fact that schemaLocation is a hint doesn't change the fact that 
it is the only thing in a schema-based world that is the functional 
equivalent of public IDs for external DTD subsets, that is, a reference 
to a specific resource, in which it is appropriate to encode some sort 
of version-specific information.

I think in practice the question comes down to either requiring the use 
of schemaLocation and ensuring that it is respected for the processing 
you care about (and can control or influence) or ignoring 
schemaLocation, if present, and using some external mechanism to bind 
namespaces to schemas on a case-by-case basis.

This binding could be done using per-document XML catalogs, or metadata 
enbedded in the document (e.g., "myns:schemaVersion='1.x'"), or metadata 
held in a content management system and provided to the schema-aware XML 
processor on demand.

For example, my toy schema-aware XML content management system, XIRUSS-T 
(http://xiruss-t.sourceforge.net/), is specifically designed to maintain 
a name-space-to-schema-document mapping and makes that mapping available 
through an API. It also provides a general document-level metadata 
mechanism by which applications could change the namespace-to-schema 
association for specific documents.

Or said another way, because the association between documents and 
schemas is merely a hyperlink association and not a syntactic inclusion 
(as for external DTD subsets), once a document is out of your sphere of 
control, you have no way of knowing what will be done with it so there's 
no point in worrying about it. So the only case worth talking about is 
the one where you do in fact control how the document-to-schema 
assocation is done, in which case schemaLocation is either respected or, 
if it's not, you've provided an alternative. So in that case, saying 
"schemaLocation is a hint" is meaningless--in this context it's either a 
directive(because we've made the choice to always respect it) or it's 
ignored if specified (because we've made the choice to do something else).

There is no meaningful use case in which the treatment of schemaLocation 
is unpredictable. Or perhaps more accurately: the use cases in which the 
treatment of schemaLocation is unpredictable are not useful use cases so 
there's not point in discussing them.

Cheers,

Eliot
-- 
W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(512) 372-8155

ekimber@innodata-isogen.com
www.innodata-isogen.com

Received on Thursday, 5 May 2005 19:26:04 UTC