RE: Auto-version corrections

Geoff,
Great descriptions. Hopefully this will remove the confusion, although I 
did have to read the third bullet item a number of times to get the 
difference. Some suggestions:

Put the value of DAV:auto-version in parens at the beginning of each 
paragraph to tie the pieces together.

Consider removing item 3. It seems gratuitous. If you have a locking 
client, it can either do the lock or not depending on what it wants to 
accomplish. Most clients that manage their own private workspaces will 
just want to do a single PUT when synchronizing their client workspace 
with the server, and won't need lock. Clients that don't manage their own 
private workspaces can use LOCK to have the server manage the temporary 
space. If you don't have a locking client, then the request should either 
fail or create the new version (auto-version on or off).

You could also consider removing the first item. A core versioning server 
that supports the checkout option should still support locking semantics. 
They're just different ways to do the same thing supporting different 
clients. Adding the checkout option shouldn't remove locking capability. 
And having an option to distinguish the two doesn't seem necessary as long 
as locking semantics are defined in terms of checkout/checkin.

Doing these two things makes DAV:auto-version a Boolean again.





"Clemm, Geoff" <gclemm@rational.com>
Sent by: ietf-dav-versioning-request@w3.org
02/13/2001 06:34 PM

 
        To:     ietf-dav-versioning@w3.org
        cc: 
        Subject:        RE: Auto-version corrections

 

Here's some revised wording for Section 3.1.2.
Let me know if you think this is clearer.

Cheers,
Geoff

3.1.2            Modifying a Version-Controlled Resource

In order to use methods like PUT and PROPPATCH to directly modify the
content or dead properties of a version-controlled resource, the
version-controlled resource must first be checked out.  When the 
checked-out
resource is checked in, a new version is created in the version history of
that version-controlled resource.  The version that was checked out is
remembered as the predecessor of the new version.
 
The DAV:auto-version property (see Section 3.3.2) of a checked-in
version-controlled resource determines how it responds to a method that
attempts to modify its content or dead properties.  The four possible
responses are:

- Fail the request.  The resource requires an explicit CHECKOUT request 
for
it to be modified (see Sections 5).

- Fail the request unless the resource is write-locked.  If it is
write-locked, automatically checkout the resource and perform the
modification.  The resource remains checked-out until the write-lock is
removed (either explicitly through a subsequent UNLOCK request or 
implicitly
through a time-out of the write-lock).  This avoids the proliferation of
versions that can result if every modification creates a new version.

- Automatically checkout the resource, perform the modification, and then 
if
the resource is not write-locked, automatically checkin the resource.  If
the resource is write-locked, it remains checked-out until the write-lock 
is
removed.  This helps a locking client avoid the proliferation of versions,
while still allowing a non-locking client to update the resource.

- Automatically checkout the resource, perform the modification, and
automatically checkin the resource.  This ensures that every state of the
resource is tracked by the server, but can result in an excessive number 
of
versions being created.

...