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

Jacek,

I am looking at this from a different perspective. Consider a message
with two header blocks, A and B. Either A and B are logically
independent, in which case they should be treated independently by the
processing model; or they are linked, for example via an encoding
href, in which case, in my opinion, they should be dealt with in
conjunction. I.e. processing should be aborted if either of them is
not understood (assuming they are both mU).

The problem really only occurs when either A or B is targeted at none,
marked mustUnderstand, referenced by the other block, and is not
understood.

I think you are saying: too bad, we forgot to see the link between the
two blocks, we missed this extra block, and now it's there for
processing and we do not undertand it. (I apologize in advance if this
is an oversimplification of your argument.)

I would prefer not to run in that situation. But at the same time, I
do not want the processing model to become a bulky machinery that has
to follow references.

Comments?

As for your other point, yes, you have found a bug.

Jean-Jacques.

Jacek Kopecky wrote:

>  Jean-Jacques,
>  first a question of clarification: what is the meaning of the
> 'href' attribute on the first header? If that is the Encoding
> href reference, the element xx:user must not have any children.
> If it is other href, please explain what that means in your
> application - it is not readily apparent to me.
>  Anyway, in your second example, the second header is targeted at
> none so the processing model does _not_ dictate a mustUnderstand
> fault.
>  On the other hand, the handling of unknown referenced data
> depends on the definition of href. Dereferencing the SOAP
> Encoding href, for example, never results in generating a
> mustUnderstand fault. The ID that is referenced is there, so no
> other fault should be generated either.
>  So my answer is "let's not mix the processing model terms
> (mustUnderstand and actor and targetting) with the encoding terms
> (references) because they are on different levels and should not
> affect each other."
>  Best regards,
>
>                    Jacek Kopecky
>
>                    Senior Architect, Systinet (formerly Idoox)
>                    http://www.systinet.com/
>
> On Thu, 22 Nov 2001, Jean-Jacques Moreau wrote:
>
>  > [Ok, no reaction, so let's try this again with a concrete
>  > example.]
>  >
>  > In the following example, the "next" SOAP node will fault if it
>  > does not understand "xx:user":
>  >   <envelope>
>  >     <header>
>  >       <xx:user
>  >           mU="true"
>  >           href="#example.org"
>  >           actor="next"><name>fred</name></xx:user>
>  >       <yy:company
>  >           id="example.org"
>  >           actor="none"><name>Example Org</name></yy:company>
>  >     </header>
>  >     <body>...</>
>  >   </envelope>
>  >
>  > In this other example, should the "next" SOAP node fault if it
>  > does not understand "yy:company"?
>  >   <envelope>
>  >     <header>
>  >       <xx:user
>  >           href="#example.org"
>  >           actor="next"><name>fred</name></xx:user>
>  >       <yy:company
>  >           mU="true"
>  >           id="example.org"
>  >           actor="none"><name>Example Org</name></yy:company>
>  >     </header>
>  >     <body>...</>
>  >   </envelope>
>  >
>  > ... probably... after all, the second block is implicitely
>  > targetted at the next SOAP node, and is not understood by that
>  > node. But is this not currently disallowed by the processing
>  > model (section 2.3 targetting + section 2.5 processing model,
>  > although a reading of section 2.5 alone my lead to a different
>  > conclusion)?
>  >
>  > Jean-Jacques.
>  >

Received on Friday, 23 November 2001 11:26:55 UTC