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