Re: xp requirement document specifies headers

On Mon, Jan 22, 2001 at 02:05:36PM -0800, Henrik Frystyk Nielsen wrote:
> > 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.

While I agree that an end-of-non-default-agent-blocks marker allows
for optimization of intermediaries, I think it could just as easily go
into an extension. This would simplify the object model, keeping a one
to one mapping between object symantic and XML tag. It would also
allow for more complicated extensions should the need arise.

For instance, with a SOAP-like encoding:

<SOAP-ENV:Block
 SOAP-ENV:mustUnderstand="sureWhyNot"
 SOAP-ENV:actor="...actor1">
   <joez:Extension joez:importData="pi" />
</SOAP-ENV:Block>

<SOAP-ENV:Block>
   <opt:endOfActors />
</SOAP-ENV:Block>

<SOAP-ENV:Block>
   <!-- end to end data here -->
</SOAP-ENV:Block>

<SOAP-ENV:Block>
   <opt:endOfData />
</SOAP-ENV:Block>

<SOAP-ENV:Block>
   <!-- MD5Sum and other transport assurances -->
</SOAP-ENV:Block>


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

Should this be "A collection of zero or more..."?
                              ^
-- 
cheers,
-eric

(eric@w3.org)

Received on Tuesday, 23 January 2001 14:43:52 UTC