W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2001

Mutable Versions (was: re-use of version URL's)

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Fri, 5 Jan 2001 11:52:49 -0500 (EST)
Message-Id: <200101051652.LAA29862@tantalum.atria.com>
To: ietf-dav-versioning@w3.org

   From: Greg Stein <gstein@lyra.org>

   As Geoff stated: you can use version-controlled resources, labels, or
   baseline selectors to create human-readable URLs.

   The version resource URL is (IMO) typically private and does not need to be
   readable. Primarily, the URL needs to be *stable* and *persistent*.

This thread brings to mind a related topic, which has an even more
negative impact on interoperability then weakening the MUST to a
SHOULD, namely "mutable versions".  A mutable version is actually even
worse than a server re-using a version URL, because it provides a way
for a *client* to break versioning semantics.

But I believe the thread on "re-use of version URL's" points out
an interoperable solution to the "mutable version" issue.  In particular,
clients that want mutable versions want to use the same "name" to apply
to one state at one time, and another state at another time.  But
we already have a mechanism for doing this in the protocol, namely
labels.  In particular, if a mutable versioning client uses *labels*
to identify versions of interest, then we get interoperability.
When a mutable versioning client wants to "change" the state of a
version, they just create a new version and apply that label to it,
and that *label* then acts as a "mutable version identifier".

The only thing we are currently missing to make this work, is to provide
a way for a mutable versioning client to tell a mutable versioning
server that it wants to create a new version as a replacement of
an existing version.  But all we need for this is a "label" parameter
to the checkin command, which tells the server which labeled version
this is supposed to "replace" (effectively combining a "checkin"
with a "move label" operation).

So I propose that we replace the current "mutable version" option
with the ability to specify a label in a CHECKIN request.  This gives
us one fewer option as well as significantly improved interoperability,
while still providing the semantics required by a "mutable versioning"
client and server.

Any objections?

Received on Friday, 5 January 2001 11:53:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:46 UTC