RE: Faults that are not described in WSDL?

The WG reexamined this issue, but felt that there is no easy way to
classify these undeclared faults; if they could be declared they would
be declared in the WSDL.  It did not feel that it was necessary to add
the text you provided.

> -----Original Message-----
> From: David Booth [mailto:dbooth@w3.org]
> Sent: Thursday, June 02, 2005 5:57 AM
> 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 Monday, 25 July 2005 14:33:46 UTC