[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

Received on Monday, 28 February 2011 01:12:17 UTC