This issue has been added to the wsbpel issue list with a status
The status will be changed to "open" if a motion to open the issue is
proposed and that
motion is approved by the TC. A motion could also be proposed to close
further consideration. Otherwise it will remain as "received".
The issues list is posted as a Technical Committee document to the
WSBPEL TC pages
on a regular basis. The current edition, as a TC document, is the most
recent version of the document entitled in the "Issues" folder of the WSBPEL
TC document list
- the next posting as a TC document will include this issue.
The list editor's working copy, which will normally include an issue
when it is announced, is available at this
Issue - R18 - Uniqueness of WSDL Faults
Date added: 10 Oct 2006
Date submitted: 10 October 2006
Submitter: Danny van der
Description: 1) Assume I have a WSDL portType that looks like
input element = "a:b"
output element = "a:c"
fault name="fault1" element = "a:fault"
fault name="fault2" element = "a:fault"
Most WSDL transports (e.g. SOAP) do not tranport fault names on the
wire. Usually all that is transmitted is the "a:fault" element, wrapped
in some information that does not include the fault name.
Yet 10.3 states that "This results in a fault identified in
WS-BPEL by a QName formed by the target namespace of the corresponding
port type and the fault name." We have no way of deriving, in this
case, whether we're talking about foo:fault1 or foo:fault2.
Possible resolutions include
2) Can't find in the spec what the QName of a non-declared fault is.
- changing the fault catching behavior to not use fault name, but
its data type
- disallowing WSDLs that use the same element in more than one
fault in an operation. (In the whole WSDL?)
- explicitly specifying rules for inferring fault names. For
example, we could say that "a:fault" will always be turned into
"foo:fault1" and "foo:fault2" will never be inferred.
Changes: 10 Oct 2006 - new issue
To comment on this issue (including whether it should be
accepted), please follow-up to this announcement on the
email@example.com list (replying to this message should
automatically send your message to that list), or ensure
the subject line as you send it starts "Issue - R18 -
[anything]" or is a reply
to such a message. If you want to formally propose a resolution to an
open issue, please start the subject line "Issue - R18 - Proposed
resolution", without any Re: or similar.
To add a new issue, see the issues procedures document