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