W3C home > Mailing lists > Public > www-voice@w3.org > October to December 2011

Re: SCXML entry order

From: Carlos Verdes <cverdes@gmail.com>
Date: Thu, 8 Dec 2011 15:03:57 +0000
Message-ID: <CAMZOHDMJV+kRJ34SuAVmPskUfwZxyygv161oyeS6C=ocVaSWEQ@mail.gmail.com>
To: Jim Barnett <Jim.Barnett@alcatel-lucent.com>
Cc: www-voice@w3.org
That has sense for me either, thanks for your time.

On 8 December 2011 15:02, Jim Barnett <Jim.Barnett@alcatel-lucent.com>wrote:

> Carlos,****
>
>   After discussion within the working group, we would like to clarify that
> entry order is the same as document order.  The order of invocations would
> be the same (so: P-->S1-->*S11*-->S2-->*S21*-->S3-->S31).  ****
>
> ** **
>
> Jim****
>
> *From:* Carlos Verdes [mailto:cverdes@gmail.com]
> *Sent:* Tuesday, November 29, 2011 6:54 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.
>
Received on Thursday, 8 December 2011 15:04:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 8 December 2011 15:04:40 GMT