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/%3cce1f2ea81001131340w2aaaf5bfs84b9db2252287...@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.
I'd appreciate any guidance you can offer. Thanks,
Jake
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
