Lists Home |
Date Index |
> -----Original Message-----
> From: Andrew Wheeler [mailto:firstname.lastname@example.org]
> Sent: Tuesday, October 26, 2004 2:12 PM
> To: email@example.com
> 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
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.
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 (, , , , ) 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.
> It's like trying to arrange deckchairs on the Titanic.
>  XML Schema Libraries and versioning: The UBL case.
>  Versioning XML Vocabularies.
>  Providing Compatible Schema Evolution.
>  Designing Extensible, Versionable XML Formats.
>  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
> 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>