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

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