RE: How to Version XML Applications

Your examples seem to justify the advice, not contradict it. 
Are there counter examples for which using a namespace value 
is a good way to version?

I agree that when the namespace changes, one has a new 
language.  Recent experience with the rewrites made 
necessary because the programmer used the previous 
version of XSLT and didn't understand what would 
happen when the namespace changed leads me to accept 
Tim's point of view.  If a namespace change causes 
the existing code to fail, that's a new language; 
otherwise, we would have to tie it directly to 
the implementation.  I realize there is middle 
ground here, but it seems to me that trying to 
account for all the possible ways that a 
implementation evolution, language evolution, 
and local code interact is a can of worms not 
worth opening.

A version attribute seems to be the 80/20 approach.

len

From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com]

Norm Walsh writes:

> For XML-based
> [quoting Tim Bray...NRM]
> | languages, designers in general SHOULD NOT embed versioning
> | information in namespace names."  -Tim

> Sounds like good practice to me :-)

I think this is premature, or at least too categorical.  We haven't said 
what a version is and therefore what versioning information is.  That 
said, in the case of minor revisions, such as bug fixes, I suspect this is 
good advice:  don't change namespaces every time you add an optional 
attribute to an element.  In the case of a major evolution of a language, 
say HTML -> XHTML, I'm not so sure.  Who's to say that's not a "version" 
that deserves a new namespace, at least for its incompatible 
constructions, unless we define some terms?  I'm not sure we understand 
the cases in the middle where there are, perhaps, serious structural 
changes in a language that affect parts but not all of it.  If we 
completely reworked the table architecture in HTML, and left the rest of 
the language unchanged, should namespaces be used?  For just the new stuff 
or for everything?  What about the parents of the new stuff that now have 
(recursively up the tree) changed content models?  What if there is an 
incompatible change to an existing element (goes from MUST HAVE attribute 
to MUST NOT HAVE attribute)?  Are we really supposed to do all of this in 
one namespace?

Received on Friday, 13 September 2002 15:23:09 UTC