[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 188 - Dead Path Elimination and Join Conditions
The example is no longer eliminating "Dead *Paths*" but "Dead Activities." That's the problem for me. BTW, the "less pathological" case that I chose to ignore is where all inputs are true, but the joinCondition evaluates to false. That, IMO, also fails the "joinCondition" semantic test, but seems to have a more valid use case, and doesn't tamper with the "Dead Path Elimination" semantic. Danny Yaron Y. Goland wrote: > I gotta admit that I don't see the current state of the spec as being > a bug. I think that the example in the issue is not pathological or > even counter intuitive. Dead path elimination is simply an > optimization that allows one to skip having to execute activities when > one has sufficient information to determine that those activities can > never execute. In the example given in this issue dead path > elimination can clean up second but not third. That seems fine to me. > > I realize I'm quite likely being thick but I reviewed the entire > thread on this issue and I just don't see a problem. > > Yaron > > Tony Fletcher wrote: > >> This issue has been added to the wsbpel issue list with a status of >> "received". The status will be changed to "open" if the TC accepts it >> as identifying a bug in the spec or decides it should be accepted >> specially. Otherwise it will be closed without further consideration >> (but will be marked as "Revisitable") >> >> The issues list is posted as a Technical Committee document to the >> OASIS WSBPEL TC pages >> <http://www.oasis-open.org/apps/org/workgroup/wsbpel> 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 >> <http://www.oasis-open.org/apps/org/workgroup/wsbpel/documents.php> - >> 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 >> <http://www.choreology.com/external/WS_BPEL_issues_list.html>. >> >> >> -------------------------------------------------------------------------------- >> >> >> >> Issue - 188 - Dead Path Elimination and Join Conditions >> >> *Status:* received >> *Date added:* 29 Jan 2005 >> *Categories:* State management >> <file:///C:/Perlscripts/wsbpel_issues30.html#category_state_management> >> *Date submitted:* 27 January 2005 >> *Submitter:* Danny van der Rijn <mailto:dannyv@tibco.com> >> *Description:* This is a question dealing with a pathological >> condition that the spec allows that I think we should disallow. >> Currently, it is legal to have a joinCondition which negates >> dead-path elimination. The simplest way to do this is to have an >> activity with one incoming link and whose joinCondition is >> not($incoming). A more detailed expression of this follows. Apologies >> if the syntax isn't quite right. >> >> <flow suppressJoinFailure="yes"> >> <links> >> <link name="first2second"/> >> <link name="second2third"/> >> </links> >> >> <someActivityname="first"> >> <sources> >> <source linkName="first2second"> >> <transitionCondition> >> false >> </transitionCondition> >> </sources> >> </someActivity> >> >> <someActivityname="second"> >> <sources> >> <source linkName="second2third"> >> </sources> >> <targets> >> <target linkName="first2second"/> >> </targets> >> </someActivity> >> >> <someActivityname="third"> >> <targets> >> <joinCondition> >> not(getLinkStatus("second2third")) >> </joinCondition> >> <target linkName="second2third"/> >> </targets> >> </someActivity> >> </flow> >> >> A flow from first to second to third. The transition from "first" to >> "second" has some condition. If it is false, "second" will not >> evaluate. Yet according to my reading of the spec this merely sets >> the link status of "second2third" to false, which in turn causes >> "third" to execute. >> >> This is in contradiction with my understanding of dead-path elimination. >> >> *Submitter's proposal:* I would prefer to disallow joinConditions >> whose expression does not require a true input in order that the join >> condition evaluate to true. Comments? >> *Links:* Announcement, 29 Jan 2005 >> <http://lists.oasis-open.org/archives/wsbpel/200501/msg00054.html> >> *Changes:* 29 Jan 2005 - new issue >> >> >> >> Best Regards, >> >> Tony/ / >> >> / <http://www.choreology.com/>/ >> >> >> >> Tony Fletcher >> >> Technical Advisor >> Choreology Ltd. >> 68, Lombard Street, London EC3V 9L J UK >> >> Phone: >> >> >> +44 (0) 1473 729537 >> >> Mobile: >> >> >> >> +44 (0) 7801 948219// >> >> Fax: >> >> >> +44 (0) 870 7390077 >> >> Web: >> >> >> >> /www.choreology.com <http://www.choreology.com/>/ >> >> Cohesions™ >> >> Business transaction management software for application coordination >> >> Work: tony.fletcher@choreology.com >> >> Home: amfletcher@iee.org <mailto:amfletcher@iee.org> >> >> > > > 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. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]