RE: Are targetless transitions on an ancestor always preempted?

Gavin,
OK, that makes sense.  I'll make those changes.


-          Jim

From: Gavin Kistner [mailto:phrogz@me.com]
Sent: Thursday, October 30, 2014 8:47 AM
To: Jim Barnett
Cc: www-voice@w3.org (www-voice@w3.org)
Subject: Re: Are targetless transitions on an ancestor always preempted?

I was suggesting changing this:

A transition T is enabled by named event E in atomic state S if a) T's source state is S or an ancestor of S, b) T matches E's name (see 3.12.1 Event Descriptors) c) T lacks a 'cond' attribute or its 'cond' attribute evaluates to "true". A transition is enabled by NULL in atomic state S if a) T lacks an 'event' attribute b) T's source state is S or an ancestor of S c) T lacks an 'cond' attribute or its 'cond' attribute evaluates to "true".

to this:

A transition T is enabled by named event E in atomic state S if a) T's source state is S or an ancestor of S, b) T matches E's name (see 3.12.1 Event Descriptors), and c) T lacks a 'cond' attribute or its 'cond' attribute evaluates to "true". A transition is enabled by NULL in atomic state S if a) T lacks an 'event' attribute, b) T's source state is S or an ancestor of S, and c) T lacks an 'cond' attribute or its 'cond' attribute evaluates to "true".

or this:

A transition T is enabled by named event E in atomic state S if a) T's source state is S or an ancestor of S, and b) T matches E's name (see 3.12.1 Event Descriptors), and c) T lacks a 'cond' attribute or its 'cond' attribute evaluates to "true". A transition is enabled by NULL in atomic state S if a) T lacks an 'event' attribute, and b) T's source state is S or an ancestor of S, and c) T lacks an 'cond' attribute or its 'cond' attribute evaluates to "true".

or this:

A transition T is enabled by named event E in atomic state S if the following are all true: a) T's source state is S or an ancestor of S; b) T matches E's name (see 3.12.1 Event Descriptors); c) T lacks a 'cond' attribute or its 'cond' attribute evaluates to "true". A transition is enabled by NULL in atomic state S if the following are all true: a) T lacks an 'event' attribute; b) T's source state is S or an ancestor of S; c) T lacks an 'cond' attribute or its 'cond' attribute evaluates to "true".


IMHO it's ambiguous English as currently written. Consider:
"For me to help you I need a) cookies, b) candy c) cake."
"For me to help you I need a) cookies, b) candy, or c) cake."
"For me to help you I need a) cookies, b) candy, and c) cake."
I'm not trying to be difficult, but I truly read the above definitions and was waiting for the final pair to be joined with "and" or "or" so that I could be sure which was meant.


On Oct 29, 2014, at 2:24 PM, Jim Barnett <1jhbarnett@gmail.com<mailto:1jhbarnett@gmail.com>> wrote:

Gavin,
 Glad the explanation helped.  Would you like to suggest the wording - I'm not sure exactly where you want the "and"s and I doubt that adding them randomly will improve things much.

-  Jim
On 10/29/2014 4:06 PM, Gavin Kistner wrote:

Ha, thank you. I feel better. I had previously been concentrating on the exit-set-intersection, which is why I was focused on targetless. So that didn't hurt my head much.

However, I had not grasped the concept of promoting a non-preempted transition to the active descendant atomic state(s). I see it now in "A transition T is enabled by named event E in atomic state S if a) T's source state is S or an ancestor of S".

So, thanks! That helped.

P.S. I think that the definition I quoted above could use an explicit "and" or two in the first sentence to clearly differentiate it from a possibly ambiguous "or" case.
--
(-, /\ \/ / /\/


On Oct 29, 2014, at 09:33 AM, Jim Barnett <1jhbarnett@gmail.com<mailto:1jhbarnett@gmail.com>> wrote:


Gavin,
 Chear up, we have been collectively confused by this subject for years.

[Q1]  Yes, "foo" is consumed by the transition in state A, so the outer transition (the one in state innerwrap) is not selected.  You are correct that clause c is the relevant item here.  (But note that the whole definition talks about optimal enablement in a specific atomic state.  That will be relevant in the answer to your next question.)

[Q2]  The log message will not occur, because foo is consumed by the transitions in States A1 and A2.  However if there were no transition in A2 the situation would be different.  In that case, the transition in outerwrap would be optimally enabled in atomic state A2 because there's no transition to block it. That is, we pick the optimally enabled transition in _each_ atomic state _independent_ of the other states.  (Now go lie down until your head stops spinning because it's about to get weirder.)  However we must check for potential conflicts between the transitions chosen in the atomic states.  Two transitions conflict if their exit sets intersect.  The transition in outerwrap is a targetless transition, and therefore has no exit set.  Thus it does not conflict with the transition in A1, so both of them will get taken.   (Now go take a stiff drink.)

[Q3] Yes, both states are entered. The two transitions do not conflict since their exit sets do not intersect.

- Jim

On 10/29/2014 10:51 AM, Gavin Kistner wrote:

I still, disturbingly, struggle to gain intuition on  section 3.13 of the spec. Please help me by clarifying:

    <scxml xmlns="http://www.w3.org/2005/07/scxml" version="1.0">
      <state id="innerwrap">
        <transition event="foo"><log label="Should I run?"/></transition>
        <state id="A"><transition event="foo" target="B" type="internal"/></state>
        <state id="B"/>
      </state>
    </scxml>

My intuition tells me that a "foo" event should be 'consumed' by the inner transition and not 'bubble' out. That the outer log message should not run.

[Q1] Is this correct?

It is, I think, confirmed by this text: "Definition: A transition T is optimally enabled by event E in atomic state S if a) T is enabled by E in S and b) no transition that precedes T in document order in T's source state is enabled by E in S and c) no transition is enabled by E in S in any descendant of T's source state."

Part (c) prevents the targetless transition above from executing. Yes?

Now, what about parallel?

    <scxml xmlns="http://www.w3.org/2005/07/scxml" version="1.0">
      <parallel id="outerwrap">
        <transition event="foo"><log label="Should I run?"/></transition>
        <state id="inner1">
          <state id="A1"><transition event="foo" target="B1" type="internal"/></state>
          <state id="B1"/>
        </state>
        <state id="inner2">
          <state id="A2"><transition event="foo" target="B2" type="internal"/></state>
          <state id="B2"/>
        </state>
      </parallel>
    </scxml>

[Q2] If "foo" occurs, should the log message occur?

The same spec above seems to tell me that it should not, as long as the transitions in inner1 or inner2 are present. Even if the transition in inner2 was not present, the fact that any child of the parallel was enabled by it means that the outer targetless transition is preempted per (c).

And finally, for good measure:

[Q3] If "foo" occurs, should both B1 and B2 be entered?

My intuition tells me yes, because that's what parallel is all about, yo. I think this is supported because part (b) of the above quoted definition does not apply. One transition precedes the other in document order, but they are not part of the same hierarchy when we consider the source state of each transition. Correct?

Thanks for your help. :)