RE: [scxml] semantics of nested history in parallel state ISSUE-773

Johan,

We have discussed the issue and decided that the underlying problem is that s2 should not be exited in your example.  Parallel siblings are exited only if the parent parallel element is exited, and p is not exited in this case (since the LCA is never exited.)  To fix this, we think we need to modify exitStates so that parallel and compound LCAs are treated differently.  Currently we exit all the descendents of the LCA.  This is correct in the case where ancestor is a compound state (as long as we take isDescendant to mean is proper descendant).  However it is incorrect if ancestor is a parallel state.  In that case we do not want to exit all its children, but only the one that is the source or target of the transition.  (We don’t allow transitions between parallel siblings, so if p is the LCA, it must be because one of its children either is the source and contains the target of the transition, or vice versa).   I don’t know what the correct syntax is, but we want something like:

 

if t.target:

           if t.type == "internal" and getTargetStates(t.target).every(lambda s: isDescendant(s,t.source)):

               ancestor = t.source

           else:

               ancestor = findLCA([t.source].append(getTargetStates(t.target)))

           if ancestor is a parallel state:

               child = find the child that is the source or target of t

               statesToExit.add(child)

               for s in configuration

                 if isProperDescendant(s,child):

                   statesToExit.add(s)   

            

           else:

             for s in configuration:

               if isProperDescendant(s,ancestor):

                   statesToExit.add(s)   

 

 

 

From: www-voice-request@w3.org [mailto:www-voice-request@w3.org] On Behalf Of Johan Roxendal
Sent: Friday, July 01, 2011 8:07 AM
To: www-voice@w3.org
Subject: Re: [scxml] semantics of nested history in parallel state ISSUE-773

 

Jim,

 

Hm, I did the change to getProperAncestors and that seems to have solved it. and it still passes all of my tests (I have about 85% coverage for the interpreter code, so it shouldn't be considered a definitive answer). I'm gonna roll with this for now.

 

thanks!

 / Johan

 

On Thursday, June 30, 2011 at 21:04 , Jim Barnett wrote:

 Johan,

 Yes, I can see that the algorithm would have this problem  (it wouldn’t if the transition were labeled ‘internal’).  An additional problem is that we don’t define getProperAncestors(state, ancestor) anywhere.  If it is defined as not including ‘ancestor’ in its returned values, this problem definitely occurs (because in this case ‘ancestor’ is parallel state ‘p’).  If the return value does include ‘ancestor’ (‘p’ in this case) then I think that this case will work, but other things may be broken.

  

 -          Jim

  

 From: www-voice-request@w3.org [mailto:www-voice-request@w3.org] On Behalf Of Johan Roxendal
 Sent: Monday, June 27, 2011 11:59 AM
 To: www-voice@w3.org
 Subject: RE: [scxml] semantics of nested history in parallel state

  

 Hey,

  

 So Torbjörn sent me the upcoming algorithm, which I transcribed into PySCXML. There seems to be a problem, I'm afraid (as PySCXML user DairTarg pointed out in the issue tracker):

  

 <scxml version="1.0"

             xmlns="http://www.w3.org/2005/07/scxml" initial="p">

  

     <parallel id="p">

         <state id="s" initial="a">

             <state id="a" />

             <state id="b" />

             <transition event="e" target="b" />

         </state>

         <state id="s2" />

     </parallel>

 </scxml>

  

 The above machine starts out by going to the configuration {p, s, a, s2}, which seems correct. however, when sent the event 'e', it reacts by leaving s and s2 (correctly) and entering s and b (correctly) but not s2. thus we find ourselves in the illegal configuration {p, s, b}. so, that's not good. 

  

 i've tested the same example with the version of the algorithm that used recursivelyAddDefaultDescendants, but same result there. It could still, of course, be the result of a transcription error (i've gone over the transcription several times, but it's hard to be sure).

  

 regards,

 johan

  

  

 
 CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities. 

 


     
-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.