- From: Jacek Kopecky <jacek.kopecky@deri.org>
- Date: Thu, 19 May 2005 20:19:06 +0200
- To: WS-Description WG <www-ws-desc@w3.org>
Hi all, I'm using WSDL 2 in our Semantic Web Services thing here and I have to explain very shortly how WSDL works. Now I got to the point that faults cannot be defaulted in SOAP binding. I checked the HTTP binding and it surprised me a bit that whttp:code is optional and when it's omitted, no claim is made by the service. I interpret that as "the implementation can choose" and if I was implementing this, I'd probably initially choose just always to send 500 (internal server error) if the service didn't specify and I'd be conforming to the HTTP binding, right? Why cannot we have the same situation in SOAP? I mean, HTTP 4xx is equivalent to a Sender SOAP fault code and HTTP 5xx is equivalent to a Receiver SOAP fault code, therefore if we are OK with HTTP defaulting to 500 (in my potential implementation), we could likewise be OK with SOAP defaulting to Receiver (or whatever the implementation chooses). I suggest that we change the SOAP binding to make wsoap:code optional and when omitted, no claim is made by the service. In my simple works here, I find the requirement of providing wsoap:code somewhat unwieldy as it destroys the nice defaultability of the binding. I searched the issue lists and only found a relevant issue (LC52c) where we say that fault codes are not defaultable, but this is in conflict with what we happily do in HTTP binding. I expect this might be new information for LC52c (sorry about that) or possibly a new issue. 8-) Best regards, Jacek
Received on Thursday, 19 May 2005 18:19:14 UTC