RE: version-selector => version-controlled-resource

Here's another cut at a definition of version-controlled resource, taking
into account Geoff's comments, and trying to pare it down to the essential
elements:

"Version-controlled resource:  The concept of the version-controlled
resource is to allow a single URL to track a resource through the
checkout-modify-checkin cycle from one version to the next.  It is a
resource with a unique URL distinct from the URLs of both its associated
version history and any of the versions in that version history.  At any
given instant when it is in a checked-in state, it has a copy of the content
and dead properties of one version from its associated version history.
Immediately after it is checked out, it has a writable working copy of the
content and dead properties of the version targeted when it was checked out.
This working copy can be modified 'in-place' with methods like PUT and
PROPPATCH, without affecting the selected version that was checked out.  A
checkin changes the state of the version-controlled resource back to
'checked-in', and creates a new version in its associated version history
whose content and dead properties are a copy of that of the
version-controlled resource at the time of checkin."

Incidentally, I find "version-controlled resource" to be a bit of a mouthful
also (:-).  I think something like "version handle" would be better, since
it's designed to be the handle by which a version is taken through the
checkout-modify-checkin cycle.  It shifts from object to object in the
process, just as a handle might in a program.  For your consideration,
here's the same definition with "version handle" instead of VCR:

"Version handle:  The concept of the version handle is to allow a single URL
to track a resource through the checkout-modify-checkin cycle from one
version to the next.  It is a resource with a unique URL distinct from the
URLs of both its associated version history and any of the versions in that
version history.  At any given instant when it is in a checked-in state, it
has a copy of the content and dead properties of one version from its
associated version history.  Immediately after it is checked out, it has a
writable working copy of the content and dead properties of the version
targeted when it was checked out.  This working copy can be modified
'in-place' with methods like PUT and PROPPATCH, without affecting the
selected version that was checked out.  A checkin changes the state of the
version handle back to 'checked-in', and creates a new version in its
associated version history whose content and dead properties are a copy of
that of the version handle at the time of checkin."

--Chuck Fay 
FileNET Corporation, 3565 Harbor Blvd., Costa Mesa, CA 92626 
phone:  (714) 327-3513, fax:  (714) 327-5076, email:  cfay@filenet.com

> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com]
> Sent: Monday, December 04, 2000 8:26 PM
> To: ietf-dav-versioning@w3.org
> Subject: Re: version-selector => version-controlled-resource
> 
> 
> 
> Just a couple of comments (and a change to "version-controlled
> resource" :-)
> 
>    From: "Fay, Chuck" <CFay@filenet.com>
> 
>    "Version-controlled resource: The concept of the version-controlled
>    resource is to allow a single URL to track a resource through the
>    checkout-modify-checkin cycle from one version to the next.  It has
>    a unique URL distinct from the URLs of both its associated version
>    history and the version which is its current target.
> 
> Note that a version-controlled resource does not have a current target
> when it is checked-out.
> 
>    It is a
>    resource that represents any of the saved states of a resource
>    under version control.
> 
> This is a correct statement, but I'd be a little concerned that folks
> might confuse "saved state" with "version".
> 
>    It is logically bound at any given instant
>    to a copy of the content and dead properties of one version in the
>    version history from which it selects,
> 
> I'd probably avoid the term "bound" since it is not a binding in
> the way we are using the term in the Binding protocol.  Probably
> I'd just say "when it is checked-in, it's content and dead properties
> are a copy of those of a version in its version history".
> 
>    or, when the
>    version-controlled resource is checked out, to the content and dead
>    properties of a version-to-be in progress.
> 
> I know what you mean, but "version-to-be in progress" is quite
> a mouthful (:-).
> 
>    On servers that support
>    the CHECKOUT method on version-controlled resources, after a
>    version-controlled resource has been checked out, the copy becomes
>    a writable working copy and can be modified 'in-place' with methods
>    like PUT and PROPPATCH, without affecting the selected version that
>    was checked out.  On checkin, this working copy is captured as a
>    new version in the associated version history, and the version-
>    controlled resource is bound to the new version."
> 
> I definitely don't want to say that it "is bound to the new version".
> It continues to be a completely separate resource (with its own live
> properties), even when it is checked in.  A checkin just changes the
> state of the version-controlled resource (to be "checked-in"), and
> creates a new version whose content and dead properties are a copy
> of that of the version-controlled resource.
> 
> Cheers,
> Geoff
> 
> 
>

Received on Tuesday, 5 December 2000 15:56:27 UTC