more Re: Issue 192 & R803

It also gets us around the issue 192/12 debate.
If a query returns a fault as a child element
of the Body, it isn't a fault and can be carried
on a 200 OK.

This is very cool IMO.

Cheers,

Chris

Christopher Ferris wrote:

> +1
> 
> we can also be explicit in the schema.
> 
> <xs:element name="Envelope" type="tns:Envelope"/>
>   <xs:complexType name="Envelope">
>     <xs:sequence>
>       <xs:element ref="tns:Header" minOccurs="0"/>
>       <xs:choice>
>     <xs:element ref="tns:Body"/>
>     <xs:element ref="tns:Fault"/>
>       </xs:choice>
>     </xs:sequence>
>     <xs:anyAttribute namespace="##other" processContents="lax"/>
>   </xs:complexType>
> </xs:element>
> 
> It gets around having to say anything about what goes in
> the Body element.
> 
> I like this proposal.
> 
> Chris
> 
> Marc Hadley wrote:
> 
>> +1, good idea !
>>
>> The Body EII is pretty redundant when a fault is carried since: "a 
>> SOAP Fault MUST appear as a direct child of the SOAP body and MUST NOT 
>> appear more than once within a SOAP Body". Unless we think that it's 
>> valuable to be able to carry additional EIIs along with the fault. If 
>> so we don't currently talk about what a node should do if the body 
>> contains stuff in addition to a fault...
>>
>> Marc.
>>
>> Martin Gudgin wrote:
>>
>>> Radical suggestion:
>>>
>>> In the fault case ditch Body entirely, and replace it with Fault.
>>>
>>> <soap:Envelope xmlns:soap='http://www.w3.org/2001/12/soap-envelope' >
>>>   <soap:Header>
>>>     ...
>>>   </soap:Header>
>>>   <soap:Fault>
>>>     <faultcode>soap:Sender</faultcode>
>>>     <faultstring>You send bad stuff</faultstring>
>>>   </soap:Fault>
>>> </soap:Envelope>
>>>
>>> Gudge
>>>
>>> ----- Original Message -----
>>> From: "Christopher Ferris" <chris.ferris@sun.com>
>>> To: <xml-dist-app@w3.org>
>>> Sent: Wednesday, April 03, 2002 4:20 PM
>>> Subject: Re: Issue 192 & R803
>>>
>>>
>>>
>>>> +1
>>>>
>>>> Marc Hadley wrote:
>>>>
>>>>
>>>>> Sorry for the slow response, catching up on email slowly.
>>>>>
>>>>> I think Noah has identified an inconsistency here and we should open a
>>>>> new issue to make sure we address it.
>>>>>
>>>>> Marc.
>>>>>
>>>>> noah_mendelsohn@us.ibm.com wrote:
>>>>>
>>>>>
>>>>>> 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 Wednesday, 3 April 2002 11:38:56 UTC