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 \__________________________