RE: Versioning Namespaces

Geoff,

Thanks.  I didn't realize until your note that we have different nightmares, and both of them are about interoperability.

I also agree that the level of attention that you suggest in 

	A significant percentage (possibly even a majority) of the hard 
	design work of WebDAV and its extensions has been 
	how to add in functionality in a way that is compatible with the 
	previous standards.  So I agree with Julian that the DAV namespace 
	should never be "rev"ed, but rather every new WebDAV protocol has 
	to figure out how to live within the single existing DAV namespace. 

will make it unnecessary to revise the namespace, although you don't entirely solve my nightmare with that approach.  The one problem that I have is that a changed or modified namespace is not construed by everyone (and definitely not me) as a "single existing ... namespace." 

Also, I am talking about namespace versioning, not revision.  Any change to a namespace is a revision, in my book.  A version is a differently-identified derivative, in my book.  Maybe there is better nomenclature for that. I am interested in suggestions for that.

Meanwhile ...

1.	Silent Up-Leveling Dangers

The java.lang "namespace" is more-or-less maintained the way you describe.  There are deprecated classes and methods, but they are still there.  There are also new elements that are added to the namespace from time to time.  

Reliance on new additions creates down-level compatibility problems, and it happens in a kind of blissful unawareness.  But if you distribute a class file, it can be found to not run on earlier versions of the JVM and its libraries precisely because an added feature has been relied on without concern for (or probably even any awareness of) version dependency.  For example, I am fond of

	double enteredValue = java.lang.Double.parseDouble(someInputString);

and in using it I am producing a program that will not operate with versions of Java prior to JDK 1.2.  If I make use of the 

	java.lang.String.matches(some-regular-expression) 

method, my program will not operate with any version of Java prior to JDK 1.4.

When I first started using Java (earlier this year in a course), I was meticulous about determining the earliest version my code would work with, and saying so in prominently placed comments and any documentation.  I have gotten lazy and I don't do that any longer.  I should probably build a tool to figure it out for me and then let me decide if I want to make changes to expand the down-level compatibility of whatever I produce for widespread usage. It is probably a hack off of JavaDoc.

2.	My nightmare

What has me wake up in the middle of the night is any situation that I have stepped over where (1) there is any change to the semantics of the same name between two versions of something or (2) there is vocabulary [local names] in one and not the other, and (3) I haven't provided for explicit differentiation so that (4) I can be specific in what interface contract I am depending on or providing, and (5) it is then clear what is a bug and what isn't.

3.	My sense of interoperability

3.1	I do not find it a nightmare to encounter a clearly-versioned use of XML that says namespace-version-2 is acceptable and name-space-version-1 is not.  I find that honest and clean.  It makes a clear declaration of where interoperability is not provided.  

3.2	I also see no problem in an XML application saying that namespace-version-2 is preferred and acceptable and that namespace-version-1 will be honored and responded to in complete compliance with the rules that apply to namespace-version-1.  That for me is the best of interoperability.  I could even foresee a specification (or an interoperability profile that applies to a specification) where acceptors of namespace-version-2 are required to accept namespace-version-1 and, in so doing, behave as if namespace-version-2 has never been heard of.  

3.3	Even better is that there is only namespace-version-1 and any client who uses namespace-version-1 will never be surprised by any response and any acceptor of namespace-version-1 will never be surprised by an unexpected legal use (as the result of some revision that has occurred).  That's a wonderful contract, as long as it can be maintained.  Clearly, if DAV accomplishes that, there is nothing I could possibly quarrel with.  

4.	Wrap-up

I find that the provision for namespace versioning, even if there is never more than one version, is a bit different than the care one takes to foster interoperability and then make clear and readily confirmable what the interoperability agreement is in actual situations.  Of course, namespace applies only to the XML part and not to DAV protocol in the context of HTTP, DAV methods and all the rest.

I suspect our nightmares overlap, but not completely. 

As I said, this is not a proposal.  And your feedback is really useful.  It is valuable to notice that we might have similar but not the same nightmares around breakdowns in interoperability.  I need to document the guidelines that I intend to follow in work that I do, and what I think that provides.

-- Dennis

-----Original Message-----
From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Geoffrey M Clemm
Sent: Sunday, October 12, 2003 06:30
To: w3c-dist-auth@w3.org
Subject: Re: Versioning Namespaces



By "breaking all existing code", I believe Julian was referring 
to the result that no client that only understands V1 
of the namespace can work against a server 
that only understands V2 of the namespace, and vica versa. 

This means that each time you rev the namespace, you introduce 
an interoperability nightmare for both clients and servers, 
because inevitably, new clients and servers will be written that 
only understand the "current" version of the namespace, which 
means that client and server implementors that care about interoperability 
will have to implement variant code for every new rev of the namespace. 

A significant percentage (possibly even a majority) of the hard 
design work of WebDAV and its extensions has been 
how to add in functionality in a way that is compatible with the 
previous standards.  So I agree with Julian that the DAV namespace 
should never be "rev"ed, but rather every new WebDAV protocol has 
to figure out how to live within the single existing DAV namespace. 

Cheers, 
Geoff 

Dennis wrote on 10/12/2003 02:19:08 AM:

[ ... ]
> 
> Having said that, I am not wedded to the idea. I was just suggesting
> a way of speaking that would allow for specific-namespace versioning
> with minimal editorial impact in future revisions of the DAV 
> specification.  I assume that 2518bis is far enough along that one 
> would not want to mess with it.  In any case, it is an editorial 
> nuance, nothing substantive.
> 
> I do think of namespace versioning as a key provision for 
> preservation of interoperability over time, like versioning COM 
> interfaces (and their UUIDs), and never changing them.  Or providing
> for versioning in Java package names.  Or even like W3C 
> specification URLs where you can refer to a specific edition or 
> simply the current latest of the progression.
> 
> -- Dennis
> 
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]

> > From: Of Dennis E. Hamilton
> > 1.1   I find it better to refer to the "DAV namespace" or "DAV
> > namespace URI" rather than the "DAV: namespace" especially
> > because namespaces are often versioned (rather than revised [;<),
> > so the identification in XML will be with different URIs over
> > time.  Ditto for the lock-token namespace.
> > ..
> 
> Well. There are no plans to change the namespace URI for DAV:. Doing that
> would be an incompatible change breaking all existing code (see for instance
> how XSLT deals with versioning).
> 
> [ ... ]
> 
>

Received on Sunday, 12 October 2003 16:12:20 UTC