RE: issue #192 positions

I agree with the formulation that Noah proposes as a refinement to the
first part of Chris's proposal. With regard to the state machine,
however, I think resolution #12 is very clear on the rules: In neither
the SOAP envelope or as part or the binding do we talk about hints - if
the two are not in sync then we have a broken implementation, full stop.
This doesn't in any way seem to be in conflict with the SOAP fault
notion or the SOAP HTTP binding.

The introduction of hints seems entirely broken to me. Do we also
consider content-length as a hint, or content-type, or the HTTP request
method name, or TCP acks for that matter?

This is similar to the situation we are moving towards for DTDs - if
there is a DTD present then it is a broken implementation - full stop.
We don't say, well it still sort of looks like a SOAP message, and if I
am careful then I can sort it out. It's an error.

Henrik

>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 20:53:23 UTC