The LC19 Story - Reusable Fault Components

 ref: http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC19

Action: Asir to detail binding changes or justify why they aren't necessary
(LC19)

The LC19 Story .. "We request the WG to elevate fault components as first
class daughters of definition components" .. detail changes are,


[1] Definitions Component.{faults} is a set of Fault components. {faults} is
an open set. That is, faults that are not described in {faults} property can
also be generated at run-time.


[2] An Operation Fault Reference component associates a fault to a fault
message occurring in a pattern. A fault is uniquely identified by its QName,
{target namespace} and {name} properties.

Operation Fault Reference component.{fault reference} = a fault component in
the {faults} property of the Definitions Component.


[3] A Binding Fault Component describes the concrete binding of a fault to a
concrete message format. A fault is uniquely identified by its QName,
{target namespace} and {name} properties.

Binding Fault Component.{fault reference} = a fault component in the
{faults} property of the Definitions Component.


[4] URI reference for a fault component is fault(x), where x is "{name}
property of fault".


That is,
Definition.{faults} |<------ Operation Fault Reference
                    |<------ Binding Fault
                    
Why?

* Allows users to identify faults across interfaces, across multiple
operations and referenced in bindings. Avoids duplicate fault declarations.
           
* Naturally maps to programming languages.
           
* Eliminates several constraints, limitations and best practice statements
(see below) in Part 1:

(a) "Interface Fault components are local to Interface components; they
cannot be referred to by QName, despite having both {name} and {target
namespace} properties."

- http://www.w3.org/TR/2004/WD-wsdl20-20040803/#InterfaceFault_details

(b) For interface extension, fault component's {name} and {target
namespace}:

"In cases where, due to an interface extending one or more other interfaces,
two or more Interface Faults components have the same value for their {name}
and {target namespace} properties, then the component models of those
Interface Fault components MUST be equivalent (see 2.16 Equivalence of
Components). If the Interface Fault components are equivalent then they are
considered to collapse into a single component. It is an error if two
Interface Fault components have the same value for their {name} and {target
namespace} properties but are not equivalent.

Note that, due to the above rules, if two interfaces that have the same
value for their {target namespace} property also have one or more faults
that have the same value for their {name} property then those two interfaces
cannot both form part of the derivation chain of a derived interface unless
those faults are the same fault."

Note:

For the above reason, it is considered good practice to ensure, where
necessary, that the {name} property of Interface Fault components within a
namespace are unique, thus allowing such derivation to occur without
inadvertent error."                    
                    
- http://www.w3.org/TR/2004/WD-wsdl20-20040803/#InterfaceFault_details

(c) "A particular fault of an interface is uniquely identified by the target
namespace of the interface and the name of the fault within that interface."

- http://www.w3.org/TR/2004/WD-wsdl20-20040803/#Binding_Fault_details

Regards,
Asir S Vedamuthu
asirv at webmethods dot com
http://www.webmethods.com/

Received on Wednesday, 20 October 2004 13:30:13 UTC