Hi
Alex,
Thanks
for looking into the spec text. this is very helpful.
I
would suggest that we amend the initial proposal to include the additional
changes.
Best Regards, Kevin
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
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 valueStatus:
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
To
unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
|