Re: XML Schemas: Best Practices ? Versioning

[Tony.Coates@reuters.com]

Let me start by saying that the comments about trying to avoid changing old instance documents with information about new Schema versions is too usage specific.  I would argue that old Schema versions should be available for validating documents against those versions, and applications should be able to rely on those old versions existing.  The idea that you will want to use the new Schema version for all legacy documents is very much an author-side wish, not an application-side wish, as has already been pointed out.  So more fleshing out is needed about the "rights" of an instance document to be validated against the Schema version that it was created for.  To continue with the rest,

On 05/09/2001 18:50:52 Mary Pulvermacher wrote:

>1. CHANGING THE SCHEMA VERSION ATTRIBUTE
> [ ... ] However, the validator ignores this field.

Yes, so #1 won't work unless you do a quick pre-parse and choose the Schema based on the version number.  Not out of the question, but a nuisance until you get set up for it.  One way to make this work is to have a RDDL document at the namespace URI, and in that document have the URIs for each Schema version.

>2. CHANGING THE SCHEMA'S TARGET NAMESPACE

I have had a number of discussions with MSMCQ about this, and the W3C view seems to be that this is not the way to go, as one namespace can correspond to many Schemas (and/or versions).  In particular, this is the result of the "3 Schemas, 1 namespace" decision for HTML.  In the purist view, the namespace is only for defining unique element names, and while different Schemas will use those element names in different structures, the names themselves often don't evolve as much as the Schemas.

From a practical point of view, changing the namespace can seem to be the only workable approach, since the "schemaLocation" is not required and can be ingnored.  Again, MSMCQ argues that the optionality of "schemaLocation" was intended to be the exception, and not the rule.  This has been confused by some validators ignoring the "schemaLocation" by default, but the point here is that while #2 can work, it is certainly not the W3C's annointed approach, and does risk conflict with future W3C specs.

>3. CHANGING THE NAME OF THE SCHEMA
>4. CHANGING THE LOCATION OF THE SCHEMA

These two seem to be the same, except that they focus on different parts of the schema location URI.  This would seem to be the W3C approved way to do it.  To make it work, what you need is to use some like an XML Catalog entity resolver that will let you redirect the "schemaLocation" URI to your local copy of the required version of the Schema.  Thus, the schemaLocation takes on the role of an identifier rather than an actual Schema location, and might even by a public ID URN of the form "urn:publicId:...".

So, I would suggest that #3/4 is the way to go, in spite of #2's appeal as the quick and dirty way to get something up and running.

     Cheers,
          Tony.
========
Anthony B. Coates
(1) Content Distribution Architect - Project Gazelle
(2) Leader of XML Architecture & Design - Chief Technology Office
Reuters Plc, London.
Tony.Coates@reuters.com
========



-----------------------------------------------------------------
        Visit our Internet site at http://www.reuters.com

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.