[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Dead Path Elimination and Join Conditions
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]