RE: Allowing non-default options for auto-checkout and -checkin

   From: Roy Seto [mailto:Roy.Seto@oracle.com]

   I'm following up on this discussion from 

 
http://lists.w3.org/Archives/Public/ietf-dav-versioning/2001OctDec/0021.html

   in a separate thread. Would it be appropriate to consider part of
   these changes in the editorial pass for the initial RFC?

I believe that this functionality can be achieved in a way that is
compatible with the current draft, i.e. no changes to the current
draft are needed for servers to support this extension.  (Note: I 
would not want to actually make the extension in the editorial pass).

      - Autoversioning (extension), baseline feature (use case): In
 Section 3.2.2, change the EMPTY elements in the
 DAV:auto-version property values to ANY, enabling DAV:checkin
 and DAV:checkout elements with default checkin and checkout
 options for the autoversioned VCR to be applied at
 auto-checkin and auto-checkout time. Use case: multiple
 workspaces share the same DAV:current-activity-set and the
 same DAV:checked-in baselines for their version-controlled
 configurations, and those VCCs' DAV:auto-version properties
 are DAV:checkout. There is a problem because
 baseline-controlled members of those workspaces cannot be
 checked in even if they are for different version histories -
 only the first workspace can auto-checkout its VCC unreserved
 in the shared DAV:current-activity-set.

I agree that this is a reasonable use case.

   Continuing this discussion, is there a possibility that some of the
   following changes might be made in the first RFC?

      - In Section 3.2.2, change the EMPTY elements in the
 DAV:auto-version property values to ANY to enable better
 extensibility of those property values.

 (The extension I have in mind is to include a
 DAV:checkout or DAV:checkin element within the
 DAV:auto-version property value to allow options
 to be specified in auto-checkout and auto-checkin
 operations.)

I wouldn't want to embed it in the DAV:auto-version property values,
since that would make it hard for the client to discover whether
this extension is supported.

     or, 

      - Around Section 3.2.2, define additional property names to hold
 options for auto-checkout and auto-checkin operations.

That is how I'd want to define the extensions, but is more than I'd
want to do in an editorial pass.  Let's define those new properties in
draft form, and add it to the "proposed extensions" list.  (we already
have one such proposed extension on the web site, the "checkin URI"
extension).

Cheers,
Geoff

Received on Sunday, 7 October 2001 19:10:08 UTC