W3C home > Mailing lists > Public > public-ws-addressing@w3.org > December 2006

Proposed response: Default Action Pattern for inherited faults

From: Paul Knight <paul.knight@nortel.com>
Date: Mon, 4 Dec 2006 16:03:14 -0500
Message-ID: <4B7DAC3FEFD35D4A96BDD011699050140BCA87E2@zrtphxm1.corp.nortel.com>
To: <public-ws-addressing@w3.org>

Hi all,

Action: Paul Knight to review document and issue to advise on response.

The issue is described in [1].
It asks:
In the case of a WSDL 2.0 interface inheriting another interface, what
wd be
the Default Action pattern for Faults that were inherited from the
interface ? Would it be still containing the targetNamespace of the
interface [the declaring interface], and the name of the target
or would it be composed from the targetnamespace and the interface name
the child interface ?

The semantics for this is Not clear in the document that describes the
2.0 Binding for WS-Addressing.

Proposed answer:
For reference, the Default Action pattern (including faults) is
described in Section 4.4.2 of the WSDL Binding [2].

Handling of inherited faults is not explicitly discussed in the
WS-Addressing specifications.  It appears to be adequately addressed in
the WSDL 2.0 specifications.

Since the "fault element has a required name attribute that must be
unique within the parent interface element," [3] and since the child
interface must contain a link to the parent, it will be appropriate to
use the child interface name.

WSDL 2.0 indicates that the child interface should be able to process
the faults inherited from the parent interface.  Thus the
targetNamespace and the interface name of the child interface should be

Note that WS-Addressing WSDL Binding provides a clear mechanism for
specifying the value of the [action] property in a WSDL description
(Section 4.4.1, Explicit Association), and this mechanism can be used to
avoid any ambiguity.

[2] http://www.w3.org/TR/2006/CR-ws-addr-wsdl-20060529/#defactionwsdl20
Received on Monday, 4 December 2006 21:03:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:15 UTC