Re: wsa:FaultTo unusable for SOAP mustUnderstand faults

* Rogers, Tony <Tony.Rogers@ca.com> [2005-06-09 16:30+1000]
> Hmm - yes, it's not immediately obvious, and some might claim it's counter-intuitive (I don't).
>  
> I'd suggest that we'll want to include in the spec something in the way of a table of what faults must / can be reported in what way to aid understanding. A table with a vertical axis showing type of fault (eg: bad URL, bad headers, bad data in the request, etc), and a horizontal axis showing perhaps method, back channel, faultTo address, with an indicator of which can be used for what. A bad URL fault will probably come back as a fault from the method that you tried to call to send the request. Bad headers will probably come back on the back channel (if there is one). Bad data in the request (the -1 to a real square root function) would come back to the faultTo. And so on.
>  
> Would that suit what you were suggesting, Hugo? Or is that more than you expected?

Actually, I was thinking of something simpler at this point, i.e. add
in the SOAP binding in section 2.3:

  http://www.w3.org/2005/03/addressing/feature/FaultEndpoint

    Corresponds to the abstract [fault endpoint] property.

    [ The following text is the proposed addition: ]

    Note: This binding of [fault destination] to SOAP does not
    influence the dissemination of SOAP mustUnderstand faults. A SOAP
    processor receiving a message containing WS-Addressing SOAP header
    blocks and faulting with a SOAP mustUnderstand fault MUST not
    process any WS-Addressing SOAP headers.

And in section 3.2 Description (right now, we don't use the word
"process" despite the SOAP processing model being all about
processing):

    When receiving a message, the processing of the WS-Addressing
    headers by the receiving SOAP node is as follows: the abstract
    properties are populated from their corresponding element
    information items in the message.

Cheers,

Hugo

-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/

Received on Thursday, 9 June 2005 12:10:16 UTC