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: Issue 74 - proposal for vote



to nicely solve the problem of unclear definition of the "joinCondition" in issue 74 I propose for vote to change the syntax of bpel a bit, and Francisco Curbera helped me with the design. We already discussed this on the last call:

changes needed:

A) remove "joinCondition" from the set of Standard attributes for each activity
- remove mentioning and description of joinCondition from 11.1 on p. 53
- remove mentioning of joinCondition="bool-expre"? from the formal description in 11.1
- remove paragraph right above 11.2 (which was the actual text which triggered this issue)

B) change standard elements for each activity

- change formal syntax definition:
<source .../>*
<traget .../>*
  <source linkName="ncname" transitionCondition="bool-expr"?/>+
<targets joinCondition="bool-expr"? >
  <target linkName="ncname"/>+

- add description of "joinCondition" attribute right below (above 11.3) (removed default value, replaced with default semantic):
The value of the joinCondition attribute is a Boolean-valued expression in the expression language indicated for this document (see Expressions). If this attribute is not present, the join condition is the logical OR of the link status of all incoming links of this activity (see 12.5.1 Link semantics).
(this also alignes the semantical definition with 12.5.1 without using the "default value")

- change text of 11.2
Each BPEL4WS activity has optional nested standard elements <source> and <target>. The use...
Each BPEL4WS activity has nested standard elements <source> and <target> within the optional containers <sources> and <targets>. The use...

C) update all samples and schema

I will bring forward the motion to accept A-C by the TC, for the editorial team to apply.

I discussed with Paco, that supressJoinFailure attribute (at least in the current definition) cannot be moved to <sources> element, because it is also an inherited meaning of a structured activity with no incoming links. 
A solution to that would be to define two different attributes, one present at <sources> and one present as default attribute for container activities. But before I think about that, I will open a new issue for this, please do not reply in this thread! 

We have introduced the sources container element anyway, for syntactical symmetry reasons.

Mit freundlichen Grüßen
Bernd Eckenfels
Chief Architect
SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany
Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256
mailto:b.eckenfels@seeburger.de - http://www.seeburger.de

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