Re: SCXML entry order

Hi,

First of all thanks for your answer.

I have another question... if a State has on entry and on exit elements...
and this elements  have executable content so could make an invoke... why
do the state has the invoke element apart?

>From my point of view this invoke is redundant and it doesn't specify when
you should call it (you have to check the algorithm), to it shouldn't be a
children of a state (just a children of on entry or on exit element).

Regards,
Carlos Verdes.

On 30 November 2011 21:31, Jim Barnett <Jim.Barnett@alcatel-lucent.com>wrote:

> Carlos,
>  Those are both good questions.  The current spec is vague on both points.
> We will discuss this in the group and let you know what we decide.
>
> - Jim Barnett
>
>
> -----Original Message-----
> From: Carlos Verdes [mailto:cverdes@gmail.com]
> Sent: Tue 11/29/2011 6:53 PM
> To: Jim Barnett; www-voice@w3.org
> Subject: SCXML entry order
>
> 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.
>
>
>
>
> -------------------------------------------------------------------------------------------------------------------
> CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain
> confidential and proprietary information of Alcatel-Lucent and/or its
> affiliated entities. Access by the intended recipient only is authorized.
> Any liability arising from any party acting, or refraining from acting, on
> any information contained in this e-mail is hereby excluded. If you are not
> the intended recipient, please notify the sender immediately, destroy the
> original transmission and its attachments and do not disclose the contents
> to any other person, use it for any purpose, or store or copy the
> information in any medium. Copyright in this e-mail and any attachments
> belongs to Alcatel-Lucent and/or its affiliated entities.
>
>