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
> < To
> >
> cc
> 26.01.2005 22:23
> 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
>
> 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
>.
>
>
>
>
