W3C home > Mailing lists > Public > public-ws-chor@w3.org > December 2004

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

From: Gary Brown <gary@enigmatec.net>
Date: Mon, 6 Dec 2004 20:12:24 -0000
Message-ID: <001201c4dbcf$ead86560$0200a8c0@LATTITUDEGary>
To: <public-ws-chor@w3.org>

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.


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.


Received on Monday, 6 December 2004 20:12:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:29 UTC