- From: Rogers, Tony <Tony.Rogers@ca.com>
- Date: Thu, 9 Jun 2005 16:30:26 +1000
- To: "Hugo Haas" <hugo@w3.org>, "David Hull" <dmh@tibco.com>
- Cc: <public-ws-addressing@w3.org>
Received on Thursday, 9 June 2005 06:30:32 UTC
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? Tony -----Original Message----- From: public-ws-addressing-request@w3.org on behalf of Hugo Haas Sent: Thu 09-Jun-05 16:17 To: David Hull Cc: public-ws-addressing@w3.org Subject: Re: wsa:FaultTo unusable for SOAP mustUnderstand faults
Received on Thursday, 9 June 2005 06:30:32 UTC