[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
If most people thought that the current behavior needs no change, then I was going to propose that wording be added to explicitly allow joinConditions to evaluate to true when all inputs are false, and vice versa. Danny Yaron Y. Goland wrote: > If you feel like doing the work to re-edit the text into something a > little less confusing I wouldn't have any objections. > Yaron > > Danny van der Rijn wrote: > >> Every time I read the following paragraph, my feeling is reinforced. >> The only time that I would expect a join condition to evaluate to true >> (last sentence) is when an incoming link is true. Yes, I am reading >> more into those words than exist. Yet I still say that this is >> unclear. The title of the section is about paths, which would make no >> sense otherwise. However, I raised this point initially to gauge >> reactions, not to change opinions. If the opinions are against me, I >> can accept that. I guess we'll find out at the call. >> >> Danny >> >> >> 12.5.2. Dead-Path-Elimination (DPE) >> >> In cases where the control flow is largely defined by networks of links, >> the normal >> interpretation of a false join condition for activity A is that A should >> not be performed, >> rather than that a fault has occurred. Moreover, there is a need to >> propagate the >> consequences of this decision by assigning a negative status to the >> outgoing links for A. >> WS-BPEL makes it easy to express these semantics by using an attribute >> suppressJoinFailure on an activity. A value of "yes" for this attribute >> 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. Suppressing the bpws:joinFailure is >> equivalent to the fault >> being logically caught by a special default handler attached to an >> implicit scope that >> immediately encloses just the activity with the join condition. The >> default handler >> behavior is an empty activity, that is, the handler suppresses the fault >> and does nothing >> about it. However, because the activity with the join condition was not >> performed, its >> outgoing links are automatically assigned a negative status according to >> the rules of Link >> Semantics. Thus within an activity with the value of the >> suppressJoinFailure attribute >> set to "yes", the semantics of a join condition that evaluates to false >> are to skip the >> associated activity and to set the status of all outgoing links from >> that activity to negative. >> This is called dead-pathelimination because in a graph-like >> interpretation of networks of >> links with transition conditions, these semantics have the effect of >> propagating negative >> link status transitively along entire paths formed by consecutive links >> until a join >> condition is reached that evaluates to true. >> >> Yaron Y. Goland wrote: >> >> > Since the algorithm is an optimization (e.g. BPEL can run just fine, >> > if slower, without it) and since it is not something that users >> should >> > need be aware of I don't see a compelling case for changing the >> > terminology. But I'm always open to a good argument. >> > >> > Yaron >> > >> > Ron Ten-Hove wrote: >> > >> >> The problem may lie with interpretion of the phrase "dead-path >> >> elimination", especially the term "path". This implies that >> something >> >> pathlike is being eliminated. I for one think of paths in graphs as >> >> usually having more than one node, which isn't really how DPE works. >> >> The example shows that DPE is more accurately termed "dead activity >> >> elimination," although more conventional use of links does indeed >> >> lead to something pathlike being eliminated. >> >> >> >> Is the above holds true, then the question is, is the phrase >> >> "dead-path elimination" so misleading that we should change it? >> >> >> >> -Ron >> >> >> >> 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. >> >> >>> >> >>> >> >> >> > >> > 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]