[
Lists Home |
Date Index |
Thread Index
]
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@hotmail.com>
To: <xml-dev@lists.xml.org>
Sent: Tuesday, October 26, 2004 11:12 AM
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"? 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>
|
