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

 Jean-Jacques,
 my understanding is that the header targeted at none and whose
parts (or whole) is referenced by some means will _not_ be
processed as usual (as if it were targetted at next, for
example).
 If we can imagine a model where one procedure is called for each
header block that is to be processed, then the procedure would be
called only for A, but the data it would get, after
dereferencing, would include the data from the header B.
 Maybe this way: the processing model doesn't know any
referencing can take place so B is not checked or processed.
 Encoding should not know any "processing model" is in place, it
should just handle its stuff, e.g. referencing data wherever it
is.
 I'm still convinced B should not be checked for understanding.
If data that is not maningful is referenced, that is a wholly
different error altogether.

                   Jacek Kopecky

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



On Fri, 23 Nov 2001, Jean-Jacques Moreau wrote:

 > 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:36:28 UTC