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 ]

My own experience, on a large enterprise Web services project, is that 
elegant schema / WSDL evolution is not possible. There is simply no way 
to constrain the schema changes such that all existing applications are 
guaranteed to work with the new versions. So we will create new services 
(and keep the old) if anything needs to change.  We hope that governance 
will help limit/control this revving process.

The situation is likely similar for other environments -- if you want to 
guarantee that all previous apps dependent on the schema work, then you 
can't change it.

If you think a schema change is idiot proof, you likely just haven't 
found a suitably qualified idiot :-(


Chiusano Joseph wrote:
>>-----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 
> 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
> architecture.
> 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.
>>It's like trying to arrange deckchairs on the Titanic.
>>[1] XML Schema Libraries and versioning: The UBL case. 
>>[2] Versioning XML Vocabularies. 
>>[3] Providing Compatible Schema Evolution. 
>>[4] Designing Extensible, Versionable XML Formats. 
>>[5] Reach Interoperability Guidelines (RIGs). 
>>** 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 
>>The xml-dev list is sponsored by XML.org 
>><http://www.xml.org>, an initiative of OASIS 
>>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>
> -----------------------------------------------------------------
> 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>

Ian Graham
H: 416.769.2422 / W: 416.513.5656 / E: <ian . graham AT utoronto . ca>


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

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