Re: [xml-dev] Namespaces best practice: managing dialect evolution--

[Ian Graham <igraham@ic-unix.ic.utoronto.ca>]

On Thu, 8 Nov 2001, David Carlisle wrote:

> 
> > Here you could use the namespace to 'flag' the old from the new. 
> 
....

> But if you change the namespace then you just have so completely changed
> the language that a whole class of tools simply can not easily work with
> both languages at the same time. That may be what you want, but if it is
> that big a change, is it really the same language any more?

In thinking about it a bit more, I believe what I'm really asking for is a
way of saying the following three things, in some standardized way, about
a particular chunk of XML:

  1) this data is written in a language coming from namespace 'X'
  2) the data syntax is consistent with version 'Y' of this language
  3) the contract implied by accepting to process this data is
     consistent with a specific contract 'Z' 

In my case I want the target application to know if the contract part (3)
has changed independent of any change in the data syntax itself, and stop
processing if it cannot obey the contract. If the contract hasn't changed,
then it should check to see if it can process the particular dialect I've
sent.

For many XML applications, (3) is likely not relevant.  

> For example any application accessing your documents by XPath (say xslt,
> or an XPath enabled DOM implementation) then all your XPath's will fail
> on the new (or old) language. It's not particularly easy to change an
> Xpath expression to work with both languages, so if you update your
> application, this is a really hard update and you no longer can process
> the old language at all (with the new tool). It seems a lot more useful
> that you stay in the same namespace but have conditional code in your
> processor depending on a version attribute.

Yes, I agree, although I wish there was a standardized or at least
accepted 'best practice' way of doing so.
 
> 
> > But that just seems so ugly and arbitrary, I am rather hoping there's a
> > better way....
> 
> No, versioning languages always has unpleasant side effects whatever you
> do. The only good solution is to get it right first time and never
> change, but that's not always easy to achieve...

Reality shows that nothing is right the first time :-( What I'm looking
for is some way of making the unpleasant side effects more predictable, or
at least manageable.

I'll try this issue out on the XML protocols list also, and see if anyone
there has thought about these things.  I'm quite new to this mode for
using XML, and may be way off base with my musings :-/

Thank you very much for your thoughs on this --

Ian