W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1999

Re: DELETE Semantics

From: Geoffrey M. Clemm <gclemm@atria.com>
Date: Fri, 24 Sep 1999 15:39:34 -0400
Message-Id: <9909241939.AA08497@tantalum>
To: w3c-dist-auth@w3.org

Very nice summary Jim.  I agree with each point.  Just one comment on
point #1:

The mapping from "/" to a resource is not a binding, because there is
no collection in which the binding can live.  So the mapping from "/" to
a collection is done through some other (server defined) means.  We could
define some way of re-mapping "/" to some other currently namable resource,
but in general (and certainly to get started) you need some server defined
way of mapping "/" to a resource, so I don't think it would be worth
special casing the re-mapping of "/" to some current descendent of "/".

Also of course, this only applies to resources that support the WebDAV


> From: jamsden@us.ibm.com
> 1. all URL references to a resource are bindings, including the PUT or MKCOL
> used to create the resource in the first place.

> 2. DELETE is effectively an UNBIND. A server is free to garbage collect and
> actually destroy the resource if there are no remaining bindings, but this is
> not defined by the protocol.
> 3.  There is no DESTROY method that deletes the resource and all its bindings.
> 4. LOCK locks the resource, not the bindings. If the namespace needs to be
> controlled, then the user should lock the applicable parent collections.
> 5. MOVE is really REBIND (or BIND followed by DELETE). So the resource in the
> repository is guaranteed to be the same resource and locks can be retained.
> 6. There is no MOVE operation that is effectively COPY followed by DELETE or
> GET/PROPFIND followed by PUT/PROPPATCH and DELETE. If a MOVE operation fails
> because the binding to the destination cannot be created, then the user is free
> to do a COPY followed by a DELETE if that meets their needs. Client applications
> are free to hide these operations inside a move menu item if they desire.
Received on Friday, 24 September 1999 15:39:37 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:20 UTC