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 Wed, 02 Mar 2011 00:00:32 GMT
On Tue, Mar 1, 2011 at 6:57 PM, Jacob Beard <jbeard4@cs.mcgill.ca> wrote:
> Please keep an eye on the www-voice thread. I think there may still be
> problems with the current step algorithm, and I'm drafting a reply to
> elaborate on this.
>
<snip/>

Sure.

-Rahul


> Thanks,
>
> Jake
>
> On Tue, Mar 1, 2011 at 6:50 PM, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
>> 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