W3C home > Mailing lists > Public > xml-dist-app@w3.org > June 2001

Re: Distinction between headers and body

From: Jacek Kopecky <jacek@idoox.com>
Date: Wed, 13 Jun 2001 23:35:29 +0200 (CEST)
To: Jean-Jacques Moreau <moreau@crf.canon.fr>
cc: "xml-dist-app@w3.org" <xml-dist-app@w3.org>
Message-ID: <Pine.LNX.4.33.0106132319510.22959-100000@bimbo.in.idoox.com>
 as Glen repeatedly pointed out during the f2f discussions none
of the known SOAP implementations do mU check on the body. They
usually take a body fault as "I could understand it [as an RPC]
but there was an application fault - no such method."
 I believe we first need to clarify how many Blocks (as in AM
XMLP Blocks) are there in the Body element because if the
"independent elements" that are the result of serializing
multiref values are to be viewed as Blocks the processor must
choose to "understand" just about everything in the Body.
 If we agree that only the first child of Body is a Block, I can
easily accept performing mU check on it along with all the
 If we agree that Body contains multiple Blocks, I'd propose
either checking mU on them _after_ processing the headers or
clearly stating that no streaming is possible for a conforming
SOAP processor.
 As long as streaming is either possible or clearly and
explicitly forbidden, I'll be happy.

 Regarding your multicast non-mU indication I believe that it
_would_ indeed be an error if one of your destinations didn't
know it can be sent such an idication. If you made this operation
one-way (please pardon my use of WSDL terms here) you would
achieve exactly what you wanted - no fault would ever get to you.
And that's with the existing rules. 8-)
 Or would you expect a successful Ack from a destination that
didn't understand/process your indication?

 Best regards

                            Jacek Kopecky


On Tue, 12 Jun 2001, Jean-Jacques Moreau wrote:

 > It was suggested in the past that the Body was (essentially) syntactic
 > sugar for an mU Header targeted at the anonymous (final) actor. If so,
 > is it subject to the same processing model (check all mU first) than
 > other Headers? I believe it should, unless not all mU are deemed
 > equal. If not, are we supposed to rollback any anonymous Header that
 > is processed before the Body fails (i.e. is not understood)?
 > I am also wondering whether the mU constraint on the Body is not too
 > strict. What if I only wish to send an indication to a bunch of
 > multicast destinations, but I do not require all destinations to
 > understand (or process) my data. Do I need to use a workaround, i.e. a
 > non-mU Header with an empty Body? Are these sort of limitations
 > appropriate for the core protocol?
 > Jean-Jacques.
Received on Wednesday, 13 June 2001 17:35:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:36 UTC