RE: update to Issue #82

>Requirements R307 and R308 call for simplicity, which would 
>argue for eliminating a distinction between header and body 
>blocks if one is not warranted.  This is particularly true if 
>that distinction poses a problem for resource-constrained 
>devices, which requirement R309 reminds us to consider and 
>which are implicated in usage scenario S21. Furthermore, the 
>Abstract Model currently makes no semantic distinction between 
>header and body blocks.

I think here it is important to ask the question of simplicity with
respect to what? The act of removing things do not necessarily make
things simpler - removing traffic lane separators do not tend to make
traffic conditions simpler.

The scenario that was brought forward in [1] and which is to be added to
issue 82 is very similar (signing a block) to that of issue 25 [3] which
was the reason for my question. This is a specific scenario that I think
is useful to address - we had the same problem in HTTP and had to
introduce trailers for supporting this. 

>The primary support for maintaining a distinction comes from 
>requirement
>
>R802 and existing practice in SOAP 1.1.  A workaround exists 
>for memory-limited handlers/processors that need to produce 
>intermingled header and body blocks. The body blocks can 
>instead be produced as header blocks and then referenced in a 
>later small body block.  This has the drawback that the large 
>body blocks in the header may not be easily skipped by 
>intermediaries, which re-raises the R802 problem again. 

Note that removing the separation between header and body in fact
doesn't solve the problem presented in the scenario - in order for it to
be useful the receiver has to know up front that something is following
at the end.

This is why I think issue 25 and 82 are in fact quite closely related.

The discussion in issue 25 talks about that it is possible to have
things after the body in SOAP but that SOAP is currently silent on how
to use this other than saying that these things do not take part in the
processing model [4].

I can think of a mechanism where we have a module with a block that
points to another block and says what is in the referenced block. The
referenced block can then be at the end. This seems to work within the
current model and allows to support scenario [1]. Are there any
downsides to this?

Henrik

[1]
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2001Apr/0160.htm
l
[2] http://www.w3.org/2000/xp/Group/xmlp-issues#x82
[3] http://www.w3.org/2000/xp/Group/xmlp-issues#x25
[4] http://www.w3.org/TR/SOAP/#_Toc478383494

Received on Wednesday, 25 April 2001 21:54:53 UTC