- From: David G. Durand <dgd@cs.bu.edu>
- Date: Mon, 25 Jan 1999 10:20:15 -0500
- To: w3c-dist-auth@w3.org
At 11:56 AM -0500 1/16/99, Geoffrey M. Clemm wrote: Roy already responded to this from an HTTP protocol point of view, based on hs rules of thumb for extension design. I'd like to make a few points based on XML document and DTD design. Roy and I both think that Geoff's proposed bundling is a bad idea, but we have different reasons for thinking it. I haven't had a chance to read Jim's paper, so apologies if I'm duplicating any of his points. >Many of the new methods being defined for WebDAV versioning have >an XML document as the value of their request and/or response body. >While designing the protocol, I am continually faced with the question: > >Should an input parameter to the method be represented as a new XML >element in the request body or as a new request header? Similarly, >should an output parameter to the method be represented as a new XML >element in the response body or as a new respose header? > snip... Snop... >The only argument I can think of for using a header is that it is >the only technique applicable when the body is being used for some >other purpose (such as GET/PUT). AS Roy says, the body is "payload". For some of our operations we treat some parameters as "payload". He might not like that part of the protocol design but it's at least logical I think. However, there are some other reasons to use headers (that I'll get to). >One possible rule of thumb: > >If the request/response body is an XML document, then the request/response >parameters should be specified as XML elements. Only if the body is not an >XML document should parameters be specified as headers. This rule of thumb might bo OK, but should _never apply_ to methods like GET/PUT, since the document being modified should not have parameters added into it, even if it were an XML document. For other messages that _already_ need to take XML encoded request bodies, your hand is also not as free as it might be. You must use a header for any information that could make sense for a GET/PUT (now, and probably also if it could ever make sense in any future extension of these methods). In general since Headers are part HTTP (the base protocol) protocol information should use headers unless it's very obviously _method specific_. If it might not always be method specific, putting it in an XML request body is dangerous, as some future method might need it in a header because the method's body is pure "payload" in an arbitrary media-type. Of course a new header (potentially) interacts with _all_ other methods, and that increases spec complexity, and (even if the effects are very local and simple) increases the time for an implementor to comprehend the spec. and implement it. So Roy is also right that minimizing the use of headers is a good idea. Of course,the versioning spec. must inherently deal with a lot of complex data objects like revision histories, and configuration specifications, and so forth. These need to be expressed in XML, but where they must be referred to in methods they should probably have URIs or some other names that can fit sensibly in headers. The Property mechanism is one way to deal with some of these, but as Yaron has pointed out, properties should not be abused as a way to create new HTTP methods... Still, I think there actually needs to be a presumptive preference for headers, unless data format, character-encoding, or protocol complexity prevent it. As Roy says, a profusion of new headers (and thus header/method interactions) is probably telling you something important that should not be ignored. -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://www.dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________
Received on Monday, 25 January 1999 10:18:53 UTC