- 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
Roberto, 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 relevant? > > 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: http://lists.w3.org/Archives/Public/www-ws-desc/2005Jul/att-0128/20050720-ws-desc-minutes.html 2. My message: http://lists.w3.org/Archives/Public/public-ws-desc-comments/2005Jun/0000.html Thanks -- David Booth, Ph.D. HP Software / Boston Hewlett-Packard, Inc.
Received on Thursday, 28 July 2005 14:38:45 UTC