[
Lists Home |
Date Index |
Thread Index
]
> -----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
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>
>
>
|
