W3C home > Mailing lists > Public > www-voice@w3.org > January to March 2013

revisiting preemption

From: Jim Barnett <Jim.Barnett@genesyslab.com>
Date: Mon, 18 Feb 2013 14:58:07 +0000
To: "www-voice@w3.org" <www-voice@w3.org>
Message-ID: <57A15FAF9E58F841B2B1651FFE16D2810214A7@GENSJZMBX03.msg.int.genesyslab.com>
There seems to be agreement that the existing definition of preemption is vague and confusing.   It can be made precise, but that still may leave it confusing.  This leaves us with three questions:

1.       Do we want another definition of preemption?  The obvious candidate is UML's definition:  two transitions conflict if their exit sets have a non-null intersection. We can tweak the definition based on transition classes/types to have the same semantics, so the real question is:  which definition is easier to understand?

2.       What do we want to do about targetless transitions?  They have an empty exit set, so on the UML definition they don't preempt any transitions and don't preempt any other transitions.  The existing definition (based on transition types/classes) says (in effect) that a targetless transition is preempted by any preceding transition that exits its source state.  This may seem intuitively clear, but it isn't necessary by any means.  The whole point of preemption is to block transition sets that could produce an illegal configuration, and targetless transitions will never do that.   By not preempting targetless transitions, we end up with the largest set of transitions that can be guaranteed not to cause problems.

3.       When we discussed this issue in the past, we decided that preemption is so complicated that it should be defined in a separate place, hence we have 'filterPreempted' as a separate function.  On the other hand, the filtering could be folded  back into the selectTransitions functions, particularly if it is based on the intersection of exitSets.   So we could consider getting rid of filterPreempted as a separate function.  However, if we do this, we have to insert the same conflict/preemption-detecting logic in both selectEventlessTransitions and selectTransitions, so it may be better to keep it factored out into a  separate function.

-          Jim
Received on Monday, 18 February 2013 14:58:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:07:43 UTC