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

RE: CHECKIN / CHECKOUT proposal from Geoff

From: Clemm, Geoff <gclemm@rational.com>
Date: Mon, 18 Jun 2001 11:16:34 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B10350AB15@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org

   From: John Hall [mailto:johnhall@evergo.net]

   My 'MAY' values are only trying to keep the client from getting into an
   impossible state.  Namely, no UPDATE/MERGE available but the CHECKIN
   'apply-to-version' isn't specified.

That is not an impossible state.  A server may wish to allow versions
to be created that will never be used to update the state of a VCR.
Or a server may have some other non-standard method of using a version
to update the state of a VCR.

   Now, I thought 'apply-to-version' was a flag on the working resource,
   but you are putting it in the CHECKIN body.  OK.

The DAV:apply-to-version flag is already defined in the protocol
(in the CHECKOUT body).

   So can you just let me fail the CHECKIN if 'apply-to-version' isn't
   specified and neither is UPDATE/MERGE?

A server is of course free to do so, but an interoperable client will
not expect that behavior.  An interoperable client will expect that
you do support UPDATE, since that is part of the client workspace 

   And another reason for 'MAY' is that different companies might wish to
   configure a given server in different ways.  Although my server will
   allow versions to be deleted, I'll also provide an admin flag
   (proprietary) to prohibit it.

Every MAY is an interoperability problem, only added as a last resort.
The "MAY" for version deletion represents an inherent tension between
the desire of a user to preserve history, and the desire of a user to
preserve space.  Any other "MAY" needs a correspondingly compelling


   CHECKOUT (of working copy) postcondition:
   <!ELEMENT checked-out-VCR (href)> MAY be set on the working copy with
   the href of the VCR when the current version is checked out.  This is
   set when the server supports apply-to-version.

A server that supports the working-resource option MUST support the
DAV:apply-to-version, and if we add this protocol element, it similarly
MUST add DAV:checked-out-VCR when DAV:apply-to-version is used.
Otherwise clients would have to inspect the working resource to
determine if DAV:checked-out-VCR was inserted, and then have
separate code paths for if it does, or if it doesn't.

   CHECKIN (of working copy) marshalling:
   If <!ELEMENT apply-to-version EMPTY> is present and <!ELEMENT
   checked-out-VCR (href)> exists the server performs a CHECKIN (of working
   copy) and then automatically updates the VCR to reflect the content and
   dead properties of this version.

DAV:apply-to-version only appears in CHECKOUT, not CHECKIN.

   [I need an error condition here if the UPDATE wasn't successful.  That
   could happen if checked-out-VCR was invalid.]

Good point!

That raises two issues:
- why did I propose that a client be able to modify the DAV:checked-out-VCR?
  A client could have checked out a particular version if it didn't want
  a DAV:checked-out-VCR to be set.
- should a server be required to update the DAV:checked-out-VCR property
  of a working resource if the VCR is moved?  I think the answer is yes
  (only the server can do this correctly).  This goes along with the
  previous constraint that the DAV:checked-out-VCR property is protected.

So the modified proposal is:

Add a protected DAV:checked-out-vcr property for a working resource.
Set this property on the working resource created when a CHECKOUT with
the DAV:apply-to-version flag is applied to a VCR.  Add a
postcondition to "CHECKIN" of a working resource that says that if
there is a DAV:checked-out-VCR on the working resource, the specified
VCR will automatically be updated to reflect the content and dead
properties of the new version.  Add a postcondition to "MOVE" of a VCR
that says that if there is a DAV:checked-out-VCR that identifies that
VCR, that property is updated to reflect the new location of the VCR.

Received on Monday, 18 June 2001 11:13:01 UTC

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