Re: DELETE Semantics

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
protocol.

Cheers,
Geoff

> 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