Variant Control: a new proposal for handling "mutable versions"

OK, I think I've grok'ed what Lisa and Mark want here.
Let me know what you think ...

-------------------

First, let's rename "mutable versions".  In particular, let's call
them "variants".  A reason for the rename is that a variant is *not* a
special kind of version resource, but rather is a special kind of
version-controlled resource.

A version-controlled resource gets variants by putting it under
"variant-control" (with a VARIANT-CONTROL request).  When a
version-controlled resource is under variant control, each time you
checkin that version-controlled resource, you create a new "variant".
A variant of a given version-controlled resource is another
version-controlled resource (with a URL selected by the server) whose
DAV:checked-in property always identifies some version of the given
version-controlled resource.  The variants of a version-controlled
resource can be determined by looking at the DAV:variant-set property
of the version-controlled resource.

One interesting characteristic of a version-controlled resource under
variant control is that a server MAY automatically delete any version
of that version-controlled resource that is not currently
identified by the DAV:checked-in or DAV:checked-out property of a
variant of that variant-controlled resource.

-------------------

OK, that's it.  I believe this gives us all what we want.
I believe the "variant URL" has all the properties that Lisa and Mark
have requested (allocated by the server, but can identify different
resources at different times), while still providing a DAV:checked-in
property for clients that want to have a stable URL for a particular
state of that variant.

Comments?

Cheers,
Geoff

Received on Saturday, 6 January 2001 09:33:23 UTC