Re: issue #192 positions

I'm comfortable with the revision as you suggest.

Thanks for taking the time to read through the
proposal:)

Cheers,

Chris

noah_mendelsohn@us.ibm.com wrote:

> I am generally in agreement with the direction you propose, though I admit 
> I have not had time to work through all the details.  Certainly I am in 
> agreement that a SOAP fault element has meaning to SOAP only when it is 
> the immediate child of Body.  Other uses are permitted, but undefined. 
> 
> I have not looked at the HTTP-specific issues as closely, but I think the 
> general rule should be: we establish transport-independent rules (as 
> above) for SOAP, and then make sure there is nothing in our use of the 
> transport that is inconsistent with their usage in SOAP.  Therefore, 
> though I claim no expertise in HTTP, I would expect us to mandate status 
> code 5XX (or whatever is appropriate for errors) when and only when the 
> fault element occurred as the immediate child of Body.
> 
> One detail in your proposal needs minor refinement, I think.  You suggest:
> 
> "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."
> 
> The word "descendant" suggests that grandchildren are allowed, which 
> somewhat contradicts the word "direct", and is exactly what we want to 
> rule out.  I believe that with Infoset terminology, we can merely say: 
> 
> "A SOAP Body element information item MUST NOT have more than one SOAP 
> Fault element information item among its [children]."  See [1].
> 
> Thanks.
> 
> Noah
> 
> [1] http://www.w3.org/TR/xml-infoset/#infoitem.element
> 
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
> 
> 
> 
> 
> 
> 
> 
> Christopher Ferris <chris.ferris@sun.com>
> Sent by: xml-dist-app-request@w3.org
> 03/22/2002 10:14 AM
> 
>  
>         To:     xml-dist-app@w3.org
>         cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
>         Subject:        issue #192 positions
> 
> 
> All,
> 
> I took an AI on the 20-Mar telcon to summarize the opposing
> positions w/r/t Issue #192[1] "When is a Fault a Fault?" and
> to propose a resolution.
> 
> Background:
> 
> Mark Baker writes in [4]:
> 
> But that's not an inconsistency.  Like I said in my example, what if I
> wanted a debugging interface on my components such that I could ask
> "give me the last fault you sent".  In the tunnelled view of SOAP,
> there's no way to know whether what you're getting is the fault
> you're asking for, or a fault generated because of your question.
> 
>   > I'd hate it if we say "if
>   > the protocol binding says the message is/isn't a fault message,
>   > this is the true information, otherwise look at the first member
>   > of the Body."
> 
> Yes, I'd hate that too.  That's why we need a single authoritative
> piece of info that processors can use, and why I'm suggesting that for
> transport protocol bindings, we can have something in-band, but that
> this mechanism SHOULD NOT (would like to use MUST, but I don't think
> it's strictly required) be used for application protocol bindings.
> 
> Jacek Kopecky writes in[5]:
> I maintain that saying "this fault is not fault, it's application
> data" should be handled by the application, for example by
> wrapping the actual fault in a Body's child element.
> 
> Chris Ferris writes in[6]:
> I would suggest that we say that a SOAP Fault is a SOAP
> envelope containing a SOAP:Fault element as the first child
> element information item of the SOAP:Body element information
> item, period. That makes it abundantly clear and unambiguous
> to a SOAP processor that this is indeed a SOAP Fault message.
> 
> If you wanted to support an edge case such as you describe
> whereby a Fault element is carried in the Body of a SOAP
> envelope (e.g. the gimme the last Fault you issued request)
> but is not considered as a SOAP Fault message then
> the appropriate means for doing so would be to either a)
> wrapper the Fault element in another element that conveys some
> harmless intent (like a SOAP RPC req/resp) or b) add a SOAP
> extension header with mU="1" that says in effect "IGNORE the
> Fault element in the Body of this message, it is informational
> and NOT operational".
> 
> Stuart Williams writes in[8]:
> 
> I think that's a good catch. I think faultHint is only discussed in the
> context of the requesting node as well. I think it perhaps also needs
> to be used in the transition from Processing to Sending at the
> responding node.
> 
> The bulk of the material in the HTTP binding was written ahead of the
> resolution of Issue 12 (HTTP status codes and faults, loosely described 
> as 500 v 200).
> 
> ======================================================================
> 
> 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.
> 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. 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. 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.
> 
> It has been suggested repeatedly (see above) that to accomodate a use
> case where an application (not SOAP) wanted to exchange
> a SOAP Fault element, that it be wrappered in some application-specific
> element information item. The problem that exists is that the
> SOAP Part 1 specification states quite clearly that the SOAP
> Fault element MUST be the first child element information item
> of the SOAP Body element information item:
> 
> Part 1 Sect 3.4 SOAP Fault[2]
> 
> A SOAP Fault is used to carry error information within a SOAP message.
> 
> If present, a SOAP Fault MUST appear as a direct child of the SOAP body
> and MUST NOT appear more than once within a SOAP Body.
> 
> The Fault element information item has:
> 
>       * A local name of Fault ;
>       * A namespace name of http://www.w3.org/2001/12/soap-envelope;
> ...
> 
> This current wording seems to preclude the usage of the SOAP
> Fault element information item in a context where it is
> NOT the direct child of the SOAP Body element information item.
> Thus, as currently specified, use of a wrappering element
> seems to be precluded (although IMO this is unenforcable).
> 
> 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. A *generated* SOAP Fault MUST
> be reported in such a way that the SOAP Fault element MUST
> be the first child descendant of the SOAP Body 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.
> 
> ======================================================================
> 
> 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>
> 
> 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/
> 
> Cheers,
> 
> Chris
> [1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x192
> [2] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#soapfault
> [3] http://lists.w3.org/Archives/Public/xml-dist-app/2002Mar/0007.html
> [4] http://lists.w3.org/Archives/Public/xml-dist-app/2002Mar/0026.html
> [5] http://lists.w3.org/Archives/Public/xml-dist-app/2002Mar/0027.html
> [6] http://lists.w3.org/Archives/Public/xml-dist-app/2002Mar/0017.html
> [7] http://lists.w3.org/Archives/Public/xmlp-comments/2001Oct/0003.html
> [8] http://lists.w3.org/Archives/Public/xml-dist-app/2002Mar/0166.html
> 
> 
> 
> 
> 
>

Received on Friday, 22 March 2002 16:41:22 UTC