This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Back to bug 913
| Who | When | What | Removed | Added |
|---|---|---|---|---|
| gritzinger | 2004-10-22 14:58:29 UTC | Component | Spec: Coord and alignment | Primer |
| martin.chapman | 2004-12-01 16:27:43 UTC | Status | NEW | RESOLVED |
| Resolution | --- | WONTFIX | ||
| Summary | Clarification on workunit guard projection I understand the role of the globalizedTrigger, to provide a guard condition for each role that is relevant to a work unit. However, if a work unit does not use a globalizedTrigger and the guard condition is related to just one of the roles involved in a workunit, then does this mean that the condition at the other roles is non-observable? In which case does it have to determine what the first observable action of the workunit would be, and monitor for it to determine dynamically if the workunit should be activated at that role? This would mean that additional validation would be required to ensure that the first observable activity (an interaction) was initiated from the role that was associated with the guard condition. If this is true, then I think we need to add an additional rule covering this situation, within the workunit section of the spec. | Clarification on workunit guard projectionI understand the role of the globalizedTrigger, to provide a guard condition for each role that is relevant to a work unit.However, if a work unit does not use a globalizedTrigger and the guard condition is related to just one of the roles involved in a workunit, then does this mean that the condition at the other roles is non-observable?In which case does it have to determine what the first observable action of the workunit would be, and monitor for it to determine dynamically if the workunit should be activated at that role? This would mean that additional validation would be required to ensure that the first observable activity (an interaction) was initiated from the role that was associated with the guard condition.If this is true, then I think we need to add an additional rule covering this situation, within the workunit section of the spec. |
Back to bug 913