RE: [offlist] WebDAV Delete post (Flavors of DELETE)

Well, since we've got Roy's attention (:-) ...

If your server does DELETE's to a trash collection (instead of making
it totally disappear), wouldn't that fall under the "capabilities"
of your server?  And if your server maintains that trash collection
at a fixed location (for all resources on that server), why would that
be unreasonable/bad information to include in the OPTIONS response
(I am assuming that we give OPTIONS a request body in which the 
client indicates what OPTIONS information it is interested in).

To emphasize, I don't advocate this approach (i.e. live properties are
fine with me), but the topic has been raised in several threads, and I
haven't seen a convincing argument either way.  (Note: There has been
no lack of definitive statements ... but unfortunately the definitive
statements from different people have not agreed with each other :-).

On the separate topic of header vs. method body, although it is
clear that method semantics of concern to a proxy should be in
headers (so that the proxy doesn't need to process the body),
could you motivate why the detailed request semantics needed only
by the resource implementation shouldn't appear as XML (WebDAV
seems to work reasonably well with request bodies like PROPPATCH
in XML).  Is it important for a proxy to know whether or not a 
DELETE'd resource has been copied/moved to a trash collection?
Or is it some other argument against XML (XML parsers are pretty
trivial).

Cheers,
Geoff

   From: Roy T. Fielding [mailto:fielding@ebuilt.com]

   On Tue, Apr 10, 2001 at 05:36:25PM -0400, Clemm, Geoff wrote:
   > Some folks prefer to use OPTIONS for things that are true
   > for the whole server, and some folks just
   > hate live properties, but the live property is fine with me.

   OPTIONS is for communicating extensions and capabilities, not for
   identifying the URI of a trash resource.  That is simply an external link
   in hypermedia parlance.

   > As for the issue of whether to marshal in a request header vs. in a
   > request body, a new request header eats up part of a global namespace,
   > whereas an XML request body can use namespaces to keep extensions
   > from stepping on each others toes, so I stand by my
   > preference for using the request body for method specific parameters
   > (of course, for methods like PUT that use the request body for content,
   > that is not an option).

   XML namespaces are no more capable of extensions than a global namespace
   controlled by a standard.  The only difference is who gets to define
them.
   HTTP and XML have different design philosophies in that regard, and so
   far the HTTP one has proven to be right (XML namespaces are 100%
extensible,
   but have almost zero interoperability success).  I'm not sure yet which
   type of extensibility is better for a protocol.  I only know that needing
   to parse XML in order to determine request semantics is totally and
   irretrievably bad design.

Received on Tuesday, 10 April 2001 18:44:07 UTC