RE: SCXML entry order

If I interprets ancestors before I should do like:
P-->S1-->S2-->S3-->S11-->S21--S31

I do not se reason why you SHOULD do this. S2 is NOT ancestor of S11 nor S31, and S3 is NOT ancestor of S11 and S21. Therefore document order is used to break the tie as specified in description of entryOrder which is then P, S1, S11, S2, S21, S3, S31.

Ales

________________________________
From: Carlos Verdes [mailto:cverdes@gmail.com]
Sent: Wednesday, November 30, 2011 12:59 AM
To: DOLECEK Ales
Subject: Fwd: SCXML entry order

While you were answering me I was sending this question... lets see the last scenario please.

---------- Forwarded message ----------
From: Carlos Verdes <cverdes@gmail.com<mailto:cverdes@gmail.com>>
Date: 29 November 2011 23:53
Subject: SCXML entry order
To: Jim Barnett <Jim.Barnett@alcatel-lucent.com<mailto:Jim.Barnett@alcatel-lucent.com>>, www-voice@w3.org<mailto:www-voice@w3.org>


Hi Jim,

I'm trying to implement SCXML in Java, and is crazy that I started with this because I used to work for CSC with people from Alcatel and their state machine oriented platform for intelligent networking.

Now I have a simple question about entry order I hope you could answer.

If we have the state machine:
<parallel id="P">
    <state id="S1">
        <state id="S11"/>
        <state id="S12"/>
    </state>
    <state id="S2">
        <state id="S21"/>
        <state id="S22"/>
         <transition event="e" target="S22" />
    </state>
    <state id="S3">
        <state id="S31"/>
        <state id="S32"/>
    </state>
      <transition event="e" target="S32" type="internal"/>
</parallel>

Which should be the entry order?

If I interprets ancestors before I should do like:
P-->S1-->S2-->S3-->S11-->S21--S31

But for me it has more sense:
P-->S1-->S11-->S2-->S21-->S3-->S31

Which is the same as document order... which is the proper one?


And I have another question about this part of the algorithm
procedure enterStates(enabledTransitions)
....

for s in statesToEnter:
        statesToInvoke.add(s)

statesToEnter = statesToEnter.toList().sort(enterOrder)

When we add states in statesToInvoke we are not following any concrete order, however statesToEnter is an ordered set.
Should be this order the document order, or insertion order in states to enter?

To put an example with the previous configuration [P,S1,S11,S2,S21,S3,S31], event e occur:
---------------------
atomicStates [S11,S21,S31]
S11 has no transition, go to parent S1, no transitions, parent P enables transition P-->S32
S2 enables transition S2-->S21
enabledTransitions[P-->S32, S2-->S21]

---------------------
transition1: P-->S32 internal
ancestor-->P (t.source)
statesToEnter [S32]

getProperAncestors(S32) -->[S3]
statesToEnter[S32,S3]

S3 is not parallel --> next transition

---------------------
transition 2: S2-->S21
ancestor --> P (LCA)
statesToEnter[S32,S3,S21,S2]

-----------------------------------
And do for s in statesToEnter:

        statesToInvoke.add(s)

statesToEnter = statesToEnter.toList().sort(enterOrder)

So
statesToInvoke[S32,S3,S21,S2]
statesToEnter[S2,S3,S21,S22] or [S2,S21,S3,S31]



Could you please give me some light on this scenario please?

Regards,
Carlos Verdes.