On Tue, Mar 1, 2011 at 6:57 PM, Jacob Beard <jbea...@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.akol...@gmail.com> wrote: >> On Sun, Feb 27, 2011 at 11:51 AM, Jacob Beard <jbea...@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/%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. >>> >> <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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
