Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Schema Evolution
 Ian, I suppose the harsh realities of life impact on the ideal .... theres no silver bullet. We would like components to understand any version (backwards, forwards or non-backwards compatible), but the reality seems like we wont 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. Cheers. --- Andrew >From: Ian Graham <ian.graham@u...> >To: Chiusano Joseph <chiusano_joseph@b...> >CC: Andrew Wheeler <akwheel99@h...>, xml-dev@l... >Subject: Re: 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 :-( > >Ian > >Chiusano Joseph wrote: >>>-----Original Message----- >>>From: Andrew Wheeler [mailto:akwheel99@h...] Sent: Tuesday, >>>October 26, 2004 2:12 PM >>>To: xml-dev@l... >>>Subject: 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 >>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. >>> >>>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> >>> >>> >> >>----------------------------------------------------------------- >>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! http://www.msn.co.uk/messenger 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
