OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] Schema Evolution

[ Lists Home | Date Index | Thread Index ]

> -----Original Message-----
> From: Andrew Wheeler [mailto:akwheel99@hotmail.com] 
> Sent: Tuesday, October 26, 2004 2:12 PM
> To: xml-dev@lists.xml.org
> Subject: [xml-dev] Schema Evolution
> 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"? 

Sorry for my pickiness here: I'm not certain how you are using the term
"enterprise architecture here", but I do not believe that this very
important issue is related to an enterprise architecture in the
traditional sense of the term enterprise architecture. One may have an
*application* that is used to support the requirements described below,
that would be mapped to the Application Layer of an enterprise

In terms of SOA - that is, if the schema defines the payload of a
message that is associated with a service - this could be accomplished
through a governance body and their associated policies and procedures.

Kind Regards,
Joe Chiusano
Booz Allen Hamilton
Strategy and Technology Consultants to the World

> 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/Providing
> CompatibleSchemaEvolution.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
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org 
> <http://www.xml.org>, an initiative of OASIS 
> <http://www.oasis-open.org>
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS