Next message: Geoffrey M. Clemm: "Re: protocol-04.8 issues"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256907.006437C1.00@d54mta02.raleigh.ibm.com>
Date: Fri, 23 Jun 2000 14:14:38 -0400
Subject: Re: Versioning TeleConf Agenda, 6/5/00 (Monday) 2pm-3pm EST
The proposal below promotes the use of the history URL to get the
versioning history of a versioned resource which is usually referenced
using a versioned resource URL, the one the user knows, is familiar with,
and would recognize on a printed piece of paper he encounters at some later
time. Why not stick with the "Target-Selector: versioned-resource" to
access the meta-data, and minimize the use of the history URL? Versioning
unaware clients are going to have to deal with a lot more confusion than
this when navigating the versioning space.
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
Minutes:
...
- Should checkout/checkin in a workspace be modeled as
a state change of a versioned resource, or as the
replacement of a versioned resource with a working resource
followed by the replacement of a working resource with
a versioned resource.
Note: Other than myself, the attendees of the conference call were
unanimous in their opposition to this proposed change (i.e. they
wanted checkout to create a working resource, and checkin to create a
new revision and delete the working resource, and not have
checkout/checkin be just a state change of the versioned resource).
Rather than pursue this change, I've decided to take the path of
less resistance, and withdraw my proposal that we change the protocol
in this fashion. This allows us to basically leave core versioning
alone (beyond the fixes identified in the Seattle minutes), and
focus on finishing up advanced versioning.
There is one (minor) terminological anomaly that I think it is
important that we fix in core versioning. Currently, we have four
kinds of URL's:
- versioned resource URL (has default target that is a revision)
- working resource URL (mutable result of checking out a versioned
resource)
- revision URL (immutable result of checking in a working resource)
- history URL (provides access to versioned resource metadata)
Currently, if you do a PROPFIND on a versioned resource URL, the
DAV:resourcetype is *never* DAV:versioned-resource, while if you do a
PROPFIND on a history URL, the DAV:resourcetype is *always*
DAV:versioned-resource.
I propose that we change the name of this resource type to be
DAV:history. Then if you do a PROPFIND on a history URL, the
DAV:resourcetype will be DAV:history. This makes it clear that
this resource is displaying the history of the versioned resource,
and not the default target of the versioned resource.
Note that this involves *no* change to the protocol, beyond
renaming this one string.
Although not a big deal for core versioning, this is very important
for preventing confusion in advanced versioning, where you can either
have two bindings in the same workspace to the same versioned resource
(all of which then have the same default target), or you can have
two versioned resources in different workspaces with different default
targets, but which are associated with the same "history" resource.
Cheers,
Geoff