[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

> 
> 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/  

• Follow-Ups:
  • Re: Changing Namespaces Between Specification Versions
    • From: Andrew Welch <andrew.j.welch@g...>

• References:
  • Re: Changing Namespaces Between Specification Versions (was: XIN: XML implicit namespace definitions)
    • From: Andrew Welch <andrew.j.welch@g...>
  • Re: Changing Namespaces Between Specification Versions (was: XIN: XML implicit namespace definitions)
    • From: "Pete Cordell" <petexmldev@c...>
  • Re: Changing Namespaces Between Specification Versions
    • From: Chuck Bearden <cbearden@r...>
  • Changing Namespaces Between Specification Versions
    • From: Webb Roberts <strebor@g...>
  • Re: Changing Namespaces Between Specification Versions
    • From: "G. Ken Holman" <gkholman@C...>
  • Re: Changing Namespaces Between Specification Versions
    • From: Andrew Welch <andrew.j.welch@g...>
  • Re: Changing Namespaces Between Specification Versions
    • From: Fraser Goffin <goffinf@g...>
  • Re: Changing Namespaces Between Specification Versions
    • From: David Orchard <orchard@p...>
  • Re: Changing Namespaces Between Specification Versions
    • From: Andrew Welch <andrew.j.welch@g...>