OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Wikipedia on XML

I agree with you about the lack of change management support.  What a non-breaking change is is a non-trivial question too.  There are clear examples at the extremes of breaking and non-breaking, but it is a bit gray in the middle.  Any structure change can break some assumption somewhere. 
If we are to preserve the option for declarative validation (schema is one example) then we need to integrate the change management with the schema technology - perhaps we need something analogous to a kind of NVDL for schema validation that can be configured with the local (or global) understandings of the correct structure to namespace (and possibly version attribute) mappings.  That would allow the external schema to evolve under one name and the internal understanding to evolve using the same namespace name while preserving the ability to do structural validation against multiple versions.  That approach would allow us to use new namespace names for significant semantic changes and still use a meaningful level of declarative structural validation.
The alternative is either optional everything with minimal usage of types (which seems to me to be worse than nothing) or embedding everything in the schema (which is what OFX did very early on - providing new element names for anything that changes).
On Wed, Aug 26, 2009 at 3:39 PM, <rjelliffe@allette.com.au> wrote:

> But you're here talking about versioning as an after-thought in order
> to fix legacy problems. If the versioning model was in place from the
> get go, perhaps this would have worked perfectly. I myself use a
> similar scheme, and it works for rather large and complex systems that
> use XML as a pipeline language.

Yes, if everyone had perfect foreknowledge, we would not have any
problems. And yes, if someone else has a problem we don't have, it is not
a real problem.

But I agree that having a worked out versioning system where the
subset/superset relationship between minor and major versions was made
explicit and could be coded for is good advice for old and new schemas.

But just imagine, if we dare, a world which where people didn't know
everything in advance, where there was risk from failure of the technology
and where it was the job of technology to try to cope with this! The best
made plans, etc.

In such a world, cruise ships would have life rafts, cars would have air
bags, and supermarkets would double-bag heavy items in case they split. Of
course, this is such a mad vision it is unrecognizeable. XML is Titanic!
Sorry for the sarcasm, it is probably not constructive. I feel like
Professor Claven explaining the theoretical "3rd" dimension to the

When there is a breaking change to a vocabulary (and schemas), and a
namespace change is forced, how do we minimize the impact and make it as
undisruptive as possible to running and deployed systems?

Rick Jelliffe


XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS