W3C home > Mailing lists > Public > www-voice@w3.org > January to March 2011

Re: [scxml] semantics of nested history in parallel state

From: Jacob Beard <jbeard4@cs.mcgill.ca>
Date: Tue, 1 Mar 2011 17:24:49 -0500
Message-ID: <AANLkTi=5ceQAoqVjynt4RNzrgLFhfXgxtNcD=ZQd6vJ8@mail.gmail.com>
To: Jim Barnett <Jim.Barnett@alcatel-lucent.com>
Cc: www-voice <www-voice@w3.org>
Hi Jim,

Thanks for the quick reply. The modified algorithm works as expected.

Best,

Jake

On Tue, Mar 1, 2011 at 5:08 PM, Jim Barnett
<Jim.Barnett@alcatel-lucent.com> wrote:
> Jacob,
>  We have discovered a bug in the algorithm that is probably involved in
> this case.  The history state should not be passed as 'root' on the
> recursive call to addStatesToEnter.  The new version of the procedure
> keeps the same value of 'root' on the recursive call:
>
> procedure addStatesToEnter(s,root,statesToEnter,statesForDefaultEntry):
>    if isHistoryState(s):
>        if historyValue[s.id]:
>            for s0 in historyValue[s.id]:
>
> addStatesToEnter(s0,root,statesToEnter,statesForDefaultEntry)
>
> This revision will be in the next published version of the spec.  Try it
> out and see if it helps.  If not, please report back to us, and we will
> investigate further.
>
> - Jim
>
> -----Original Message-----
> From: www-voice-request@w3.org [mailto:www-voice-request@w3.org] On
> Behalf Of Jacob Beard
> Sent: Sunday, February 27, 2011 8:11 PM
> To: www-voice
> Subject: [scxml] semantics of nested history in parallel state
>
> Hi,
>
> I'm currently working on an implementation of the SCXML step
> algorithm, and I've run into a situation which is somewhat unclear.
> Please consider the following scenario:
>
> <scxml>
>        <initial>
>                <transition target="A2 B2"/>
>        </initial>
>
>        <parallel id="P">
>                <history id="H" type="deep"/>
>
>                <state id="A" initial="A1">
>                        <state id="A1"/>
>
>                        <state id="A2"/>
>                </state>
>
>                <state id="B" initial="B1">
>                        <state id="B1"/>
>
>                        <state id="B2"/>
>                </state>
>
>                <transition event="e1" target="C"/>
>        </parallel>
>
>        <state id="C">
>                <transition event="e2" target="H"/>
>        </state>
> </scxml>
>
> The state machine starts in basic configuration [A2,B2].
>
> Given event e1, the state machine transitions to C, so the basic
> configuration is [C].
>
> Given event e2, the state machine transitions to H. It has already
> captured the previous configuration [A2,B2]. The step algorithm then
> calls addStatesToEnter with A2 bound to parameter s, and H bound to
> parameter root. A2 is a basic state, so it gets added to current
> statesToEnter. Then, for each ancestor anc of A2, add anc to
> statesToEnter and if anc is a parallel state, any child of anc that
> does not have a descendant on statesToEnter is added to statesToEnter.
> In this case, P is an ancestor of A2, and its child compound state B
> does not yet have a descendant on statesToEnter (B2 has not yet been
> added to statesToEnter, as we have not yet returned from this
> recursive call). So, addStatesToEnter is called with B bound to s, and
> P bound to root. B is a compound state, so B's initial state, B1, will
> be added to statesToEnter.
>
> Later on, we will return from the recursive call, and addStatesToEnter
> will be called for B2. B2 will be added to statesToEnter, and so both
> B1 and B2 will have been added to statesToEnter, which will later on
> cause the statechart to enter an illegal configuration.
>
> It seems I have probably misunderstood the specification, but it's not
> clear how. I would appreciate any advice as to what I might be
> missing.
>
> Thanks,
>
> Jake
>
>
>
> -------------------------------------------------------------------------------------------------------------------
> 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 Tuesday, 1 March 2011 22:25:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 1 March 2011 22:25:47 GMT