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

The problem with the version selector is that it is a chameleon; its
behavior and semantics change dramatically during a
checkout--modify-in-place--checkin cycle.  Finding a single name that
conveys all that may be difficult.

No matter what it's called, I believe a better definition for version
selector (or version-controlled-resource) is needed beyond the current
operational description in the Terms section of the specification.  It
should include the motivation for the concept, which has been requested
several times on this list.

The part in the current definition about putting an existing resource under
version control is defined rigorously in the section on VERSION-CONTROL, so
it seems like it should be removed from the definition of version selector.
From a recent discussion with Geoff Clemm and my own reading of the
specification, I would define version selector this way, which may still be
too operational:

"Version selector:  The concept of the version selector 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.  It
is a resource that represents any of the saved states of a resource under
version control.  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, or, when the version selector is checked out, to the
content and dead properties of a version-to-be in progress.  On servers that
support the CHECKOUT method on version selectors, after a version selector
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
selector is bound to the new version."

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

Received on Monday, 4 December 2000 18:29:47 UTC