W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2002

Re: issue #192 positions

From: Mark Baker <distobj@acm.org>
Date: Fri, 22 Mar 2002 17:34:59 -0500 (EST)
Message-Id: <200203222234.RAA20286@markbaker.ca>
To: chris.ferris@sun.com (Christopher Ferris)
Cc: xml-dist-app@w3.org
Thanks for doing this Chris.  I think you've got all the required
context in one message, well done.

> Analysis:
> 
> It seems clear (to me at least) that SOAP intends that the
> semantics of a message that contains a SOAP Fault element
> info item as a direct child of the SOAP Body element are that
> it is conveying error information generated at some SOAP node.

That's not clear to me.  If I had seen anything in the spec saying so,
I would have spoken up long ago.

> The SOAP spec does not say anything about the responsibility that
> a SOAP node receiving such a message, containing a SOAP Fault,
> might have in processing such a message.
>
> The resolution to issue #12[7] was that the HTTP binding would
> use the HTTP 500 status response to report a SOAP Fault being
> generated at the receiving SOAP node.

Erm, I thought it was for any of the fault codes specified in that
table?  Anyhow, not a big deal right now.

>  This resolution was taken
> before the TBTF had completed its work on the new HTTP binding
> for the Part 2 Adjuncts specification. In general, the new
> HTTP binding captures some, but possibly not all of the intent
> of the resolution to issue #12.

Agreed.

> However, this is somewhat
> orthogonal to the issue raised in #192 which has a slightly
> different slant to it in that it suggests that the HTTP
> response code be autoritive and modify the semantics of
> the SOAP Fault message which is (I believe) what Jacek and
> I are so much opposed to.

Currently, the specification says nothing about what it means for a SOAP
fault to be sent over a 200 response.  Issue 12 doesn't talk about that
case, nor does the state transition table deal with it.

> Rather, I believe that the intent of section 3.4 is that
> the *semantics* of a SOAP Fault are conveyed by virtue of
> its presence as the first child element information item
> of the SOAP Body element info item.

Again, had I seen anything in the spec that said this, I would have
brought it up.

> Any other usage of the SOAP Fault element schema fragment is
> unspecified by SOAP.

Now *that*, I agree with. 8-)

> A SOAP node MUST NOT attribute SOAP
> Fault semantics to a SOAP message containing a SOAP Fault
> element information item in any other context than the
> direct child descendant of the SOAP Body element information
> item.

Well, didn't you just say that the behaviour was unspecified?  Is this
paragraph just your opinion, or are you drawing a conclusion from some
text in the spec?  The text above doesn't suggest it, from what I can
determine.

> ======================================================================
> 
> Proposal:
> 
> Amend Sect 3.4 as follows:
> <proposed replacement text>
> Part 1 Sect 3.4 SOAP Fault
> 
> A SOAP Fault is used to carry error information within a SOAP message.
> 
> A SOAP node MUST attribute the semantics of a SOAP Fault message
> to all SOAP messages that contain a SOAP Fault element information item
> when it is present as a direct child descendant of the SOAP Body element
> information item. A SOAP Body element information item MUST
> NOT contain more than one SOAP Fault element information item
> as a direct child descendant element information item.
> 
> Any other usage of the SOAP Fault element schema fragment is
> unspecified by SOAP. A SOAP node MUST NOT attribute SOAP
> Fault semantics to a SOAP message containing a SOAP Fault
> element information item in any other context than the
> direct child descendant of the SOAP Body element information
> item.
> 
> The Fault element information item has:
> 
>       * A local name of Fault ;
>       * A namespace name of http://www.w3.org/2001/12/soap-envelope;
> ...
> </proposed replacement text>

I thought this was supposed to be compromise? 8-)  It's worse than the
status quo! 8-O

I cannot accept that resolution, because it says that a fault sent on
a 200 response must be treated as a fault.

> In addition, in order to ensure that the intent of the
> resolution to issue #12 is preserved, the SRR MEP and the
> default HTTP binding need to be tidied up.
> 
> <current text>
> 6.1.4 Fault Handling
> ...
> 
> If a SOAP Fault is generated by the Responding SOAP node while it is in 
> the Processing state, the generated SOAP Fault replaces the abstraction 
> of the Response Message that is used to set the 
> "transport:CurrentMessage" property and the state machine transitions to 
> the Responding state.
> </current text>
> 
> <proposed replacement text>
> 6.1.4 Fault Handling
> ...
> 
> If a SOAP Fault is generated by the Responding SOAP node while it is in 
> the Processing state, the generated SOAP Fault replaces the abstraction 
> of the Response Message that is used to set the 
> "transport:CurrentMessage" property and the state machine transitions to 
> the Responding state. In addition, the "transport:FaultHint" property is
> set to 'true'.
> </proposed replacement text>
> 
> The "Instantiation of Message Exchange Context for ..." tables (6.1.3)
> need to be updated to include the "transport:FaultHint" property with an
> initialized value of 'false'.
> 
> 7.4.1.2.3 Responding
> this set of tables needs to be updated to (somehow) reflect the
> processing/treatment of the 'transport:FaultHint' property. In addition,
> I think that the "MUST" intent of the resolution to issue #12
> needs to be conveyed in this section. Would suggest the following
> edit:
> 
> s/Set according to the following table/MUST be set according to the 
> following table/

Agreed.

Also, 7.4.1.2.2 needs to be updated to add faultHint=true on the 4xx
responses.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com
Received on Friday, 22 March 2002 17:30:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:09 GMT