- From: Henrik Frystyk Nielsen <frystyk@microsoft.com>
- Date: Mon, 22 Jan 2001 14:05:36 -0800
- To: "Eric Prud'hommeaux" <eric@w3.org>, <xml-dist-app@w3.org>
- Cc: "Mark Nottingham" <mnot@akamai.com>
> I noticed that the xp requirements document now defines and requires > a header [1]. Due to a limitation of two participants from an > organization, I have not participated in the teleconferences or face > to face meetings. However, I don't believe that there is a paper trail > in xml-dist-app [2] documenting consensus on adopting this > terminology/constraint from the May 2000 SOAP note [3]. There actually has been a fair amount of discussion on this as it affects processing intermediaries quite a bit. It is somewhat hard to find stuff in the archives as the search mechanism doesn't seem to work but especially 802 and 811 and the discussion surrounding those addresses this. Mark Nottingham might be able to provide some more background on this. One of the arguments for a separation between parts intended for the "end" and things that may not be intended for the "end" is that it allows intermediaries to work more efficiently. > Adopting the terminology of "blocks" [4], it is easy to imagine > other, less constraining organizations of blocks to indicate > processing order, precedence, and intended recipient. For instance, > these attributes may be communicated via attributes in the block > element, association lists in a manifest, or scoping tags. The latter > describes the header/body organization adopted by SOAP except that > in SOAP, the SOAP-ENV:Body [6] conveys the intended SOAP-ENV:actor > (recipient of the block) and SOAP-ENV:mustUnderstand (see [7]). > > I believe the working group should consider whether these symantics > are always and will always be coexistentent. Otherwise, it may, for > instance, be useful to treat all blocks like the headers in a SOAP > envelope, capable of separately defining actor and mustUnderstand. I > may also be adopting the SOAP mentality to a fault here. Perhaps there > are much cooler ways to design the block assembly that I can't > concieve of. There surely are many ways that one can combine blocks but without diving too much into the design of SOAP, one shouldn't put too much into the header/body distinction in SOAP. SOAP header and body entries are very much similar and in fact the body is defined as syntactic sugaring of a header [20]. However, they provide the advantage that an intermediary knows that when it has dealt with the headers, it doesn't need to look at the rest. So for SOAP, in a sense, the header/body separation really are scoping tags and a really simple manifest mechanism built into one. Regarding your question of why the header/body notion shows up in the glossary [21], I think the primary reason for defining these concepts was exactly to capture the point about interaction with intermediaries rather than an attempt of doing design. From [21]: XP header: A collection or zero or more XP blocks which may be intended for any XP receiver within the XP message path. XP body: A collection or zero, or more XP blocks intended for the ultimate XP receiver within the XP message path. Henrik [20] http://www.w3.org/TR/SOAP/#_Toc478383504 [21] http://www.w3.org/TR/xp-reqs/#N3010
Received on Monday, 22 January 2001 17:06:09 UTC