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

Julian wrote:
> > Julian wrote:
> >
> > > b) the server deletes the VHR and un-version-controls the
> > > VCR (to avoid breaking the live versioning properties).
> >
> > In what sense would the property be "broken"?  Clearly from the
server's
> > point of view there is a good reason why it may not want to so this,
but
> > from a protocol point I don't see a problem.  For example, what would
be
> > the difference if the version-history resource is unaccessible
> > due to other
> > circumstances, such as authentication or reachability?
> >
> > The semantics of a version-controlled resource can be enforced even if
the
> > version-history resource does not exist.
>
> Even if both the resources referenced by  DAV:checked-in and
DAV:checked-out
> do not exist?

In principle, yes.  For example, if a site wanted to allow anonymous users
to see the current state of the website, by browsing the version-controlled
resources; but not allow them to view the history or checked-in,
checked-out states.  The server may still ensure that the semantics are
maintained.

I just wondered what you meant by the properties being 'broken'.  If you
envisage that to mean the references cannot be 'de-referenced' then there
are multiple reasons why that may be the case.  I see DELETE to be the
inverse of BIND (and agree with your descriptions earlier in the thread),
plus whatever further semantics we choose to apply to DELETE for
convenience.

Regards,
Tim

Received on Tuesday, 9 July 2002 12:50:58 UTC