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

Re: Basic resource lifecycle: a new proposal for handling "mutable versions"

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Sun, 7 Jan 2001 09:16:58 -0500 (EST)
Message-Id: <200101071416.JAA03048@tantalum.atria.com>
To: ietf-dav-versioning@w3.org

Edgar's proposal is basically to keep the current "mutable version"
semantics, but to require that once "ismutable" is set to "true",
it cannot be set back to "false".

This is certainly sensible, but unfortunately does not address the
key problem with the "mutable version" semantics.  In particular,
since a server can just refuse to let you set the ismutable flag to
true, it means that a client cannot count on a server providing
stable URL's (and so any client that does need stable URL's will not
interoperate with such a server).

It's also important to point out that those who are in favor of
mutable versions want to have "human meaningful" URL's for those
mutable versions.  I believe that any sensible server will refuse
to let you set the "immutable" flag on any version with a human
meaningful name, since over time, this would result in the limited
number of human meaningful names being "used up" by immutable
version URL's.

So it is unlikely that anybody was ever going to support the
"ismutable" transition from "false" to "true" anyway.

The key point here is that a "stable name" is incompatible with a
"human meaningful name", so any attempt to unify "resources with
stable names" and "resources with human meaningful names" will
never succeed.

The point of the "variant" proposal is to say that we already
have defined resources that have "human meaningful names" and
are "mutable" ... they are version-controlled resources.

If you want to have a resource that is mutable and has a human
meaningful name assigned by the server, then all we
need is to provide a way for the server to expose a set of
version-controlled resources with server-defined names.

And that is what a "variant" is.  I'll post a version of the
protocol with the "variant option" defined, to make the proposal
more concrete.


   From: Edgar@EdgarSchwarz.de

   Why not define a version resource as having a state:

   State           = "working" | "approved" # The names aren't that important.
   The lifecyle has two states: "working" -> "approved"

   For documents we can set state to "working". As long as the author
   thinks he could still change something he can leave it in this
   state. And anybody is warned by the state that it can still change.
Received on Sunday, 7 January 2001 09:17:46 UTC

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