Re: preemption again (sigh...)

I doubt there is a way you could come up with something where all of the
examples have completely intuitive results.  I agree with the analysis.

IF you always wanted transitions in children to have descendants over
transitions in ancestors then that is fine but it is somewhat (or perhaps)
a lot harder to implement than the current algorithm.  It also precludes
short circuiting the transition selection algorithm, something that I can
in favor of.

Going back to the definition I gave a while time ago where you looked at
preemption based on if a transition arena is the child of another arena you
could have an efficient algorithm to allow exactly what UML suggests,
allowing descendents to take precedence.  You would just always take the
descendent of order of the transitions in the document.  The problem is
that a later transition could preempt an earlier one and thus you would
have to produce essentially a new transition list on every transition
instead of just appending to the transition list.

In any case, this could be a potentially large discrepancy from the UML
specification.  Which would only manifest itself in subtle edge cases.
 Seems troubling.

Chris



On Thu, Feb 28, 2013 at 3:03 PM, Michael Bodell <bodell@247-inc.com> wrote:

>  I personally find the current behavior more intuitive, where the
> transition associated with deeplyNested1 that goes to somewhereFarAway
> “wins” over the transition as part of deeplyNested2.  I think the key thing
> for me is which atomic states you are in at the time, so thinking from that
> perspective makes the current behavior intuitive.****
>
> ** **
>
> *From:* Jim Barnett [mailto:Jim.Barnett@genesyslab.com]
> *Sent:* Thursday, February 28, 2013 1:57 PM
> *To:* VBWG Public (www-voice@w3.org)
> *Subject:* preemption again (sigh...)****
>
> ** **
>
> 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…****
>
>    <parallel>****
>
>       <state id=”deeplyNested1”/>****
>
>       <state id=”deeplyNested2”>****
>
>            <transition event=”e” target=”someWhereElseFarAway”/>****
>
>   </state>****
>
> </parallel>****
>
> …….****
>
> </state>****
>
> ** **
>
> 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.  ****
>



-- 
A foolish consistency is the hobgoblin of little minds - Emerson