W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2000

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

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Mon, 4 Dec 2000 23:25:32 -0500 (EST)
Message-Id: <200012050425.XAA12219@tantalum.atria.com>
To: ietf-dav-versioning@w3.org

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.

Received on Monday, 4 December 2000 23:26:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:46 UTC