Re: CHECKIN/CHECKOUT - Mutable resources and a call for consensus

David G. Durand (
Wed, 20 Jan 1999 10:07:22 -0500

Message-Id: <v04011702b2cb9e711754@[]>
In-Reply-To: <3FF8121C9B6DD111812100805F31FC0D08792D50@RED-MSG-59>
Date: Wed, 20 Jan 1999 10:07:22 -0500
To: Yaron Goland <>,
        "'Geoffrey M. Clemm'" <>,
From: "David G. Durand" <>
Subject: RE: CHECKIN/CHECKOUT - Mutable resources and a call for consensus

At 11:58 PM -0500 1/19/99, Yaron Goland wrote:
>This is the second part of my comments on Geoffrey's spec.
>> Mutable-Revisions
>> A mutable-revision is a revision whose contents and properties can be
>> changed, although an attempt to change the contents or the "immutable
>> properties" of a mutable-revision must be preceded by an explicit
>> "checkout/thaw" operation, and then should be followed by a
>> "checkin/freeze" operation to return it to a read-only state.  This
>> then requires two flavors of checkout: a checkout that unfreezes an
>> existing mutable-revision (which I'll call CHECKOUT) and a checkout
>> that creates a new (unfrozen) mutable-revision that is based on an
>> existing mutable-revision (which I'll call CHECKOUT-NEW).
>This paragraph leads me to two questions:
>		1) Should mutable resource management be in-scope for

At the last meeting, (and the previous one) it became clear that this is a
real requirement for the class of what you might call "office document
management systems".

So, in a word, "yes."

>		2) Are the mutable resource and versioning models similar
>enough to justify worrying about their interoperability?
>I do not believe that WG consensus exists on the answer to question 1. There
>was discussion on the issue amongst the original WebDAV authors but no
>conclusion was ever reached as versioning work was shut down in favor of
>solidifying the rest of the spec. Consequently the issue was never presented
>to the WG for discussion and consensus.

This is the versioning authoring team. We reach consensus among ourselves,
and the WG gets their licks in. I think the case is very strong, and the
whole point of this group is to get a subset of the "experts" to make
preliminary decisions to focus the WG discussion.

>As for question 2, I would be very interested in hearing the reasoning
>behind the versioning authors' opinions on these matters. A presentation of
>the versioning model and a separate presentation on the mutable resource
>management model with a compare/contrast between the two would probably go a
>long way to clarifying the issues.

sure, these are all in-progress work items of this group. Some of the
drafts are already available. Of course, like many working documents, much
is left unsaid because the group agrees on it, and some things will need to
be made more explicit.

>A versioning client may be willing to use core WebDAV methods such as
>PROPFIND/PROPPATCH and GET against a mutable resource server. But such a
>client could not, for example, pull down the history of a mutable resource
>since the client's fundamental assumption is that while a history can be
>expanded its existing relationships can not be changed. Additionally, such a
>versioning client would most likely not want to execute check-in/out against
>a mutable resource server given that the result is not a versioned resource.
>Thus a versioning client can not fully interoperate with a mutable resource

In Geoffrey's proposal, both kinds of client make their requests at the
same point in the protocol. Of course a versioning client will have a
trouble because there is no revision graph, nor any support for
configuration management, but the same protocol elements will be used by
the client to perform that same basic operations. Of course a great deal of
functionality will be unavailable.

We are also anticipating a two-tier set of versioning functions: "mutable
resource" or "document management" level, and configuration level.
Configuration level functions only work when the full set of immutable
revision operation semantics are available. So a level II client talking to
a level I server must only use that subset of the operations that the
server supports.

I like Geoffrey's proposal a lot, because the level I protocol looks
exactly the same as the level II protocol, but with fewer methods, and
weaker semantic guarantees.

Interoperable doesn't mean interchangeable -- there's a reason that you
might want the level II features, but it's eased if level II _only adds_

   -- David

>A mutable resource client is likely to be more flexible in dealing with a
>versioning server. It certainly can use the core WebDAV commands and will
>have no problem pulling down a history. It will run into trouble, however,
>when it tries to use check-in/out since the user is expecting that they can
>change resources. Still, one can see mutable clients working around this
>problem fairly easily since it is a similar problem to access control. Thus
>a mutable client can interoperate, almost fully, with a versioning server.

The mutable client works perfectly, since what it thinks of as a "version"
the server thinks of as a "branch" -- a named chain of immutable revisions,
with default access to the most recent. The client never issues the
advanced messages that would inform it of the extra revisions that it
doesn't know about, though, given the right URI, it could actually access
those revisions...

>Thus it would seem that mutable clients should be able to interoperate with
>versioning servers but not the other way around. This argues for separating
>versioning design from Mutable design. This could mean breaking the speak
>into two parts or even just having two separate specs. [Insert standard
>disclaimers about not doing anything gratuitous in the versioning standard
>which make it impossible to layer the mutable standard on top.] [Insert
>standard disclaimers about not allowing the versioning standard to be
>unnecessarily complicated for the sole purpose of making the mutable
>standard designer's jobs easier.]

We can do better than that, by using subsetting, since the common semantics
are enough to make that possible.

  -- David
David Durand      \
Boston University Computer Science        \  Sr. Analyst   \  Dynamic Diagrams
MAPA: mapping for the WWW                    \__________________________