RE: binding fault defaulting?

Thank you for your comment, which we tracked as LC130 [1].  The WG
resolved to make wsoap:subcode and wsoap:code optional, to allow #any as
a token for wsoap:subcode and wsoap:code, to map a missing attribute to
#any in the component model, define #any as meaning no assertion is made
about the code or subcode value, and to make similar modifications to
http:code.  If this resolution is unacceptable, please let us know
within two weeks.

[1] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC130

> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]
> On Behalf Of Jacek Kopecky
> Sent: Thursday, May 19, 2005 11:19 AM
> To: WS-Description WG
> Subject: binding fault defaulting?
> 
> 
> 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, 9 June 2005 21:02:02 UTC