Cart
[Home] [By Thread] [By Date] [Recent Entries]
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
|
