Disambiguating default wsa:Action pattern in inherited faults

Gurus,

I have a question, and appreciate your comments on the same.
In the event that an interface that extends another interface [in an
imported description] happens to define a fault with the same local name
[but different namespace name, and hence a different {name} property] as one
thats defined in the parent interface, wouldnt there be a possible ambuguity
in resolving the "default" WSA Action pattern for faults within the
component model of the importing description.?
Let me explain my doubt with an example.

I have two WSDLs.

WSDL A:-
-------------
<description targetNamespace="www.parent.com">
<interface name="parent">
   <fault name='sampleFault" .../>
</description>

WSDL B:-
--------------
<description targetNamespace="www.child.com">
 <import the parent wsdl/> [from the different namespace]
 <interface name="child" extends="prns:parent">
  <fault name="sampleFault" .../>
 </interface>
</description>

WSDL B. defines the bindings for the portType "child" and finally the
endpoints.

Question is :- How wd we resolve the default action pattern between the
"declared and the inherited" version of "sampleFault" in the description for
WSDL B.? [The interface "child" inherits the "sampleFault" from the parent
interface, and since the namespace names are different, there does not seem
to be a conformance violation, or is there a violation ?.]

If there isnt a violation, then here is the explanation of the problem. The
default wsa action pattern for faults is [target
namespace][delimiter][interface name][delimiter][fault name]. Where fault
name is specified as the local name of the "fault". The WS-A
specification does not state that the interface name should be the local
name of the original declaring interface.[in this case, "parent"]
This makes both the declared and inherited faults indistinguishable while
computing the default action pattern.

If this makes some sense, we can either have the 2.0 spec mandate the
inherited fault names to have a different local name altogether [in addition
to a different namespace name], which makes life much simpler, or
alternatively let the WS-A spec explicitly state that the {interface name}
in the default action pattern should be the name of the interface that
originally declared the fault, and {targetNamespace} be it's target
namespace. We could also mandate that this scenario requires the modeler to
explicitly specify WSA Actions in the description.  [well, am I going on a
huge tangent ? ...... well, hope not :-) :-) ]

I'd appreciate your comments on this.
rgds,
Ram


-- 
Shift to the left, shift to the right!
Pop up, push down, byte, byte, byte!

-Ramkumar Menon
A typical Macroprocessor