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
>>>>>>
>>>>>> < 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.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
