[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Changing Namespaces Between Specification Versions

  • From: "Michael Kay" <mike@s...>
  • To: "'Andrew Welch'" <andrew.j.welch@g...>,"'David Orchard'" <orchard@p...>
  • Date: Fri, 24 Apr 2009 09:49:55 +0100

RE: Changing Namespaces Between Specification Versions
> 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

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

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


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.