- From: Clemm, Geoff <gclemm@rational.com>
- Date: Tue, 10 Apr 2001 18:45:11 -0400
- To: WebDAV Working Group <w3c-dist-auth@w3.org>
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