Discussion Topic: Simple Version Selection and Checkout

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Wed, 27 Jan 1999 23:21:01 -0500 

Date: Wed, 27 Jan 1999 23:21:01 -0500
Message-Id: <9901280421.AA21706@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: ietf-dav-versioning@w3.org
Subject: Discussion Topic: Simple Version Selection and Checkout


If you are a "document management system" vendor or user,
your participation in this discussion would be especially appreciated.

Jim Amsden and I worked today on resolving the differences between the
versioning models that he and I have proposed.  We were able to work
through most of the issues in the full "configuration management"
versioning models, but we got stuck on one key aspect of the simpler
"document management" subset of the versioning model.

In particular, Jim proposed a model that was more consistent with the
configuration management model, while I proposed a model that I felt
was closer to current document management systems.  Since Jim's
proposal produces a simpler and more consistent protocol, I'd prefer
to use his model, but I need to confirm that it is one that is
acceptable to document management system vendors and users.

The key questions are:
- How does a user request that a specific revision of a versioned-resource
  appear at a specific URL?
- What revisions can be "checked-out" for modification?

The answers in our configuration management versioning model are simple:
- The user can associate versioned-resources with URL's in a "workspace",
  and then specifies a "revision-selection-rule" for that workspace
  (i.e. pick all revisions labeled "LATEST")
- The user can check-out any revision that appears in a workspace.

Jim's proposal is that we answer these questions the same way in the
document management versioning model.

This has three key effects on the document-management versioning model:

(1) The concept of a "workspace" is introduced at the document-management
versioning level.

(2) The version-selection rule is a property of the workspace, so if that
rule says to do something special for URL-1 (e.g. "for URL-1, pick the
revision with id R1.3.5"), and you MOVE URL-1 to URL-2, you need to
update the version-selection-rule to do this special thing to URL-2
instead of URL-1.  In configuration management, this is not a problem
because version selection is almost always done with a floating label
or "branch/LATEST", rather than a bunch of special cases for individual
resources.  Is it a problem for document-management?

(3) Although you can access an arbitrary revision (since every revision
has a URL), only a revision exposed in a workspace can be modified.
This seems like a pretty reasonable constraint to me, but I wanted to
make sure that wasn't just my configuration management background
coming through.

If these effects are acceptable, then I'm totally in favor of Jim's
proposal in this area.  So document mangement folks, what say you?
Yea or Nay?

Cheers,
Geoff