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 13:02:06 UTC