- From: Bob Cunnings <cunnings@lectrosonics.com>
- Date: Thu, 9 Sep 2004 11:46:56 -0600
- To: <public-ws-desc-comments@w3.org>
Hello, It's not that I want to bind a common fault differently to various operations. Rather, I wanted to somehow associate a particular SOAP module with a particular Interface Fault component. It doesn't necessarily have to be at the operation level. The purpose in mind was to specify a particular soap module (embodied in a header element) that would be present in a particular Fault message to carry additional information "out of band" with respect to the application generating the Fault. This module is not associated with any other message. IIRC when the binding/operation/outfault was available, the the association could be made via a wsoap:module component. Since faults are now at the interface level, would it make sense for binding/fault to contain a SOAP module component? That would do the job, unless I'm missing something here. Thanks, RC I believe they were removed when we lifted faults to the interface level and introduced Interface Fault components. Since faults are now shared by multiple operations, they can only be bound once in an interface by using a Binding Fault component. For example, it's not possible for a single fault, used by three different operations, to result in SOAP faults with different fault codes depending on which operation was being invoked when the fault was raised. I vaguely remember the WG discussing this case at the January 2004 F2F hosted by Sonic. If there is a genuine need for allowing different operations in the same interface to bind the same fault differently, we may want to (re-)introduce a Binding Fault Reference component. So please tell us more about your use case. Thanks, Roberto
Received on Thursday, 9 September 2004 17:47:26 UTC