commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Beard <>
Subject Re: [scxml] semantics of nested history in parallel state
Date Sun, 27 Feb 2011 17:24:57 GMT

I think I have identified the source of my confusion. I thought that
function getChildStates would also return history states, but I
believe that this interpretation is incorrect, and leads to a number
of conflicts, like the one I already described. I now think that
getChildStates would return child elements of type <state> and

Let me know what you think. Thanks,


On Sun, Feb 27, 2011 at 11:51 AM, Jacob Beard <> 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>
> (
> 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:
> 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.
> I'd appreciate any guidance you can offer. Thanks,
> Jake

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message