Re: xp requirement document specifies headers

On Mon, Jan 22, 2001 at 02:05:36PM -0800, Henrik Frystyk Nielsen wrote:

> > 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.

Yes. header/body is, as previously mentioned, syntactic sugar, but
useful - it's a distinction that helps guide developers into tagging
their payload with "Body", so that intermediaries can do magic
without disturbing it, and/or readily identifying it for
manipulation. Without some implicit, strong identification of the
payload, there's nothing that the headers can "talk about", making it
difficult to layer in services without good foresight by the party
originally assembling the message.


I also see some reference to footers here, which makes me scratch my
head a bit. I can see two possible reasons why this would be
desireable;

* To "stream" messages, much as chunking and Trailers do in HTTP. My
  understanding was that XP messages were to be considered and
  processed only as a whole; processing messages before they are
  complete leads to complications, both in the transport binding and
  with XML processing.

* To imply a processing order by the arrangement of the modules. If
  so, what significance does placing modules after the body have?

Is the assumption that XP messages will only be considered as a whole
well-founded? If so, perhaps this should be a requirement or
restriction of some kind. If not, we should discuss the implications
(I haven't fully thought them through, I just faintly hear alarm
bells ;).

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA)

Received on Tuesday, 23 January 2001 17:15:42 UTC