[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Issue 188: Dead Path Elimination and Join Conditions
Hello Everybody, Please do not forget that this issue now has a number, even if it has yet to be accepted by the TC. It will help me to keep the issues list up to date on the message tracking if you could use the issue number as for all the other issues. With thanks Tony A M Fletcher Cohesions (TM) Business transaction management software for application coordination www.choreology.com Choreology Ltd., 68 Lombard Street, London EC3V 9LJ UK Tel: +44 (0) 1473 729537 Mobile: +44 (0) 7801 948219 tony.fletcher@choreology.com (Home: amfletcher@iee.org) -----Original Message----- From: Danny van der Rijn [mailto:dannyv@tibco.com] Sent: 31 January 2005 17:27 To: Rania Khalaf Cc: Dieter Koenig1; wsbpel@lists.oasis-open.org Subject: Re: [wsbpel] Dead Path Elimination and Join Conditions 1) It's not a "joinCondition" if it makes sense to use it when there isn't a join - i.e. when there's only one incoming link 2) My proposal is not inconsistent with your statement. It only calls for a (small) restriction on what the expression may express. Rania Khalaf wrote: > isn't it easier for the "lay user" to understand that a join Condition > will evaluate to whatever the expression evaluates to ? > > > Danny van der Rijn wrote: > >> Rania- >> >> What you find confusing was my restatement of my desire in order to >> make it more clear for "lay" users. I was attempting to combine the >> descriptive with the prescriptive. My descriptive statement appears >> to be confusing, so I can go back to my original prescriptive >> statement if you and others find it more acceptable. (This is why I >> like to leave the wordsmithing to the editors...) >> >> An explicit join condition MUST NOT evaluate to false in the case >> where the status each incoming link is false. >> >> Rania Khalaf wrote: >> >>> >>> Hi Danny, >>> >>> The semantics as they are now are consistent for any join condition >>> and any number of links. Why special case to make one have to take >>> into account for each activity the implicit and explicit join >>> condition? Doing so just adds confusion. >>> >>> Regards, >>> Rania >>> >>> >>> >>> >>> >>> Danny van der Rijn wrote: >>> >>>> Right. Change my statement for clarity to the following: >>>> >>>> I would prefer that another statement be in the spec that says that >>>> an explicit join condition MUST NOT evaluate to false in any case >>>> where the implicit join condition /would evaluate/ to true /if it >>>> existed/. >>>> >>>> Thanks >>>> Danny >>>> >>>> Rania Khalaf wrote: >>>> >>>>> Hi Danny, >>>>> >>>>> Each activity has exactly one join condition. So if there is an >>>>> explicit join on an activity, there is no implicit one. >>>>> Regards, >>>>> Rania >>>>> >>>>> Danny van der Rijn wrote: >>>>> >>>>>> I agree that the syntax is straighforward. It appears that we >>>>>> just disagree on the semantics. I would prefer that another >>>>>> statement be in the spec that says that an explicit join >>>>>> condition MUST NOT evaluate to false in any case where the >>>>>> implicit join condition evaluates to true. In other words, it >>>>>> can not be true when all incoming links are false. >>>>>> I think it is ugly to have a construct such as a transition that >>>>>> is meant to express control dependencies, and then allow its use >>>>>> for expressing "anti-dependencies." >>>>>> >>>>>> Danny >>>>>> >>>>>> >>>>>> Dieter Koenig1 wrote: >>>>>> >>>>>>> >>>>>>> Hi Danny, I meant *any* join condition, either implicit or >>>>>>> explicit. >>>>>>> >>>>>>> This applies to *every* activity, either with one or with more >>>>>>> incoming links. This is also how I read the spec: >>>>>>> >>>>>>> "(...) propagating negative link status transitively along >>>>>>> entire paths formed by consecutive links until a join condition >>>>>>> is reached that evaluates to true." >>>>>>> >>>>>>> "Every activity that is the target of a link has an implicit or >>>>>>> explicit "join condition" associated with it. This applies even >>>>>>> when an activity has exactly one incoming link" >>>>>>> >>>>>>> "If the explicit join condition is missing, the implicit >>>>>>> condition requires the status of at least one incoming link to >>>>>>> be positive" >>>>>>> >>>>>>> Maybe I am still missing the point, but with these three >>>>>>> statements in the spec, I see no more room for interpretation. >>>>>>> >>>>>>> Kind Regards >>>>>>> DK >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Danny van >>>>>>> der >>>>>>> Rijn >>>>>>> >>>>>>> <dannyv@tibco.com To >>>>>>> > Dieter >>>>>>> Koenig1/Germany/IBM@IBMDE >>>>>>> >>>>>>> cc 27.01.2005 19:51 >>>>>>> andrew.francis@mail.mcgill.ca, >>>>>>> >>>>>>> wsbpel@lists.oasis-open.org >>>>>>> >>>>>>> Subject Re: [wsbpel] Dead >>>>>>> Path Elimination and Join >>>>>>> Conditions >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Do you mean that DPE always ends at "an explicit join >>>>>>> condition"? Every >>>>>>> activity in a flow has at least an implicit join condition. >>>>>>> While I >>>>>>> agree that an implementation can do what you describe, the >>>>>>> especially >>>>>>> pathological case that I describe doesn't even meet the (implied) >>>>>>> semantics of the word "join," since there is only one control >>>>>>> path. I >>>>>>> am bothered more by the ability to create extremely confusing >>>>>>> semantics >>>>>>> than by any non-implementability. >>>>>>> >>>>>>> Danny >>>>>>> >>>>>>> Dieter Koenig1 wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Formally, I see no problem as DPE always ends at a join >>>>>>>> condition, so the >>>>>>>> effect caused by the "SecondToThird" transition is perfectly >>>>>>>> valid. Maybe >>>>>>>> this is something that should be made more clear in the spec >>>>>>>> language. >>>>>>>> Kind Regards >>>>>>>> DK >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Danny van der >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Rijn >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> <dannyv@tibco.com To >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> > andrew.francis@mail.mcgill.ca >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> cc >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> 26.01.2005 22:23 wsbpel@lists.oasis-open.org >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Subject >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Re: [wsbpel] Dead Path >>>>>>>> Elimination >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> and Join Conditions >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> The contradiction is one of semantics. There can be no "dead >>>>>>>> paths" in >>>>>>>> such a case, since a join condition later in the path can >>>>>>>> "resuscitate" >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> the >>>>>>> >>>>>>> >>>>>>>> path. >>>>>>>> >>>>>>>> The sentinel case you describe can easily be coded differently, >>>>>>>> say as the >>>>>>>> 2nd activity in a sequence, where the first is a flow. After >>>>>>>> the flow >>>>>>>> completes, the sentinel can check conditions. Of course, it >>>>>>>> can't check >>>>>>>> link status, but I don't see that as a huge obstacle. >>>>>>>> >>>>>>>> Danny >>>>>>>> >>>>>>>> andrew.francis@mail.mcgill.ca wrote: >>>>>>>> Hello Danny: >>>>>>>> >>>>>>>> >>>>>>>> This is in contradiction with my understanding of >>>>>>>> dead-path elimination. I would prefer to disallow >>>>>>>> joinConditions whose expression does not require a >>>>>>>> true input in order that the join condition evaluate >>>>>>>> to true. Comments? >>>>>>>> >>>>>>>> >>>>>>>> I do not see how your example contradicts sections >>>>>>>> 12.5.1 (link semantics) or 12.5.2 (dead path elimination)? >>>>>>>> I think your example is strange but not pathological. >>>>>>>> Let us pretend the programmer does not like fault handlers >>>>>>>> and structured the process as a graph with one end activity: >>>>>>>> Third. In turn, the programmer wants activity "Third" to >>>>>>>> be a sentinel or assert of sorts, executing only if activity >>>>>>>> "Second" failed. If my understanding is correct, if "Second" >>>>>>>> executes and sets "secondToThird"'s transitionCode to true, >>>>>>>> Third's joinCondition will evaluate to false, not run, and >>>>>>>> the process is finished: after all nothing bad happened .... >>>>>>>> and this is what the programmer intended. >>>>>>>> Cheers, >>>>>>>> Andrew >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 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. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> >>> > > > 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]