Re: XML Schemas: Best Practices ? Versioning

[Robin LaFontaine <robin@monsell.co.uk>]

Mary et al,

You are getting some sensible suggestions here and some experience. I 
think compatibility is an issue here, e.g. do you want:

(a) old instances to be valid against new version of schema, so new 
software runs with old data
OR
(b) old software to still run on the new data

These two requirements push you in the opposite direction - one 
person's compatibility is another's headache! You need to update the 
old data or the old software to move on. Try to avoid having to do 
both. Doing neither results in no progress.

Perhaps for (a) you change the target namespace and update the 
software (your solution 2), and for (b) you change the schema version 
only and leave the namespace (your solution 1, or 3 for big changes). 
Unfortunately life is usually more complex and you end up with a 
combination.

A key aspect of all this is to be able to identify and represent the 
changes. We are developing, for schemas and data, XML-aware 
comparators and representations of changes in XML so that users (of 
schemas or data) have some chance of finding out what the changes 
are. And for schema diffs you have to track through the two versions 
intelligently matching the names to find real changes. Not as easy as 
it looks. More info at [1].

Robin
[1]  http://www.deltaxml.com

At 3:57 pm +1000 6/9/01, Mike_Leditschke@nemmco.com.au wrote:
>Hi Mary.
>
>We had to make this decision about 12 months ago and decided
>to use #2 as well as encoding the equivalent information into the
>schemaLocation attribute.
>
>This was driven mainly by a reading of section 4.3.2 of the Schema
>structures document (as it was then), which implied that toolsets
>might end up using the schemaLocation OR the namespace
>to locate the schema. We figured we could always
>freeze one or the other depending on how the best practices
>evolved.
>
>As it turned out, I'm glad we did include the version in the schemaLocation
>as most of the tools to date have used this as the mechanism to
>pick up the relavent schema.
>
>Regards
>Michael
>
><OffTopic>
>
>I realise the best practices are about schemas but IMHO, the issue of
>versioning the XML content needs to be considered as well, for a
>versioning scheme to be effective. Naturally, this is domain specific
>
>As an example, we also added a version
>attribute on each transaction, within our transaction framework.
>The driver here was that the transaction could become
>disconnected from the document in which it was delivered, as multiple
>transactions directed to multiple backend systems can be delivered
>in a single document.
>
>By attaching a version attribute to each transaction,
>the backend processing can provide the appropriate logic switch for
>different versions, without knowledge of the schema version under which
>the transaction was delivered. This version attribute reflects the schema
>version
>at which the transaction structure last changed. This allows the schema
>version
>to progress without needing to touch the backend code to track these
>changes,
>except in the case where the application logic is affected.
>
></OffTopic>
>
>
...cut
-- 
-- -----------------------------------------------------------------
Robin La Fontaine, Monsell EDM Ltd
(XML file comparison, Engineering data exchange and management using XML)
Tel: +44 1684 592 144 Fax: +44 1684 594 504
Email: robin@monsell.co.uk      http://www.deltaxml.com