Re: [wsbpel] Issue - 188 - Dead Path Elimination and Join Conditions

["Yaron Y. Goland" <ygoland@bea.com>]

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>
> 
>