OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] Dead Path Elimination and Join Conditions


1) It's not a "joinCondition" if it makes sense to use it when there 
isn't a join - i.e. when there's only one incoming link
2) My proposal is not inconsistent with your statement.  It only calls 
for a (small) restriction on what the expression may express.

Rania Khalaf wrote:

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