RE: Baby steps

Extracted from below, Jim wrote:
  >At present, the consensus of the group, reflected in section 5.9.1 of RFC
  >2291, "Requirements for a Distributed Authoring and Versioning Protocol for
  >the World Wide Web", is that versions, once they are frozen, are immutable.
  >Most working group members I have talked to have been associating "freeze"
  >semantics with the "checkin" method.
  >
  >Based on this, the current versioning proposal would not let you modify an
  >existing member of a version graph (that is, modify the contents available
  >at a given URL), since  the members of the version graph are frozen.  The
  >current versioning proposal does force a new version on each change.
  >
  >In previous discussions on this topic, it seemed to me we had determined
  >that the WebDAV LOCK functionality exactly matches the functionality that
  >Novell terms checkout.
  >
  >Also, I know many people on the list view immutability of previous versions
  >as an essential guarantee provided by a versioning system, and lack of such
  >guarantee as a serious diminishment of the value of a versioning system.  It
  >would be helpful to me (and to the list as well), if you could give some
  >scenarios of use where previous versions need to be modified (i.e., where
  >immutability isn't desired), so we can understand why you feel this is a
  >critical feature.

There are two scenarios.  First, which I believe is VERY common, is to allow me to edit a leaf node and have the changes go back into that same version.  In our experience with versioning (8+ years), most of our users have responded that they do NOT want a new version being forced every time they save their document back into the library.  Think of it in terms of the WebDAV proposal document.  You may work on the document every day for four weeks before you have it to a point where you feel it should be posted again.  That would be a single version, even though you worked on it every day (and presumably didn't keep it checked out since others also needed to do some work in it).  Once you've posted it, you create a new version and all work goes into that version until the next posting.  Of course you might choose to create new versions between postings, generally to preserve the document in a certain mid-point stage.

The second scenario is to allow me to edit a non-leaf node and save those changes back into that node.  While the need/request for this is considerably less, not everyone uses versioning the way we think of it.  For instance, some users use versions in the way that WebDAV would implement variants: they store each language version as its own version.  (This makes perfect sense, they say  ;-)   This scenario might also be when a company produces their employee handbook and have a version for each year's updated handbook.  Right now I would have versions for all previous years, 1998, and the new one for the upcoming year 1999.  If a mistake is found in our 1998 handbook, I would like to fix it in-place.

Novell's model (and I'm sure we aren't the only ones who don't force a new version with every edit) would be broken by WebDAV *requiring* this.  I believe WebDAV needs to be kept flexible.  Let the server, not the spec, determine if automatic versioning is enforced or not.

>>> Jim Whitehead <ejw@ics.uci.edu> 08/06 11:00 AM >>>
Comments below.

> -----Original Message-----
> From: Bruce Cragun [mailto:BCragun.ORM2-1.OREM2@gw.novell.com] 
> Sent: Thursday, August 06, 1998 7:21 AM
> To: ejw@ics.uci.edu; Sam Ruby; WEBDAV WG
> Subject: RE: Baby steps
>
>
> This explanation of VPortals helped me a lot in understanding their
> purpose.  But it returns me to a question I asked in Redmond: What is
> the method for getting an earlier (i.e. not the tip) version of a
> document?

There are a couple of retrieval cases here:

1) Retrieving a version of a resource where the version identifier and
Vportal URL are known (but the exact URL of the version of the resource is
unknown)
2) Retrieving a version of a resource where the Vportal URL is known, but
the version identifier and exact URL of the version of the resource are not
known (i.e., perhaps you want the most recent version before a given date)
3) (for completeness) Retrieving a version of a resource where the exact URL
of the resource is known.

For case 1, ideally it should be possible to use GET, with the version
identifier specified in a header, on the Vportal URL.  The response will an
entity representing the requested resource.

Returning to the example from my previous post, if "x.c" is the Vportal, and
version 4 of x.c is requested, then a GET request could be made to x.c, with
the version identifier "4" specified in a header.  The response from the GET
will be an entity representing the resource which is version 4 of x.c.

For case 2, the version can be retrieved by first requesting a listing of
the version graph. The version graph is then examined to determine the
version identifier of the desired version.  A GET request is then made to
the exact URL of the desired version.

So, in the "x.c" example, the client would first request the version graph
(using GRAPHGET), receiving a list of all the resources in the version
graph, their is-derived-from relationships, and their version identifiers.
The client examines the version graph for the URL of the desired version,
performing a GET operation to retrieve the desired version.

Case 3 is trivial -- just perform a GET on the URL of the desired version.

For cases 1 and 3, the version is retrievable with a single network round
trip.

All retrieval cases work for non-tip resources (as well as for tip
resources).

> And does WebDAV truly support not only getting a non-tip
> version but also the ability to return that version, with changes, to
> the same location? Stated another way, can I edit a non-tip version
> and return it to the collection as that same version, or does WebDAV
> force a new version for any change?

At present, the consensus of the group, reflected in section 5.9.1 of RFC
2291, "Requirements for a Distributed Authoring and Versioning Protocol for
the World Wide Web", is that versions, once they are frozen, are immutable.
Most working group members I have talked to have been associating "freeze"
semantics with the "checkin" method.

Based on this, the current versioning proposal would not let you modify an
existing member of a version graph (that is, modify the contents available
at a given URL), since  the members of the version graph are frozen.  The
current versioning proposal does force a new version on each change.

> This issue is critical to us at Novell, so I just want to make sure
> nobody believes we have placed such limitations into this spec.

In previous discussions on this topic, it seemed to me we had determined
that the WebDAV LOCK functionality exactly matches the functionality that
Novell terms checkout.

Also, I know many people on the list view immutability of previous versions
as an essential guarantee provided by a versioning system, and lack of such
guarantee as a serious diminishment of the value of a versioning system.  It
would be helpful to me (and to the list as well), if you could give some
scenarios of use where previous versions need to be modified (i.e., where
immutability isn't desired), so we can understand why you feel this is a
critical feature.

- Jim

Received on Friday, 7 August 1998 12:11:23 UTC