W3C home > Mailing lists > Public > www-voice@w3.org > July to September 2011

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

From: Johan Roxendal <johan@roxendal.com>
Date: Thu, 14 Jul 2011 11:55:09 +0200
To: Jim Barnett <Jim.Barnett@alcatel-lucent.com>
Cc: www-voice@w3.org, w3c-voice-wg <w3c-voice-wg@w3.org>
Message-ID: <8B0649AA99ED49B3B0CA14A842993043@roxendal.com>
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 (mailto: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) [mailto:www-voice-request@w3.org] On Behalf Of Johan Roxendal
> > Sent: Monday, June 27, 2011 11:59 AM
> > To: www-voice@w3.org (mailto: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. 
Received on Thursday, 14 July 2011 09:55:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 14 July 2011 09:55:47 GMT