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:

> 
> Gee, Namespaces are versioned all of the time without breaking any 
> existing code.  I didn't mean to suggest obsolescing anything, only 
> that it is useful to speak in a way where a new URI might be usable 
> for a *later* namespace.  The existing namespace URI would still 
> work, and refer to the current namespace.  A future namespace might 
> have the current one as a proper subset and that would work too, 
> even though there is a different URI for it.
> 
> I realize that there are DAV headers for this, as part of feature 
> coordination and leveling, It is often handy to also rev the 
> namespace for anything specific to the use of XML.  For example, 
> with the SOAP XML binding to HTTP, a closer analog to WebDAV, I 
> would think, the SOAP 1.2 Recommendation establishes a different 
> namespace than is used for the SOAP 1.1 level, and the SOAP 1.2 
> specification deals with how to deal properly with SOAP 1.1 as a 
> legacy.  This supports the versioning of XML Schema definitions too,
> since XML Schema definitions tend to be targeted to specific namespaces.
> 
> So I wasn't anticipating any kind of versioning of namespace URIs 
> that would break compatibility with or even usage of the current 
> specification.  I see it as keeping a namespace stable and known, 
> whether or not it is a proper subset of a future one.
> 
> Namespace versions will already have to be dealt with when 
> properties, for example, are taken from other XML-mapped 
> vocabularies, such as Dublin Core, which has a specific namespace 
> for its current 1.1 level of element definitions.  Something like 
> that will doubtless happen with RDF, if it isn't underway already in
> Friday's Last-Call Working Draft documents.
> 
> 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).
> 
> [ ... ]
> 
>