W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2001

RE: xp requirement document specifies headers

From: Henrik Frystyk Nielsen <frystyk@microsoft.com>
Date: Mon, 22 Jan 2001 14:05:36 -0800
Message-ID: <008501c084bf$72eeb380$308f3b9d@redmond.corp.microsoft.com>
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. 


[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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:30 UTC