RE: Faults that are not described in WSDL?

Sorry, I forgot to correct the "From:" address on that message.  It
shows my old dbooth@w3.org address instead of my current dbooth@hp.com
address.  Please use my dbooth@hp.com address now.  Thanks!



On Wed, 2005-06-08 at 12:03 -0400, David Booth wrote:
> Yes, SOAP 1.2 does define how faults are transmitted:
> http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#soapfault
> But that is at the transport level.  Something still needs to say how
> SOAP's notion of a fault maps to WSDL's notion of a fault, which is
> independent of transport.  For faults that are declared in a
> wsdl:interface, this is already covered by the spec, because the
> wsdl:binding must explicitly specify how they are mapped.  But for
> Undeclared Faults, the spec does not say how they are to be
> mapped/recognized.
> 
> My suggested additional verbiage for the WSDL SOAP MEP Binding Extension
> may not be worded quite right.  Perhaps it should talk about the
> soap12:Fault element instead of fault codes.  But the point is that
> something in the spec should say how Undeclared Faults are to be
> recognized at the WSDL abstract level.  Otherwise, different
> implementations are apt to handle them differently -- all supposedly
> being faithful to the wsdl:interface that the service exposed.  
> 
> David Booth
> 
> On Thu, 2005-06-02 at 07:15 -0700, Martin Gudgin wrote:
> > 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: David Booth
> > > 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>
> > > 
> > > 
-- 

David Booth, Ph.D.
HP Software / Boston
Hewlett-Packard, Inc.

Received on Wednesday, 8 June 2005 16:10:29 UTC