[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Schema Evolution

• To: xml-dev@l...
• Subject: Schema Evolution
• From: "Andrew Wheeler" <akwheel99@h...>
• Date: Tue, 26 Oct 2004 18:12:12 +0000
• Bcc:

Hello All,

I have an open-ended question which I don't expect a definitive answer to, 
nor solutions, but your experiences or pointers to useful information would 
be invaluable.

How do enterprise architectures expect to cope with "Schema evolution"? I 
know this is a very generic question and doesn't just apply to XML Schema's 
(nor enterprise architectures) . I've read a number of papers that have been 
referenced here on XML-Dev ([1], [2], [3], [4], [5]) but would like more 
information in order for me to understand potential solutions. Having read 
the papers I feel they discuss extensibility as oppose to versioning (I 
might be wrong as it's just a feeling). One can think about extensibility as 
a bilateral agreement between a single producer and a single consumer where 
as versioning has enterprise wide implications, you've no idea who might be 
consuming. (I have no real experience on this scale of coping with such an 
issue, nor do most people by the sounds of it).

Just to amplify the problem ... Each change cycle we release a version of a 
language** with new capabilities, rectifying earlier errors, etc. We do not, 
nor believe we can, guarantee backwards compatibility between versions. 
Therefore our enterprise contains mixed, non-backwards compatible versions. 
We have versioning and extensibility issues, controlled evolution through 
versioning, uncontrolled user defined evolution through extensibility. For 
the moment, due to particular circumstances, we are able to cope with change 
but the future will be somewhat different (as take up of the language grows 
within the maturing enterprise).

Sorry for the waffle and sorry if this has been asked a thousand times 
before. Many thanks in advance.

Andrew

It's like trying to arrange deckchairs on the Titanic.

[1] XML Schema Libraries and versioning: The UBL case. 
http://www.idealliance.org/papers/dx_xmle03/papers/03-04-03/03-04-03.pdf
[2] Versioning XML Vocabularies. 
http://www.xml.com/pub/a/2003/12/03/versioning.html
[3] Providing Compatible Schema Evolution. 
http://www.pacificspirit.com/Authoring/Compatibility/ProvidingCompatibleSchemaEvolution.html
[4] Designing Extensible, Versionable XML Formats. 
http://www.xml.com/lpt/a/2004/07/21/design.html
[5] Reach Interoperability Guidelines (RIGs). 
http://sdec.reach.ie/rigs/rig0006/pdf/rig0006_v0_3.pdf


** The model we have is actually defined in UML (pure UML - not a marked up 
XML version) for which we automatically generate an XSD. We have fine 
granularity of configuration control in the logical UML model, but as yet do 
not take advantage of this in the physical XML model. We have looked at 
using namespaces (or hard coded attributes) within the physical XML schema 
to indicate version granularity but are looking for experience to guide us. 
To give you an idea of scale the auto generation creates 1100 complex types 
and 250 simple types, which knit together 2100 distinct elements and 60 
distinct attributes We know the scale won't necessarily dictate the strategy 
we choose.

_________________________________________________________________
Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

• Follow-Ups:
  • Re: Schema Evolution
    • From: "Guillaume Lebleu" <gl@b...>

• Prev by Date: RE: Partyin' like it's 1999
• Next by Date: Re: Schema Evolution
• Previous by thread: RE: Partyin' like it's 1999
• Next by thread: Re: Schema Evolution
• Index(es):
  • Date
  • Thread