[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> >>> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]