[
Lists Home |
Date Index |
Thread Index
]
Thanks Guillaume.
The structure of our schema is quite relaxed, we use optional fields, we use
xsi:type etc etc. So we have all of the mechanisms in place to maximise
flexibility. The issue that arises is more when we introduce non backwards
compatible change. If all we did was add fields then I think we could cope
with documenting a strategy for ignoring.
I know the answer is going to be "don't do non backwards compatible change"
but our history shows we can't, however much we try.
A related subject here is the use of binding technologies. We are looking at
using EMF (or JAXB) for the creation of an API. For each release of the
model we would have to rebind and redeploy. This just doesn't sound right,
even if we were to stick to add only changes!.
Cheers.
---
Andrew
>From: "Guillaume Lebleu" <gl@brixlogic.com>
>To: <xml-dev@lists.xml.org>,"Andrew Wheeler" <akwheel99@hotmail.com>
>Subject: Re: [xml-dev] Schema Evolution
>Date: Tue, 26 Oct 2004 11:52:59 -0700
>
>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>
>
_________________________________________________________________
It's fast, it's easy and it's free. Get MSN Messenger today!
http://www.msn.co.uk/messenger
|
