RE: error condition for delete of VHR when VCR is in checked-in c ollection

If you are going to allow deletion of version histories, your best
bet is to "clean up" (at least, from the protocol perspective).
This means you should remove all references (or act as if you have
removed all references) to /vhr/123.  In particular, you would remove
references from the version-controlled-binding-set of any collection
version.  The result is that from the perspective of /a, there no longer
is a version-controlled binding to /a/b, so /a/b is just a
non-version-controlled member from /a's perspective (i.e. no error).

Cheers,
Geoff

   From: Julian Reschke [mailto:julian.reschke@greenbytes.de]

   considering:

   - a versioned controlled checked-in collection /a
   - a version controlled resource /a/b with a version history resource of
   /vhr/123
   - a server that handles deletion of version histories as request to
   un-version-control the VCR

   What should happen upon a DELETE on /vhr/123?

   - this would be considered to change the state of /a/b from being
   version-controlled to not being version-controlled, however the parent
   collection isn't checked out

   - returning Conflict with error condition
   DAV:cannot-modify-checked-in-parent seems to be a valid approach, however
   doesn't fit optimally (because the request was sent to /vhr/123, and /a
--
   which causes the error as not bein checked out -- isn't a parent
collection
   of the request URI).

Received on Friday, 28 June 2002 08:43:28 UTC