RE: proposed new definition of preemption

+1 for me for transition order (which works out to document order of the atomic states) rather than straight document order.

I think for all these descriptions it would be useful to have sample SCXML documents to make sure everyone is on the same page.

For instance, in the following little state machine, if after we enter the state machine we get the event e, I'd expect we end up in next without ending up in s2b.  That follows transition order, but not document order.  If you move the transition that is a child of top to above p, you'd still end up in the same place.

<scxml initial="p">
  <state id="top" initial="p">
    <parallel id="p">
      <state id="s1" initial="s1a">
         <state id="s1a"/>
     </state>
      <state id="s2" initial="s2a">
        <state id="s2a">
          <transition event="e" target="s2b"/>
        </state>
        <state id="s2b">
          <onentry><log expr="'should not be here"'/></onentry>
        </state>
      </state>
    </parallel>
    <state id="next"/>
    <transition event="e" target="next"/>
  </state>
</scxml>

From: Jim Barnett [mailto:Jim.Barnett@genesyslab.com]
Sent: Tuesday, February 26, 2013 5:40 AM
To: David Junger; VBWG Public (www-voice@w3.org)
Subject: RE: proposed new definition of preemption

David,
For your first point, using 'transition order' amounts to using document order of the _states_ that selected the transitions, not the transitions themselves.  I agree that may be clearer.  All we have to do with the existing definition is call enabledTransitions.toList(), which will sort  them in the order in which the items were added, which is the order of the selecting states.  (By the way, the definition I sent around is wrong, in that it doesn't sort them in any order.)

On your third point, I think that you are right that targeted transitions will conflict if one's source state is a descendent of the other's, but that is not the only condition under which they conflict.  Consider a parallel element P with children S1, S2, and put transitions in S1, S2 that both exit P and go to different remote states (i.e., ones that cannot be simultaneously active).  The transitions in S1, S2 conflict, but neither's source state is a descendent of the other's.  However, I agree that practical implementations will not want to compute exit sets.


-          Jim

From: David Junger [mailto:tffy@free.fr]
Sent: Tuesday, February 26, 2013 4:18 AM
To: VBWG Public (www-voice@w3.org<mailto:www-voice@w3.org>)
Subject: Re: proposed new definition of preemption

Le 25 feb 2013 à 16:53, Jim Barnett a écrit :

First, I think we should preempt in transition order, not document order (i.e. a transition should be preempted by transitions that are selected before it, not witten before it). If we use document order, then we'll end up with <state>s and <transition>s mixed in complex states to achieve a precise result, very hard to read or visualize.
q
3.       Is it a good idea to get rid of the word "preemption"?  (the selectTransitions functions have to be modified to call removeConflictingTransitions instead of filterPreempted, but the argument to the functions and the return values are the same.  hasIntersection() und union() are defined in the list of functions/procedures at the top of the algorithm)

I don't mind the word. I just hoped we could find an elegant solution that made it unnecessary.

4.       Is there a better way to do this?

It seems that targeted transitions will always conflict if one's source state is a descendant of the other's and that those cases are precisely the cases that trip the source state approach. Is that correct? I don't think that would be a "better" way to explain it in the spec but if it is equivalent then I like it better for my implementation (in which I don't want to compile exit sets in advance, for example).

                                    David