Re: Comments on issue 101

Doug,

This is taking a very RPC-centric view of SOAP (IMO).
While I would agree that a SOAP RPC handler would likely
choke on the second example, there is no reason to suggest
that a message-oriented handler could not deal with
this form of message because it deals with the message
as a whole (typically), and one would assume that the
message listener was capable of dealing with the messages
it receives.

Cheers,

Chris

Doug Davis wrote:

> I think it would be interesting to see how many SOAP
> processors would be able to successfully process
> a message where instead of:
>   <env>
>     <header>
>       <myheader1 mu=1/>
>     <header>
>     <body>
>       <getQuote.../>
>     </body>
>   </env>
> we sent:
>   <env>
>     <body>
>       <myheader/>
>       <getQuote.../>
>     </body>
>   </env>
> Just a guess but I think most would not - and I think
> it is mainly because they had a similar interpretation
> of the spec.
> When we say headers should be (or are) just like the
> body, why do we say that headers should be used as
> extensions - why not use the body?  Sure we can, as
> long as you wanted an implicit MU attribute - but we
> don't tell people to do that - should we?  Maybe if
> we did that then I would be less inclined to look at
> the Body as a single unit.  And going one step further
> why not just get rid of the MU attribute at all - then
> we have Martin's proposal, where we have an optional
> section and a mandatory section - or if we want to
> have an ordered mixing of MU and non-MU blocks then just
> get rid of the HEADER and BODY elements and just have
> blocks.
> I think it is important to understand why the above
> example would fail (my assumption) and what we could
> do to fix it so that either we don't break them or we
> make it perfectly clear to implementors why they're
> all wrong.
> -Dug
> 
> 
> Noah_Mendelsohn@lotus.com on 10/31/2001 03:29:20 PM
> 
> To:   Doug Davis/Raleigh/IBM@IBMUS
> cc:   henrikn@microsoft.com, hugo@w3.org, jacek@systinet.com,
>       xml-dist-app@w3.org
> Subject:  RE: Comments on issue 101
> 
> 
> 
> 
> Dug Davis writes:
> 
> 
>>>The spec specifically says we're not going to
>>>deal with things like boxcarring so what
>>>does multiple independent
>>>body blocks mean then, if not taken a single
>>>unit ?
>>>
> 
> I think it means the same thing as multiple header blocks, all with
> mustUnderstand="1", all addressed to the anonymous actor.   That is:
> follow the rules in chapter 2.  Just because you understand and process
> multiple entries, whether in Header or Body, does not mean your are
> boxcarring (it might, we can't prohibit it, but we aren't working through
> the many issues you would need to handle to make boxcarring work.)  In
> general, we say:
> 
> Note also that nothing in the spec says anything about the order of
> processing of such anonymous header blocks vs. body blocks.  They're
> symmetric.  In general, order is indeterminate unless the message uses
> special features: [1]
> 
> "It is possible that the processing of particular SOAP block would control
> or determine the order of processing for other SOAP blocks. For example,
> one could create a SOAP header block to force processing of other SOAP
> header blocks in lexical order. In the absence of such a SOAP block, the
> order of processing is at the discretion of the SOAP node."
> 
> I really think we don't want to invent special rules for all of this
> involving the body.  It's syntactic sugar for a common case, and it is
> suggestive of being the main point of the message.
> 
> Also:  I disagree with those who say that the body can't be manipulated by
> intermediaries.  If that were true, how could we do encryption at
> intermediaries?
> 
> [1] http://www.w3.org/TR/2001/WD-soap12-part1-20011002/#procsoapmsgs
> 
> ------------------------------------------------------------------------
> Noah Mendelsohn                                    Voice: 1-617-693-4036
> Lotus Development Corp.                            Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------------
> 
> 
> 
> 
> 
> 
>

Received on Wednesday, 31 October 2001 17:12:21 UTC