W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2001

checked-out VCC: A new proposal

From: Clemm, Geoff <gclemm@rational.com>
Date: Thu, 12 Apr 2001 10:57:41 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E2356@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org

At the very end of my last response to Tim on this topic,
I proposed an alternative approach instead of "always keep it checked-out".
Since this appeared at the end of a long message, I thought it would
be better to state the new proposal in a separate message (i.e. this one).

To summarize the issue: In order to allow a baseline-unaware
versioning client to interoperate with version-controlled resources
that are under baseline control, it is important to allow a client to
to check-out/check-in any version-controlled member of a
baseline-controlled collection.  My previous proposal to address this
is to require that a version-controlled configuration is always in the
checked-out state.  One can make a good argument for why there is
little/no value in having the version-controlled configuration ever be
in the checked-in state, but rather than make that argument, I believe
there is an alternative that provides a more regular model, and that will
be more palatable to those who have objected to the "it's always
checked-out" approach.

The new proposal is to add a new value for the DAV:auto-version
property, namely the "DAV:always-checkout" value.  When this value is
set for a checked-in version-controlled resource, that resource will
automatically be checked out whenever it is updated, but must be
explicitly checked in (with a subsequent CHECKIN request) to create
a new version (or in the case of a configuration, to create a new
baseline).

This addresses the baseline-unaware versioning client issue, because
a baselining server that wants to be friendly to such a client will
set the DAV:autoversion property of a version-controlled configuration
to be DAV:always-checkout.  Standard checked-out/checked-in semantics
will then apply to the version-controlled configuration.

Any objections?

Cheers,
Geoff
Received on Thursday, 12 April 2001 10:56:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:41 GMT