[
Lists Home |
Date Index |
Thread Index
]
Joseph,
You're right, maybe (as I tried to hint) the use of "enterprise"
architecture is a red-herring. So how does any architecture, that has no
control on what version of a language producers produce and consumers
consume, handle schema evolution beyond changes that are purely additive?
(OK that's over egging the pudding, we do have some element of control).
It's these pointers I'm looking for.
I understand the use of governance, policies and procedures but that doesn't
seem workable, doesn't it cost too much? Is it not the schema design and any
associated processing strategies that will ultimately enable us to manage
change? I'm hoping so.
Cheers.
---
Andrew
>From: "Chiusano Joseph" <chiusano_joseph@bah.com>
>To: "Andrew Wheeler" <akwheel99@hotmail.com>, <xml-dev@lists.xml.org>
>Subject: RE: [xml-dev] Schema Evolution
>Date: Tue, 26 Oct 2004 16:10:04 -0400
>
> > -----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>
> >
> >
_________________________________________________________________
Want to block unwanted pop-ups? Download the free MSN Toolbar now!
http://toolbar.msn.co.uk/
|
