Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


RE: [xml-dev]Changing Namespaces Between Specification Versions

From: "Michael Kay" <mike@--------.--->
To: "'Andrew Welch'" <andrew.j.welch@-----.--->, "'David Orchard'"
Date: 4/24/2009 8:51:00 AM
> 
> How about this really simple practical example: your 
> application accepts the following xml:
> 
> <root>
>   <node>doSomething</node>
> </root>
> 
> You know this might change, so you wonder about using a 
> version attribute and/or a namespace, and what that namespace 
> should be.  (if you do use a namespace, you want it to 
> "brand" your xml appropriately).
> 
> A few months later your application changes to accept the 
> following xml:
> 
> <root>
>   <from>customer name</from>
>   <node>doSomething<node>
> </root>
> 
> There are already lots of customers sending you the original xml.
> What should happen here?

If "your application" is the only application that ever consumes this data,
then just modify the schema to add <from> as an optional element, and modify
your application to understand it.

If "your application" has been distributed around the world, or if other
applications read this data, and if these applications make no provision for
future extensions to the schema, then you're skewered whatever you do. No
tinkering with the schema is going to make unmodified applications behave in
a sanitary way with the new data.

> 
> Personally I would:  Use the same namespace for both, and add 
> version attribute to distinguish them. 

Yes: and this needs to be done right at the start, in anticipation of future
changes; and applications need to be written to check the version and/or to
follow some kind of policy like ignoring unrecognized elements.

> I would also have two 
> xsd's, and validate each instance based on its version number.

XSD 1.1 allows you to use conditional type assignment switched on the
version number, so you don't need two separate schemas, it can all go in
one.

But the essential point is that this is not primarily an issue of schema or
vocabulary design. It's primarily an issue of application design. If
applications aren't future-proof, nothing you do in a schema will keep them
working when the data changes.

Michael Kay
http://www.saxonica.com/  


_______________________________________________________________________

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@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php



transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent