Re: My experience and issues implementing an SCXML Interpreter

Concerrning issues 12 and 13 (definition of  preemption), I wonder if the following definition would be clearer:

function preemptsTransition(t1, t2)
Two transitions conflict if their exit sets have a non-null intersection. In the case of such a conflict, we say that the first transition preempts the second. With respect to preemption, there are three classes of transitions: 1) targetless transitions 2) transitions whose source and target are contained within a single child of <parallel> 3) transitions that cross child boundaries (including exiting and reentering a single child) and/or leave the parallel region altogether. Class 1 transitions have an empty exit set and hence do not preempt any other transitions. Class 2 transitions have an exit set that is entirely contained within the child of <parallel>. Hence they do not conflict with other class 2 transitions, but they do preempt subsequent class 3 transitions. Class 3 transitions leave the <parallel> region and all its descendant states. Hence they conflict with all class 2 transitions and all other class 3 transitions.

function preemptsTransition(t1, t2):

       if isClass2(t1) and isClass3(t2): return True

        elif isClass3(t1): return True

        else return False

However, we need to extend this definition or change the function.  The problem is that in the current function definition,  Class 3 transitions preempt Class 1 transitions, even though their exit sets don't intersect (since Class1 transitions have an empty exit set.)  We decided to define things this way because once you've taken a class 3 transition, you may no longer be in the state that contains the class 1 transition, so it would seem odd to take it.  In particular, if someone puts a class 1 transition in state s1, he will naturally assume that the state machine will always be in state1 when the executable content in his transition executes (since the transition doesn't exit state1).  But in the case of parallel states also containing a class3 transition, he could be wrong and that might produce some very odd behavior.  On the other hand, the _order_ in which the transitions are taken is not defined, either by Harel or UML, so it is not inconsistent to say that class 1 transitions fire even if they are preceded by class 3 transitions.

Another possibility would be to define preemption by saying that two transitions conflict if one exits the others source state.  But that is not what UML says, and we try to remain consistent with it.