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 Sunday, 12 October 2003 16:30:49 UTC