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 ]


I suppose the harsh realities of life impact on the ideal .... there’s no 
silver bullet. We would like components to understand any version 
(backwards, forwards or non-backwards compatible), but the reality seems 
like we won’t be able to guarantee they can understand what they get. I 
guess I always knew this, just wondered what strategies people had adopted 
in order to reduce the cost of change.



>From: Ian Graham <ian.graham@utoronto.ca>
>To: Chiusano Joseph <chiusano_joseph@bah.com>
>CC: Andrew Wheeler <akwheel99@hotmail.com>,  xml-dev@lists.xml.org
>Subject: Re: [xml-dev] Schema Evolution
>Date: Tue, 26 Oct 2004 21:29:13 -0400
>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 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 
>>>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 
>>>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 <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>
>>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>

It's fast, it's easy and it's free. Get MSN Messenger today! 


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

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