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

preemption again (sigh...)

From: Jim Barnett <Jim.Barnett@genesyslab.com>
Date: Thu, 28 Feb 2013 21:56:54 +0000
To: "VBWG Public (www-voice@w3.org)" <www-voice@w3.org>
Message-ID: <57A15FAF9E58F841B2B1651FFE16D281023BBE@GENSJZMBX03.msg.int.genesyslab.com>
Johan points out that the currently proposed definition of preemption (and the one in the current spec) have a counter-intuitive result, which is that transitions placed very high in the state machine can preempt ones in atomic states.  Consider the following case:

<state id="s1">
<transition event="e" target="someWhereFarAway">
    ... imagine a bunch of nested states here with no transitions that handle e...
      <state id="deeplyNested1"/>
      <state id="deeplyNested2">
           <transition event="e" target="someWhereElseFarAway"/>

If we are within the parallel region when e occurs, then state deeplyNested1 will select the transition that is a child of s1 while deeplyNested2 will select the transition that is contained inside it.   These two transitions will conflict.  In our current definition, the one chosen by deeplyNested1 will win, since that state comes first in document order.   Johan finds this counterintuitive since that transition is located much higher up in the state machine than the one in deeplyNested2.  (In fact, its source state is an ancestor of deeplyNested2).    Johan argues that this will make the behavior of complex state machines hard to understand.

So, my question is:  do other people find this behavior odd or confusing?  Do we want to try to tweak the definition so that the transition in deeplyNested2 would win?  (It may take a pretty big tweak...)

-          Jim

P.S.  I've looked at UML 2 and find its explanation extremely vague.  It does define clearly conflict in terms of intersecting exit sets.  It also says that transitions inside descendents take precedence over transitions in ancestors, but the rest of the discussion is so confusing that I'm not sure what algorithm they really suggest.
Received on Thursday, 28 February 2013 21:57:22 UTC

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