Re: Issue 192 & R803

Chris Ferris writes:

>> the .../ultimateReceiver role MUST be capable
>> of "correctly processing" the contents of the 
>> SOAP Body EII which I interpret as meaning, 
>> if the child of the SOAP Body EII is a SOAP
>> Fault EII, it is a fault, and I process it 
>> as such unless there is some SOAP Header 
>> block telling me otherwise. That is the SOAP
>> processing model as I understand it.

That was true, but not any more I'm afraid.  The latest editors' draft 
says with respect to body processing [1]:

"An ultimate SOAP receiver MUST correctly process the immediate children 
of the SOAP body (see 5.3 SOAP Body). However, Part 1 of this 
specification (this document) mandates no particular structure or 
interpretation of these elements, and provides no standard means for 
specifying the processing to be done."

We introduced this formulation during the great debate over body 
interpretation.  In the non-fault case, I think I am happy with it.  I 
think it also implies that ascribing semantics to a body containing a 
fault is optional (or, conversely, you might view the first and second 
sentences as contradictory in this respect.)

In the case of faults, first of all, it contradicts the rest of the 
specification in claiming that we mandate no structure for the body.  I 
suspect we should open an issue at least on that.  My guess is that (with 
apologies in advance to Mark Baker) many of us had assumed that we wanted 
to mandate not just the structure, but also the interpretation in the case 
that a fault was received.  Maybe the issue should be expanded to include 
that question as well, though knowing Mark's views, it may not be easy to 
achieve quick consensus on a resolution.


[1] 
http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#structinterpbodies

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Friday, 29 March 2002 21:37:51 UTC