W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > July to September 2002

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

From: Tim Ellison <Tim_Ellison@uk.ibm.com>
Date: Tue, 9 Jul 2002 17:50:42 +0100
To: ietf-dav-versioning@w3.org
Message-ID: <OF92FBBB11.11B3E83F-ON80256BF1.005BE6A2@portsmouth.uk.ibm.com>


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 GMT

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