[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 74 - Ambiguity in join condition definition
That sounds nice and clean. After all, if you don't have any targets on your activity then you can't have a joinCondition which neatly takes care of the whole problem. Would you be willing to write this up as a proposal? > -----Original Message----- > From: Eckenfels. Bernd [mailto:B.Eckenfels@seeburger.de] > Sent: Wednesday, October 29, 2003 11:05 AM > To: wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Issue - 74 - Ambiguity in join condition > definition > > > Hello, > > one idea would be to move the @joinCondition attribute from > activites standard attributes to a new targets element, which > is optional but must ne non-empty: > > <activity> > <targets joinCondition="getLinkStatus(l1) || getLinkStatus(l2)"> > <target linkName="l1" /> > <target linkName="l2" /> > </tragets> > </activity> > > > 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 > > > -----Original Message----- > From: Frank Leymann [mailto:LEY1@de.ibm.com] > Sent: Thursday, October 23, 2003 12:22 PM > To: wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Issue - 74 - Ambiguity in join condition > definition > > > > The issue is that there is a clear distinction between what > is called a > "join condition" and a "start condition". The latter is not > addressed in > BPEL at all. > > The purpose of a join condition is to "join", i.e. synch-up > threads of work > that are going on in parallel. The purpose of a start condition is to > specify under which conditions (causal, temporal,...) an > activity that is > known to be ready to be performed will actually be performed. > > If there is nothing to join or sync-up, a join condition > doesn't make sense > at all. Thus, we should not introduce an artificial join condition for > activities without incoming edges (even if this condition > would so trivial > to handle than a constant TRUE condition). > > Regards, > Frank > > ------------------- > Prof. Dr. Frank Leymann, Distinguished Engineer > IBM Software Group > Member, IBM Academy of Technology > > Phone 1: +49-7031-16 39 98 > Phone 2: +49-7056-96 50 67 > Mobile: +49-172-731 5858 > -------------------- > > > > > > Please respond to <ygoland@bea.com> > > To: Frank Leymann/Germany/IBM@IBMDE, <wsbpel@lists.oasis-open.org> > cc: > Subject: RE: [wsbpel] Issue - 74 - Ambiguity in join condition > definition > > > There are two cases where an activity does not have any > incoming links: > > Case 1 - No Join Condition is Explicitly Defined - This is a > hole. The spec > requires that the join condition be equal to the OR join of > the incoming > links but there are no incoming links so what does it mean to > have an OR > join of nothing? Tri-state logic being more than I want to deal with I > suspect a quick sentence of the form "in the case where an > explicit join > condition is not defined and the activity does not have any > incoming links > the value of the join condition is set to true." > > Case 2 - A Join Condition is Explicitly Defined - In this > case the only > function that can be called is getLinkStatus and that can > only be called on > links that have the activity as their target. By definition of this > scenario > there is no such link therefore any call to getLinkStatus > will produce a > static analysis error (we need to add this to the static > analysis error > list). Therefore the only contents of the Join Condition can > be various > types of fancy Boolean nonsense all based on playing around > with True and > False. While silly, it isn't harmful. > > Therefore I would propose that we pretend that join > conditions exist on all > activities, independent of having any links pointing at them. > In the case > where there are no links and no explicitly defined join > condition we just > a-priori define the join condition to be true. All other > cases seem to take > care of themselves. > > Just a thought, > > Yaron > > > -----Original Message----- > > From: Frank Leymann [mailto:LEY1@de.ibm.com] > > Sent: Tuesday, October 21, 2003 12:50 AM > > To: wsbpel@lists.oasis-open.org > > Subject: RE: [wsbpel] Issue - 74 - Ambiguity in join condition > > definition > > > > > > > > The current spec says: > > > > "If the explicit joinCondition is missing, the implicit > > condition requires > > the status of at least one incoming link to be positive..." > > > > I.e. if you don't specify any explicit join condition the implicit > > condition is the ORing of the truth values of the incoming links. > > > > Furthermore, the current spec says that > > > > "The expression for a join condition for an activity MUST be > > constructed > > using only Boolean operators and the bpws:getLinkStatus > function (see > > Expressions) applied to incoming links at the activity" > > > > I.e. it is NOT possible to spec join conditions that refer to other > > functions than getLinkStatus. > > > > To avoid "mathematical subtleties" that can blow your mind > (statements > > about the empty set...), we need an explicit clarification > > for situations > > where there are no incoming links at all. > > > > Regards, > > Frank > > > > -------------------- > > > > > > > > > > > > Please respond to <ygoland@bea.com> > > > > To: <wsbpel@lists.oasis-open.org> > > cc: > > Subject: RE: [wsbpel] Issue - 74 - Ambiguity in join condition > > definition > > > > > > What is harmed if we allow join conditions on activities that > > don't have > > links? Isn't it already possible to write a join condition > > that doesn't > > refer to any form of link state in calculating its Boolean output? > > Just Curious, > > Yaron > > -----Original Message----- > > From: ws-bpel issues list editor > [mailto:peter.furniss@choreology.com] > Sent: Thursday, October 09, 2003 2:59 PM > To: wsbpel@lists.oasis-open.org > Subject: [wsbpel] Issue - 74 - Ambiguity in join condition definition > > > > 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 - 74 - Ambiguity in join condition definition > > > Status: open > Date added: 9 Oct 2003 > Submitter: Dieter Roller > Date submitted: 09 October 2003 > Description: The specs could possibly be interpreted in such > a way that > activities without an incoming link could also have a join > condition. This > is not the intended meaning. > Submitter's proposal: Modify the first sentence in the > second paragraph in > section 12.5.1 as follows : > Every activity that is the target of a link has an implicit or > explicit joinCondition attribute associated with it; > an activity > that is not target of a link has no joinCondition attribute > associated with it. > Furthermore it may be helpful to have a similar sentence > earlier in the > document. > Changes: 9 Oct 2003 - new issue > > > > To comment on this issue, 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 - 74 - [anything]" or is a > reply to such a > message. > > > To add a new issue, see the issues procedures document (but > the address > for new issue submission is the sender of this announcement). > > > 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/le ave_workgroup . php . 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. 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. 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.
<<attachment: winmail.dat>>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]