RE: Proposal: map HTTP fault codes to interface faults

Hi Hugo!

> I'm not sure why we would need to indicate more than one. 
> In the SOAP fault component that you based your proposal 
> for example, only one SOAP fault can be attached to a fault 
> component[1].


This does expose some muddled thinking on my part: I placed HTTP 
fault codes at the level of SOAP sub-codes, which is a list.

I considered other possibilities to support ranges of fault codes
such as "4" indicating "4xx" and "40" indicating "40x", and even
splitting the fault code into a code and sub-code akin to SOAP 
(code="4", subcode="03"), but felt this was all complex syntactic 
sugar for little real benefit. How often would someone want to 
describe a range of faults?

so, i'd also be happy to further simplify the proposal to:

    <fault ref="xs:QName" http:code="xs:int">
       <documentation />?
    </fault>*


>>   - describing HTTP faults at the abstract level is orthogonal 
>>     with our SOAP/HTTP binding.
>
> Actually, not completely, as the SOAP HTTP itself defines a 
> binding of errors to HTTP faults[2]: 4xx for client errors, 
> and 5xx for server errors.


Agreed that's not orthogonal with the use of HTTP as a 
*transport*, but is when using HTTP as an *application* protocol.
The possible of routing a HTTP fault in the HTTP biding to an 
interface level fault is consistent with being able to route a SOAP 
Fault to an interface fault from the SOAP/HTTP binding.



Use-Case
--------

A Web site provides a service to download mobile phone ring-tones 
protecting this invaluable resource using a pay-as-you-go voucher 
scheme.

The service provider offers several mechanisms for accessing the 
same resource, which may or may not all described in the same WSDL 
document. All the access methods share the same abstract error 
conditions: "VoucherMissing", "InvalidVoucher" and "VoucherUsedUp".

The author for a WSDL document describing the SOAP/HTTP service in
WSDL will be able to describe the SOAP fault codes which indicate 
the abstract level faults.

With this proposal the WSDL document describing the HTTP GET in
WSDL could describe the HTTP fault codes which map onto the same
abstracted faults.
     
Paul


-----Original Message-----
From: Hugo Haas [mailto:hugo@w3.org]
Sent: 01 June 2004 16:56
To: Downey,PS,Paul,XSJ67A C
Cc: www-ws-desc@w3.org
Subject: Re: Proposal: map HTTP fault codes to interface faults


Hi Paul.

* paul.downey@bt.com <paul.downey@bt.com> [2004-05-27 17:47+0100]
[..]
> Proposed Syntax
> ---------------
> 
> we copy/re-use the SOAP fault component as follows:
> 
>   <binding>
>     <http:binding methodDefault="xsd:string"? />
> 
>     <fault ref="xs:QName"
>            http:codes="list of xs:int" >
>       <documentation />?
>     </fault>*
> 
>     <operation>
>        .....
>     </operation>
>    </binding>
> 
> Whilst this doesn't provide wild-carding or ranges of fault codes, 
> it does provide the ability for a list of individual fault codes to 
> be grouped, described and targeted at an individual abstract fault.
[..]

I'm not sure why we would need to indicate more than one. In the SOAP
fault component that you based your proposal for example, only one
SOAP fault can be attached to a fault component[1].

> Rationale
> ---------
[..]
>   - describing HTTP faults at the abstract level is orthogonal 
>     with our SOAP/HTTP binding.

Actually, not completely, as the SOAP HTTP itself defines a binding of
errors to HTTP faults[2]: 4xx for client errors, and 5xx for server
errors.

If we adopt your proposal, we should add some text about that.

Regards,

Hugo

  1.
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-bindings.
html#soap-fault-decl
  2.
http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#http-reqbindwaitsta
te
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/

Received on Thursday, 3 June 2004 07:57:19 UTC