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)
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