W3C home > Mailing lists > Public > public-ws-desc-comments@w3.org > July 2005

Re: LC72 - Faults that are not described in WSDL

From: David Booth <dbooth@hp.com>
Date: Thu, 28 Jul 2005 10:36:11 -0400
To: Roberto Chinnici <Roberto.Chinnici@Sun.COM>
Cc: Jonathan Marsh <jmarsh@microsoft.com>, public-ws-desc-comments@w3.org
Message-Id: <1122561371.4129.112.camel@nc6000.w3.org>


I don't want to be pushing LC72 if I've made an erroneous assumption,
but the minutes of the group's discussion of it at the last F2F[1] are
too sketchy for me to figure out what is that assumption.  Can you
please explain?

The minutes[1] say:
> LC 72. Faults which are not described in WSDL may be received. Closed
> with no action. Response from objector: how do you know that a
> response is a fault?
> Glen, Amy: it's up to the binding.

That's consistent with my understanding of the intent, but that isn't
clearly stated in Part1 or Part2, as my message[2] tried to explain.

> Umit: thinks he wants to be able to distinguish between declared and
> undeclared ones (ref to part two)

Sort of.  My intent is to clarify (a) that undeclared faults are as much
a part of the interface as declared faults, and thus a client
application programmed against the interface must be prepared to deal
with them; and (b) how messages representing undeclared faults can be
distinguished from erroneous random noise messages.  

> anish: is this to help distinguish, from receiver's point of view,
> between undeclared fault and undeclared other message?

Yes, exactly.

> amy: yes, that's what he's suggesting for part one, and for part two,
> as umit suggests, he's recommending greater specificity.
> roberto: not clear that the "undeclared faults" *will* always be of
> the same class as declared faults.

What do you mean by "of the same class"?  Can you give an example?  And
why must undeclared faults be of the same class for my concern to be

> umit: disagrees, his undeclared faults are only interface-level
> (application) faults

I'm talking about the mapping to interface-level faults, because Part 1
section 2.3.1 is talking about interface-level faults: 

	"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."

If at least some of these interface level faults are intended to map
from received messages (such as SOAP faults), then it seems to me that
the binding extension should specify that mapping.  

> roberto, amy: then his assumptions are faulty.

What assumptions are faulty?

> general consensus: let's not do anything about this one.
> hugo: summary is that there is no easy way to classify these
> unclassified faults; if they could be declared they would be declared.
> <uyalcina> I actually do not disagree. Rereading the message, I agree
> with Roberto.
> <uyalcina> the intent seems to capture the protocol level problems as
> well.
> <jjm> no objection*
> LC 72 to be returned to objector with the summary agreed; if faults
> aren't characterized, then we can't usefully offer further guidance in
> the specification.

1. F2F minutes:
2. My message:



David Booth, Ph.D.
HP Software / Boston
Hewlett-Packard, Inc.
Received on Thursday, 28 July 2005 14:38:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:05:57 UTC