Cart
[Home] [By Thread] [By Date] [Recent Entries]
Andrew, Imagine the following. You have an XML Schema or WSDL A, and an implementation of it (i.e. full service including relevant wrapper logic, business logic and calls to other Web Services with WSDL a, b and c). Wouldn't it be nice if, given a new XML Schema A', a', b' or c', your IDE would show you at compile time which statements in your implementation are not compatible with the new XML Schema B ? With modern, visual tools and languages that use XML Schema as their native type system, this is possible. So, my answer to you is that enterprises will either have to: - restrict their use of some XML Schema features to those that their existing tools/languages handle well (Ex. using abstract types instead of xsd:choice, using optional fields instead of required fields, dropping most of the facet constraints, etc.), so they can apply their tools/languages static type checking feature to manager changes. Quite a problem, especially in a world where your constraints come more and more from the outside (customers, partners) than the inside. - adopt a brute force approach, where hundreds/thousands of tests are semi-automatically generated to test existing implementations according to new schema versions. Not very scalable. - or upgrade to new implementation tools that natively support XML Schema features (i.e. with a type system based on XML Schema). Hope this helps, Guillaume Lebleu Brixlogic ----- Original Message ----- From: "Andrew Wheeler" <akwheel99@h...> To: <xml-dev@l...> Sent: Tuesday, October 26, 2004 11:12 AM 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"? 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/ProvidingCompatibleSchemaEvolution.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>
|
