RE: Clarificatioin for binding fault

Thank you for your comment, tracked as LC56 [1].  The WG resolved this
as a duplicate of LC55 [2], which we accepted as described at [3].

 

If we don't hear from you within two weeks, we'll assume this resolution
is satisfactory.

 

[1] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC56

[2] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC55

[3]
http://lists.w3.org/Archives/Public/public-ws-desc-comments/2005May/0022
.html

 

 

________________________________

From: Liu, Kevin [mailto:kevin.liu@sap.com] 
Sent: Wednesday, September 29, 2004 5:37 PM
To: public-ws-desc-comments@w3.org
Cc: Jonathan Marsh
Subject: Clarificatioin for binding fault

 

Unlike interface faults, no binding operation level <infault> and
<outfault> constructs are provided in the LC draft. I don't recall and
can not trace discussion on the rationale for such in-symmetric desgin
from the mail archival. Since Faults have been changed so many times, I
would like to make sure we still have a common understanding about how
it should work and that no problem are introduced here. 

 

Without corresponding <infault>/<outfault> in the binding level, here is
how I see it works:


1. How can one figure out which fault an binding operation uses?

 

This seems do-able without binding level <infault>/<outfault>. Since a
binding operation refers to an interface operation, one should be able
to get the fault message reference from the interface operation, and
then look up the binding <fault> corresponding to the interface <fault>
to figure out. It's do-able, but convoluted. 

 
2. How can one specify a different fault code, soap module, and maybe
custom binding extensions  for infault and outfault  of an binding
operation?

 

This is also do-able, but again cumbersome -  one has to define
different interface <fault>s for infault and outfault even if they share
a same fault message. 

 

If this correctly reflects the group's thinking, I will add some text in
the primer accordingly.

Best Regards,
Kevin