- From: Doug Davis <dug@us.ibm.com>
- Date: Wed, 31 Oct 2001 17:44:08 -0500
- To: Christopher Ferris <chris.ferris@sun.com>
- Cc: Noah_Mendelsohn@lotus.com, henrikn@microsoft.com, hugo@w3.org, jacek@systinet.com, xml-dist-app@w3.org
Actually, I think non-rpc soap node would barf (right now) just like
rpc ones. I suspect that most people view the body as a single
XML block (for example, a single PO) and expect nothing but the
PO to be in the body. I might be wrong, but I'd be surprised if a
non-rpc SOAP handler handles the 2nd example nicely (now).
The spec talks about headers being used as "extensions" not
the body - so it would make sense that SOAP nodes don't except
to see extensions in the body.
-Dug
Christopher Ferris <chris.ferris@sun.com> on 10/31/2001 05:07:07 PM
To: Doug Davis/Raleigh/IBM@IBMUS
cc: Noah_Mendelsohn@lotus.com, henrikn@microsoft.com, hugo@w3.org,
jacek@systinet.com, xml-dist-app@w3.org
Subject: 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:44:51 UTC