RE: Versioning Namespaces

Dennis wrote on 10/12/2003 04:12:15 PM:
> 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." 

Yes, there still is the problem of determining what functionality
within that namespace is supported by a given server.  That's what
the DAV header is all about.

> 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.

I don't think "revision" is the right way to model what happens to 
the DAV namespace.  In particular, revision commonly implies a 
set of alternatives, of which you can pick one.  The WebDAV
specs do not define a sequence of alternatives, but rather a set
of standard "features", any combination of which can be supported
by a WebDAV server(with some constraints, e.g. WebDAV level "2" support
requires WebDAV level "1" support).  The set of features supported
by a server is indicated in the DAV response header.
 
> 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.

This is a problem for Java classes because they do not have the
"supported feature" mechanism that is provided by the WebDAV DAV
header.  WebDAV clients understand that they must deal with servers
that support different combinations of WebDAV features.

One of the most difficult aspects of defining a WebDAV protocol
extension is to invent the minimal number of new features needed
for that extension (preferably just one, but for some sophisticated
extensions such as DeltaV, several are required).

> 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.

In WebDAV:

(1) is not allowed, except in extreme cases where the previous semantics
was so poorly defined that interoperability would improve by changing the
semantics to something closer to what was actually being implemented
(e.g. "lock-null resources" in 2518).

(2) is explicitly allowed, but must be accompanied by a new DAV feature
that allows a client to discover what vocabulary is supported by a given
server.

which addresses (3), (4), and (5).

> 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. 

The WebDAV approach of defining DAV features provides significantly
superior interoperability.  A client that requires features X, Y, and
Z just checks whether X, Y, Z are supported by a given server.
If they aren't, the client can fail, or can fall back to the subset
of features the server does support.
 
> 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. 

That is what the WebDAV DAV feature mechanism gives you.
 
> 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. 

It does, so we have no quarrels (about that, anyway, I'm sure that 
there are some other aspects of the WebDAV protocols that will warrant
a quarrel or two :-).

> 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.

The WebDAV feature mechanism deals with all of these issues, i.e. a
"feature" that appears in the DAV header defines a set of node types
in XML, a set of DAV methods, a set of headers, and a set of properties
(in the DAV: namespace).  And it works by requiring a DAV protocol 
extension
to respect (and re-use when appropriate) every DAV feature that has been
defined by a DAV protocol with an earlier IETF RFC number.  This makes
writing WebDAV protocol extensions an interesting challenge, but it sounds
like you appreciate why we would impose this requirement on ourselves.

Cheers,
Geoff