RE: Faults that are not described in WSDL?

Doesn't SOAP define what a fault is? I always thought it was any message
that had soap:Fault as a child of soap:Body...

Gudge 

> -----Original Message-----
> From: public-ws-desc-comments-request@w3.org 
> [mailto:public-ws-desc-comments-request@w3.org] On Behalf Of 
> David Booth
> Sent: 02 June 2005 13:57
> To: Jonathan Marsh
> Cc: public-ws-desc-comments@w3.org
> Subject: RE: Faults that are not described in WSDL?
> 
> 
> I think this needs more attention, and perhaps I was not clear enough
> about my concern.  I'm fine with faults being an open set.  
> That is not
> my concern.  
> 
> My concern is that the spec is not clear about how faults that are not
> described by the WSDL interface would be recognizable as faults when
> they are received.  In other words, if a client receives an unexpected
> message X, how does it know whether message X represents a 
> well-formed,
> undeclared fault message or is an erroneous message containing random
> gibberish?  Something must indicate to the client, in a
> machine-processible language that the client understands, 
> that message X
> represents a fault.  
> 
> I think there is an implicit assumption being made that either:
> 
> a. binding/transport-level mechanisms will permit undeclared faults to
> be recognizable as undeclared faults (for example, by the use of SOAP
> fault codes or HTTP error codes); or
> 
> b. the parties must agree out-of-band (i.e., outside of the WSDL
> description) how undeclared faults can be recognized as undeclared
> faults.
> 
> Section 2.3.1 seems to be saying that conceptually every interface has
> one more fault type implicitly declared -- call it 
> UndeclaredFault -- in
> addition to the explicitly declared faults, and this is a catch-all
> fault type that can indicate any kind of fault.  Thus, an application
> written against the interface must be prepared to handle an
> UndeclaredFault in addition to the declared faults.  But how is this
> UndeclaredFault at the abstract level bound to an underlying
> binding/transport mechanism?  AFAICT, the spec does not say.  In other
> words, if a party wishes to send an UndeclaredFault, what 
> mechanism must
> be used to send it?  Both parties need to know what mechanism will be
> used, thus either the WSDL document or the WSDL spec should say
> explicitly what that mechanism is.  Rather than being silent and
> assuming that "magic occurs", I think it would be much better for the
> spec to discuss these UndeclaredFaults explicitly.
> 
> In general, the binding is responsible for indicating how 
> notions at the
> abstract level are manifested at the transport level.  In theory, a
> binding extension could provide syntax to permit 
> UndeclaredFaults to be
> bound explicitly to an underlying mechanism via 
> wsdl:bindings.  However,
> in practice, the binding extensions may always bind 
> UndeclaredFaults in
> a fixed, default way.  For example, UndeclaredFaults might always be
> bound to SOAP fault codes if the WSDL SOAP binding extension 
> is used, or
> using HTTP error codes if the HTTP binding extension is used.
> 
> In summary, I think clarification along the following lines 
> would help:
> 
> 1. Part 1 should give some indication of how UndeclaredFaults are
> expected to be bound.  For example, it could add a subsection like:
> [[
> Undeclared Faults
> Faults other than the ones described in the Interface 
> component can also
> be generated at run-time, i.e. faults are an open set.  
> Faults that are
> not declared in the Interface component are known as 
> Undeclared Faults. 
> 
> Note: It is the binding extension's responsibility to specify how
> Undeclared Faults are transmitted.  For examples, see Part 2 SOAP
> Binding Extension section @@BindingUndeclaredFaults@@ or Part 2 HTTP
> Binding Extension section @@BindingUndeclaredFaults@@.
> ]]
> 
> 2. The binding extensions should say explicitly how 
> UndeclaredFaults are
> transmitted.  For example, the WSDL SOAP MEP Binding 
> Extension could add
> a subsection to section 4.7 like:
> [[
> Binding Undeclared Faults
> In addition to any faults that are explicitly declared for an 
> interface,
> the WSDL SOAP Binding Extension can transmit Undeclared Faults
> @@reference Part 1 Undeclared Faults@@ associated with the interface.
> Undeclared Faults are always transmitted using SOAP fault code/subcode
> combinations that are not associated with any declared faults for the
> interface.
> ]]
> (The above might need to be stated in a little tighter spec-ese, but
> hopefully this gives you the idea.)
> 
> The WSDL HTTP Binding Extension could say something similar.
> 
> Please let me know if further clarification would help.
> 
> Thanks,
> David Booth
> 
> 
> On Fri, 2005-05-20 at 20:44 -0700, Jonathan Marsh wrote: 
> > Thank you for your comment - we tracked this as a Last Call 
> comment LC72
> > [1].  The Working Group declined to make any changes to the 
> spec as a
> > result.  Faults by their very nature need to be an open set.  
> > 
> > If we don't hear otherwise within two weeks, we will assume this
> > satisfies your concern.
> > 
> > [1] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC72
> > 
> > > -----Original Message-----
> > > From: public-ws-desc-comments-request@w3.org 
> [mailto:public-ws-desc-
> > > comments-request@w3.org] On Behalf Of David Booth
> > > Sent: Thursday, October 28, 2004 8:37 AM
> > > To: public-ws-desc-comments@w3.org
> > > Subject: Faults that are not described in WSDL?
> > > 
> > > 
> > > Part 1 section 2.3.1 says "Note that faults other than the ones
> > > described in the Interface component can also be generated at run-
> > > time,
> > > i.e. faults are an open set.".
> > > 
> > > I think this needs clarification.  How can a client 
> application or Web
> > > service know what additional faults to expect, and what message
> > > schemas
> > > would describe such faults?
> > > 
> > > --
> > > 
> > > David Booth
> > > W3C Fellow / Hewlett-Packard
> > > 
> > 
> -- 
> David Booth <dbooth@w3.org>
> 
>

Received on Thursday, 2 June 2005 14:15:26 UTC