Re: Proposed resolution of issue 101: relationship between headerand body blocks

So what seems to be on the plate right now is:

   * to reinforce the distinction between body and header (i101)
   * to disallow references from body to header (i170)
   * to allow only one body block per message

This gives the picture of a very narrowedly corseted protocol,
especially when contrasted with a generic XML document, where the
flow of blocks is contrainted only by schemas at design time. Are we
not being too restrictive with ourselves? Shouldn't we be more open
in the core protocol, and defer specialisation to niches?

Comments?

Jean-Jacques.

Jacek Kopecky wrote:

>  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 Thursday, 22 November 2001 11:19:45 UTC