- From: David Junger <tffy@free.fr>
- Date: Thu, 7 Feb 2013 08:17:58 +0100
- To: "VBWG Public (www-voice@w3.org)" <www-voice@w3.org>
Le 6 feb 2013 à 23:26, Gavin Kistner a écrit : > A colleague of mine created a pathological preemption case to show problems with the current system. Consider: > > <scxml xmlns="http://www.w3.org/2005/07/scxml" version="1.0"> > <parallel id="p0"> > <onentry><raise event="e"/></onentry> > <state id="s0"> > <parallel id="p1"> > <state id='p1s0'><transition event='e' target='s0a'/></state> > <state id='p1s1'><transition event='e' target='s0b'/></state> > </parallel> > <state id="s0a"/> > <state id="s0b"/> > </state> > </parallel> > </scxml> > > The event 'e' causes both transitions to be chosen by selectTransitions(). Both are 'type 2' transitions, and so the logic in preemptsTransition() causes neither to preempt the another. Both transition targets are entered, and now the state machine is in an invalid configuration where both s0a and s0b are active. > > Is there a simple fix to the preemption logic for this? Or do we need to consider to simpler, more robust solution for determining whether the subgraphs affected by transitions overlap? This may happen because the definition is not precise enough. Both transitions in state p1 are indeed "within a single child of <parallel>" state p0. But they are not Type 2 relative to their closest <parallel> ancestor (p1), which is what should matter. David
Received on Thursday, 7 February 2013 07:18:28 UTC