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

ISSUE-826 Re: More Problems with Preemption

From: Jim Barnett <Jim.Barnett@genesyslab.com>
Date: Fri, 8 Feb 2013 14:34:26 +0000
To: "www-voice@w3.org" <www-voice@w3.org>
Message-ID: <57A15FAF9E58F841B2B1651FFE16D28101F7B5@GENSJZMBX03.msg.int.genesyslab.com>
Your basic idea is correct - transitions conflict if their state subgraphs conflict.  The specific definition we use is taken from the UML spec.   Two transitions conflict if their exit sets have a non-null intersection.  I wrote the preemption algorithm in its current form because I found it hard to visualize the intersection of the exit sets, and found it much easier  to think in terms of the three classes of transitions.  But it's becoming clear to me that not everyone finds that clear.  Perhaps the best thing to do is to rewrite filterPreempted roughly as follows:

function filterPreempted(enabledTransitions)
Filter out any transition in enabledTransitions that is preempted by a transition that precedes it in enabledTransitions. Two transitions conflict if their exitSets have a non-null intersection.  In that case, we take the first transition in document order and say that it preempts the second.
function filterPreempted(enabledTransitions):
    filteredTransitions = new OrderedSet()
    totalExitSet = new Set()
    for t in enabledTransitions.sort(documentorder):
        if (t.getExitSet().intersection(totalExitSet).IsEmpty())
            totalExitSet = totalExitSet.union(t.getExitSet())
    return filteredTransitions

The syntax needs work here (we need to define Set, union, intersection, getExitSet), but if people think this is clearer, we can use this instead.  The definition using transition classes is intended to give the same result as this.

-          Jim
Received on Friday, 8 February 2013 14:34:52 UTC

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