RE: Versioning Namespaces

Just a couple of things on the practical use of namespace versioning.  

I just want to sharpen some cases as long as we are discussing this.  I don't have any basis for suggesting that a particular one applies to DAV (or not).


1.	Although I have seen cases where there is an added namespace (for example, Dublin Core uses two), normally the idea is that the new namespace includes everything needed.  Sometimes namespaces are partitioned/subsetted for convenience or logical appropriateness, but that is another matter (RDF uses two in that way (usually prefixed rdf: and rdfs:), and so does XML Schema (usually prefixed xs: and xsi:).

2.	If there is legacy interoperability, which is generally a strong requirement as well as practical reality, then the usual idea would be that uses of the original namespace would continue to do so, and the new namespace would be used only where features of that namespace, not available with the earlier namespace, are required.
	There is the matter of people specifying the newer namespace out of convenience or carelessness, and this causing processors that only support the original namespace to reject the material.  It is like updating your Microsoft Office Suite and not doing Save As ... to the oldest compatible version.  On the other hand, the Microsoft Office application actually has all of the information necessary to correctly do a Save As ... to the oldest compatible version. And a Java processor could have all of the information necessary to correctly specify the oldest versions of JDK that a compiled class is definitely compatible with [;<).
	Note that changing the namespace without versioning the name does not make this particular problem go away, it just changes the way the problem shows up.  Versioning the namespace has it show up sharply and up front, and that may or may not serve the requirements of a particular application setting. I find that it has a strong accountability quality that I prefer, as I mentioned in the exchange of nightmares with Geoff.  But, you know,  your nightmare may vary.

3.	For changes such that the new namespace does not recognize the old as a subset, there are more problems, obviously.  That is the case for SOAP, where, like it or not, SOAP 1.1 is in serious de facto use (and is the level used in the WS-I Base Profile 1.0a for interoperable use in web services).  The SOAP 1.2 namespace does not include the SOAP 1.1 nomenclature and elements as a proper subset.  There are substantial and important differences.  And SOAP 1.2 accounts for what the SOAP 1.1 behavior will be on receiving a SOAP 1.2 request. It also specifies how SOAP 1.2 processors can properly accept SOAP 1.1 and also how to properly reject SOAP 1.1 by using responses that a SOAP 1.1 requester will interpret correctly.

I have my own druthers among that set.  If the namespace can be held fixed and not changed as Web DAV is revised, that certainly preserves maximum interoperability with ones own legacy.  I'm for it.

I am grateful for this discussion.  There is a lot here that I am going to pay attention to as I look at applying the XML technology set in other situations, and in writing about it and encouraging best practices.  This has been useful to me whether or not it is particularly apt in the context of DAV.

Thank you,

-- Dennis

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Sunday, October 12, 2003 13:30
To: dennis.hamilton@acm.org; Julian Reschke; w3c-dist-auth@w3.org
Subject: RE: Versioning Namespaces


> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dennis E. Hamilton
> Sent: Sunday, October 12, 2003 8:19 AM
> To: Julian Reschke; w3c-dist-auth@w3.org
> Subject: Versioning Namespaces
>
>
>
> Gee, Namespaces are versioned all of the time without breaking
> any existing code.  I didn't mean to suggest obsolescing

I think that depends on what you understand with "breaking". If the DAV:
namespace URI gets versioned that is *changed*, no existing code will be
able to process messages using the new namespace, even if the local names
match and do have the same semantics.

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

That would mean that new elements are put into a new namespace, or existing
elements are getting changed and now use a new namespace. That's possible,
but it doesn't (IMHO) really means that the namespace is versioned -- you
are just adding a second namespace for new elements, and the old one isn't
changed at all. That would be a compatible change, however it would mean
that when creating messages, you always have to worry about picking the
right namespace URI. One of the reasons why XSLT2 elements use the existing
XSLT namespace URI.

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

I don't know a lot about SOAP, but SOAP 1.2 is the first revision of the
spec issued by a (sort-of) standards body, so it makes perfect sense to
restart and not to worry too much about legacy.

> 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

Funny that you mention that, because I came across this issue just a few
weeks ago (the SAP EP portal will support extraction of RFC2731-formatted
custom metadata from remote HTML pages, for instance as support for
crawlers).

>From a WebDAV point of view, DC properties with the same local name differ
when they use different namespace URIs. It seems that DC people have found
this to be a problem as well. Looking at
<http://dublincore.org/documents/2001/10/26/dcmi-namespace/>, they seem to
recommend to use unique (and hopefully) stable namespace URIs for their
elements.

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

Doing versioning right is *hard*. I think a few months ago it was suggested
that the W3C TAG would pick up the topic, and they rejected that :-)

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Monday, 13 October 2003 15:15:13 UTC