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 Monday, 4 December 2000 23:26:19 UTC