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:

> 
> 
> > Since namespaces associate a name with a language dialect, what is a best
> > practice for "evolving" that namespace when the language evolves?
> 
> This is of course something of a religious question, and you'll get
> different answers from different people, but the answer I prefer is that
> the namespace name is (only) the name of the language dialect.
> 
> So if your new language is close enough to the old one to be called
> a new version of the same language, it should be in the same namespace.
> If it is really a new language with just an historic association with
> the old language, then it should be in a new namespace.
> 
> So, MathML 2, being version 2 of MathML, uses the same namespace as
> MathML 1. If at some point in the future we decided MathML was all wrong
> and we want to do YetAnotherMarkupLanguageForMath then that would be in
> a new namespace.
> 
> If you change the namespace then, to a namespace aware processor, the
> name of _every_ construct in the language has changed, as the name of
> each element is the namespace/local-name pair. It's hard to argue that
> if you have changed the name of every construct in a language that it is
> just an incremental version change.

These are good points (which I hadn't thought of) -- and for languages
like MathML, XHTML, SVG and so on I agree entirely.

Another case, however, would be a language used as an exchange protocol
between applications. In this case a 'language' change may involve (at one
extreme) no change in the language schema, but instead important changes
in the side-effect processing of the involved applications (for example,
one version may assume a tertiary database is not updated by the target
application, while the other may assume that the target app does the
update). In this case, you don't want an application to accept the message
unless it knows about (and can handle) the 'new' version with the new
implied contract.

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

I guess you could break messages parts into language classes -- parts that
are pure data models with no side-effects, and others that are
protocol-based and have potential side-effects. Then you could retain the
same namespace for different versions of the data model languages, and
evolve the namespace for the others.....

But that just seems so ugly and arbitrary, I am rather hoping there's a
better way....

Thanks --

Ian