commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <rahul.akol...@gmail.com>
Subject Re: [scxml] semantics of nested history in parallel state
Date Tue, 01 Mar 2011 23:50:47 GMT
On Sun, Feb 27, 2011 at 11:51 AM, Jacob Beard <jbeard4@cs.mcgill.ca> wrote:
> Hi,
>
> I'm currently working on revising scxml-js so that it implements the
> semantics defined by the step algorithm of the SCXML specification (as
> opposed to the mixture of SCXML semantics and Rhapsody semantics which
> it currently implements). I've run into a part of the step algorithm
> which is somewhat unclear, and because it may relate to a limitation
> in the Commons SCXML implementation, I thought I would ask about this
> on the Commons SCXML list before asking about it on the w3-voice list.
>
> Consider the following SCXML document:
>
> <scxml initial="p">
>
>        <parallel id="p">
>
>                <history id="h">
>                        <transition target="A.2 B.2"/>
>                </history>
>
>                <state id="A" initial="A.1">
>                        <state id="A.1"/>
>                        <state id="A.2"/>
>                </state>
>
>                <state id="B">
>                        <state id="B.1"/>
>                        <state id="B.2"/>
>                </state>
>
>        </parallel>
>
> </scxml>
>
> (https://gist.github.com/846316)
>
>
> I believe the step algorithm in the SCXML specification would
> interpret the document in the following way:
>
> addStatesToEnter would at some point be called for parallel state p.
> addStatesToEnter would then be called recursively for each of p's
> children: h, A, B.
>
> addStatesToEnter would first be called for h. Because this is the
> first time h was entered, addStatesToEnter will be recursively called
> for each of the targets of its default transition: A.2 and B.2. A.2
> and B.2 will then be added to statesToEnter.
>
> addStatesToEnter would then be called for state A. A  is a compound
> state, so addStatesToEnter would then be called for A's initial state:
> A.1. A.1 would then be added to statesToEnter.
>
> The same would occur for B, and so B.1 would be added to statesToEnter.
>
> The resulting configuration would then be: p,h,A,B,A.1,A.2,B.1,B.2,
> which is not a legal configuration, as A and B are both OR states.
>
>
>
> Is my interpretation of the specification correct, in that the step
> algorithm would allow this illegal configuration, or am I missing
> something?
>
>
>
> I'm asking this question here, rather than on the w3-voice list,
> because I believe Commons SCXML does not currently support history in
> parallel: http://mail-archives.apache.org/mod_mbox/commons-user/201001.mbox/%3Cce1f2ea81001131340w2aaaf5bfs84b9db22522877d7@mail.gmail.com%3E
>
> It's not clear whether this is due to possible conflicts in SCXML
> semantics, or whether this is simply Commons SCXML implementation
> lagging a bit behind changes in the specification.
>
<snip/>

Its lag. I believe you have your answer on w3-voice, if not, let me
know and I'll look further.

-Rahul


> I'd appreciate any guidance you can offer. Thanks,
>
> Jake
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message