Re: [wsbpel] Issue 70 - Proposal to vote

[Alex Yiu <alex.yiu@oracle.com>]

Hi, all,

Actually, after doing a search on "suppressJoinFailure", there are some old parts of the spec need to be changed also. We may need to amend issue 70 in a way:

(1)
To remove / change the wrong description default value of suppressJoinFailure attribute of an activity from section 6.2:

Existing Text:
-----------------------------

where the default values are as follows:

• name. No default value (that is, unnamed)

• joinCondition. The logical OR of the liveness status of all links that are targeted at this activity

• suppressJoinFailure. No

-----------------------------

New Text:

• suppressJoinFailure. In case the suppressJoinFailure attr is omitted for an activity, it is inherited from its closest enclosing activity / BPEL construct.
  

(2)
To remove / change the wrong description from section 11.1 "Standard Attributes for Each Activity":
Existing description:
"The default value of suppressJoinFailure is no."
New description:
"In case the suppressJoinFailure attr is omitted for an activity, it is inherited from its closest enclosing activity / BPEL construct."

(3)
To change the description of Section 12.5.2. "Dead-Path-Elimination (DPE)":
Existing description:
"The default value of the suppressJoinFailure attribute is "no". This is to avoid unexpected behavior in simple use cases where complex graphs are not involved and links without transition conditions are used for synchronization.
New description:
"The default value of the suppressJoinFailure attribute of process element is "no". This is to avoid unexpected behavior in simple use cases where complex graphs are not involved and links without transition conditions are used for synchronization.

(4)
Similar situation for the table in Section 20.2 Appendix for Standard Attrubute


Does it make sense?

Thanks!




Regards,
Alex Yiu



Liu, Kevin wrote:

Propose to close issue 70 based on the solution provided by Jim Clune below.

Best Regards,
Kevin
 

-----Original Message-----
From: ws-bpel issues list editor [mailto:peter.furniss@choreology.com]
Sent: Tuesday, Sep 30, 2003 01:58 AM
To: wsbpel@lists.oasis-open.org
Subject: [wsbpel] Issue - 70 - suppressJoinFailure default value

This issue has been added to the wsbpel issue list. 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 document with the title in the "Issues" folder of the WSBPEL TC document list - the next posting 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 - 70 - suppressJoinFailure default value

Status: open
Date added: 30 Sep 2003
Submitter: Jim Clune
Date submitted: 26 September 2003
Description: The XML schema in the appendix of the BPEL 1.1 spec declares a default value of "no" for the suppressJoinFailure attribute in tActivity and tProcess complexType declarations. This makes sense for tProcess, as it establishes a default to be used until overridden. For tActivity, however, I think that specifying a default value contradicts this statement in section 12.5.2:

A value of "yes" for [suppressJoinFailure] has the effect of suppressing the bpws:joinFailure fault for the activity and all nested activities, except where the effect is overridden by using the suppressJoinFailure attribute with a value of "no" in a nested activity.

By having the schema specify a default value for suppressJoinFailure for each activity element, nested activities always reset the value of suppressJoinFailure instead of inheriting it.
Submitter's proposal: If I am reading this wrong, perhaps someone can clarify. Otherwise, I propose, in the schema's tActivity declaration, replacing this:

<attribute name="suppressJoinFailure" type="bpws:tBoolean" default="no"/>
  

with this:

<attribute name="suppressJoinFailure" type="bpws:tBoolean" use="optional"/>
  

Changes: 30 Sep 2003 - new issue