OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [wsbpel] Issue - R18 - Uniqueness of WSDL Faults

Alex Yiu wrote:

Hi Danny,

Regarding to the suggestion in your first bullet:
  • changing the fault catching behavior to not use fault name, but its data type
I am not sure I follow 100%. But, if my understanding is correct, we have already supported that kind of capabilities:

   <catch faultName="QName"?
      ( faultMessageType="QName" | faultElement="QName" )? >*

<catch faultElement="foo:aFaultElement">
<catch faultMessageType="foo:aFaultMsgType">

What I meant in the first bullet is that <catch faultName="QName"> is not a well-defined option if the fault name can't be readily inferred.  So it would need to be changed somehow, or removed.

Of course, I guess the next question is: is that good enough? and do we need other extra "tools or ropes" suggested in your other bullets?

And, I am not sure I follow your third bullet.

As for the 3rd bullet, I was suggesting that we specify an algorithm for turning transmitted data into a fault QName.  As an example, I was suggesting a lexical first match against the fault elements specified in the WSDL.  Note that I don't have a suggestion for fault types, just elements.  I imagine types would be similar, though.


Alex Yiu

ws-bpel issues list editor wrote:

This issue has been added to the wsbpel issue list with a status of "received". 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 it without further consideration. Otherwise it will remain as "received".

The issues list is posted as a Technical Committee document to the OASIS 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 constant URL.

Issue - R18 - Uniqueness of WSDL Faults

Status: received
Date added: 10 Oct 2006
Date submitted: 10 October 2006
Submitter: Danny van der Rijn
Description: 1) Assume I have a WSDL portType that looks like the following:
portType pT
    operation op
          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

  • 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.
2) Can't find in the spec what the QName of a non-declared fault is.
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 wsbpel@lists.oasis-open.org 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]