[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Schema Evolution
> -----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> > >
|
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
|