- 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