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:>
>>> *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:
>>>
>>> Home: <mailto:>
>>>
>>>
>>
>>
>>
>> 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.
>>
>>
>
