Re: Proposed resolution of issue 101: relationship between header and body blocks

 Jean-Jacques,
 I'd like to comment on your concerns from the second paragraph.
 Today's telcon agenda item number 11 is a resolution proposal
for issue 170 which, if passes, will disallow SOAP Encoding
references from body to header. There is nothing to disallow
applications to use other means of referencing to refer from the
body to a header. But the SOAP spec's native mechanism won't
allow that.
 As for mU on a header targeted to .../none, you are right, it is
ignored. At least I understand it as though it must be ignored
(unless some extension says otherwise but then extensions can do
just about anything anyway).
 About failing on referencing into an not understood mU header:
this is a matter of layering. As it is now, the Encoding layer
comes in _after_ the processing model so all mU failures will be
resolved before the encoding rules are applied to the data.
Therefore no mU fault can be generated as a result of some block
referencing a not understood header because when we talk
"referencing", we don't care about "understanding" any more.
 Just my understanding, I may be mistaken, of course. 8-)

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Wed, 14 Nov 2001, Jean-Jacques Moreau wrote:

 > I am feeling somewhat incomfortable with point b),
 > especially if the next step is to disallow multiple body
 > blocks. Unless there is strong evidence that this is a
 > necessary restriction, I would suggest that we remove b)
 > from the proposal.
 >
 > On a related note, I am have been wondering recently about
 > the processing model and mU blocks. Am I correct in
 > thinking that, today, we allow body blocks to reference
 > hearder blocks, and vice-versa? Does it make sense for an
 > mU header block to be targetted at none? Does it make sense
 > for a body block to reference an mU header block? Is an
 > intermediary supposed to abort processing if it finds a
 > non-mU header block that references an mU header block it
 > does not understand (i.e. is section 2.5 meant to be
 > recursive?)?
 >
 > Jean-Jacques.
 >
 >

Received on Wednesday, 14 November 2001 13:22:18 UTC