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
>> < To
>> > Dieter Koenig1/Germany/IBM@IBMDE
>> cc
>> 27.01.2005 19:51 ,
>>
>> 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
>>>
>>>
>>
>>
>>
>>> < 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
>>>
>>>
>>
>>
>>
>>>.
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>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.
