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

Johan,

 You’re right about isPreempted needing to change.  In your examples, both transitions should be taken when ‘e’ occurs.  IsPreempted blocks a transition t only when an already-selected transition causes the source state of t to be exited.  

 

I’m not sure I understand your proposed change to enterstates, though.  Wouldn’t you just add a test for whether child was already active?

 

-          Jim

 

From: Johan Roxendal [mailto:johan@roxendal.com] 
Sent: Thursday, July 14, 2011 5:55 AM
To: Jim Barnett
Cc: www-voice@w3.org; w3c-voice-wg
Subject: Re: [scxml] semantics of nested history in parallel state ISSUE-773

 

Jim,

 

It seems that further adjustments are needed beyond those suggested for exitstates. 

 

1. although the s2 state in my example is no longer exited, it is caught by enterstates later in the microstep. the relevant lines in the algorithm (lines 15-18 of enterstates):

 

if isParallelState(anc):

    for child in getChildStates(anc):

        if not statesToEnter.some(lambda s: isDescendant(s,child)):

            addStatesToEnter(child,statesToEnter,statesForDefaultEntry)  

 

we'll need to make sure that s2 isn't reentered, which seems to be accomplished by changing the inner if statement to:

if not statesToEnter.some(lambda s: isDescendant(s,child)) and isDescendant(s, child): 

 

 

2. I'm not sure about isPreempted anymore, after this last change. take the following example (suggested by pyscxml user DairTarg):

 

<scxml>

    <parallel id="p">

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

            <state id="a1" />

            <state id="a2" />

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

        </state>

        <state id="b" initial="b1">

            <state id="b1" />

            <state id="b2" />

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

        </state>

    </parallel>

</scxml>

 

here, the second transition is preempted by the first. but because the first transition no longer causes the state 'b' to be exited, it seems reasonable that its transition also be taken at event 'e'. would that be a correct assessment?

 

 - johan

 

On Wednesday, July 13, 2011 at 19:26 , Jim Barnett wrote:

 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. 

 


     
-------------------------------------------------------------------------------------------------------------------
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.