Re: Workunit blocking - an alternative that addresses both sets of required semantics

I must confess to a certain amount of surprise at the change in 
semantics and to the groups decision to adopt them with little thought 
as to the impact of such a change.

If you step back the change itself it really means that "false" has no 
meaning to a blocking workunit with a guard. The guard now becomes a 
constraint and not a condition. The timeout then becomes a consequence 
of a constraint having failed. Calling it a condition serves only to 
confuse the situation and leaves me feeling somewhat concerned that a 
"work-unit" is an ill thought out conglomeration of functions. Tidying 
this up, as per Gary's suggestion, would at least ensure that they are 
more "user friendly" and make it easier to implement and use.

Just my tuppence worth although in this case it feels more like 10 
pounds-worth.

Cheers

Steve T

On 7 Dec 2004, at 08:51, Gary Brown wrote:

> Therefore we just add to the list of possible constraints........
>  
> For example,
>  
>
> If the attribute block is set to "true", then the condition will be 
> examined to determine if it satisfies the necessary constraints for it 
> to be evaluated. If the constraints are not satisfied, then the 
> workunit will suspend pending all of the constraints being satisfied. 
> These constraints define that:
>
> * all the variables referenced in the condition must be available,
>
> * any 'variablesAligned' function must wait until the specified 
> variables are aligned,
>
> * and any time related functions (i.e. hasDurationPassed and 
> hasDeadlinePassed) must evaluate to true.
>
> When the constraints have been satisfied, the guard condition will be 
> evaluated. If the result is "true", then the Work Unit is matched, 
> otherwise the Work Unit is disabled.
>  
> This is more preferrable than subverting the semantics of a 
> "condition" to actually mean "blockUntil". This is not intuitive.
>  
> With my suggested approach above, it means that both our requirements 
> are satisfied - I cannot understand why you would object to this 
> solution, as it will make it simplier for a CDL user.
>  
> Regards
> Gary
>  
> ----- Original Message -----
>  From: Nickolas Kavantzas
> To: Gary Brown ; public-ws-chor@w3.org
> Sent: Monday, December 06, 2004 9:19 PM
> Subject: Re: Workunit blocking - an alternative that addresses both 
> sets of required semantics
>
> The way the 'hasDuration/DeadlinePassed' functions would work with a 
> WU with block=true
> were given by me as an example that demonstrates the existing 
> semantics of WU with block=true.
>   
> As another example look at the variablesAligned() function text and 
> also look at the example (c) in
> the WorkUnit section that uses this function with a WU having 
> block=true.
>  
> --
> Nick
> ----- Original Message -----
>  From: Gary Brown
> To: public-ws-chor@w3.org
> Sent: Monday, December 06, 2004 12:12 PM
> Subject: Workunit blocking - an alternative that addresses both sets 
> of required semantics
>
>  
> Based on the discussion on tonight's conference call, I believe the 
> only reason that was given for needing the additional "or the guard 
> condition evaluates to "false" " text, was to cater for the 
> 'hasDuration/DeadlinePassed' functions.
>  
> If this is the case, then I believe that these functions should be 
> treated in the same way as variables are within the following text - 
> i.e. the blocking semantics should be specified explicitly in respect 
> of those concepts. This would mean that it would not be necessary to 
> apply the blocking semantics to all conditions that may evaluate to 
> false, but only those that contain one of the duration/deadline 
> functions. 
>  
> Therefore I propose changing the text from:
>
>
> If the attribute block  is set to "true" and one or more required 
> Variable(s) are not available or the guard condition evaluates to 
> "false", then the Work Unit MUST block. When the required Variable 
> information specified by the guard condition become available and the 
> guard condition evaluates to "true", then the Work Unit is matched.
>
> to:
>
>
>
> If the attribute block  is set to "true", then the condition will be 
> examined to determine if it satisfies the necessary constraints for it 
> to be evaluated. If the constraints are not satisfied, then the 
> workunit will suspend pending all of the constraints being satisfied. 
> These constraints define that all the variables referenced in the 
> condition must be available, and any time related functions (i.e. 
> hasDurationPassed and hasDeadlinePassed) must evaluate to true. When 
> the constraints have been satisfied, the guard condition will be 
> evaluated. If the result is "true", then the Work Unit is matched, 
> otherwise the Work Unit is disabled.
>
>  
>
> Regards
>
> Gary

Received on Tuesday, 7 December 2004 15:04:15 UTC