RE: ISSUE-830: Bug in transition with target of history state [SCXML-LC-Comments]

Stefan,
  Yes, this looks like a bug.  I will look at it and Chris' comments as well.

- Jim

-----Original Message-----
From: Voice Browser Working Group Issue Tracker [mailto:sysbot+tracker@w3.org] 
Sent: Friday, February 08, 2013 1:46 PM
To: w3c-voice-wg@w3.org; www-voice@w3.org
Subject: ISSUE-830: Bug in transition with target of history state [SCXML-LC-Comments]

ISSUE-830: Bug in transition with target of history state [SCXML-LC-Comments]

https://www.w3.org/Voice/Group/track/issues/830


Raised by: James Barnett
On product: SCXML-LC-Comments

>From Stefan Radomski [radomski@tk.informatik.tu-darmstadt.de]

Hi there,

I do have a problem with the following scxml document putting my interpreter in an illegal configuration:

<scxml 
 xmlns="http://www.w3.org/2005/07/scxml"
 version="1.0"
 profile="ecmascript"
 id="root"
 initial="a">

 <state id="a">
  <transition target="h" />
 </state>

 <state id="b" initial="b1">
  <history id="h">
   <transition target="b1.2"/>
  </history>

  <state id="b1" initial="b1.1">
   <state id="b1.1"/>
   <state id="b1.2">
    <transition event="t2" target="b1.3"/>
   </state>
   <state id="b1.3">
    <transition event="t3" target="a"/>
   </state>
  </state>
 </state>
</scxml>

The problem is with entering state "h" from "a" for the first time. With regard to "procedure enterStates(enabledTransitions)", this means that tstates contains only "h" with "a" as the source state and "root" as their ancestor. The procedure "addStatesToEnter(s,statesToEnter,statesForDefaultEntry)" will recognize s as being a history state and call itself with "b1.2", adding "b1.2" into "statesToEnter".

When returning into the enterStates procedure again, only tStates will be iterated to get the set of proper ancestors to enter as well, but tStates still only contains "h", not "b1.2", meaning "b" will be entered as a proper ancestor of "h" but "b1" will not as "b1.2" is only contained in statesToEnter, not in tStates and thus, its proper ancestors are never added into statesToEnter resulting in a configuration of {"b", "b1.2"}.

What did I miss here? What part of the pseudo-code is supposed to add "b1" into statesToEnter with the document above? As having b1.2 and not b1 in the configuration is supposed to be illegal.

Best regards
Stefan

Additional comment from chris nuernberger [cnuernber@gmail.com]

I had the *exact* same issue.  I *think* it is in the pseudo-code.

I believe the pseudo-code should be ammended to:

modified--
    
procedure addStatesToEnter(state,statesToEnter,statesForDefaultEntry):
    if isHistoryState(state):
        if historyValue[state.id]:
            for s in historyValue[state.id]:
                addStatesToEnter(s,statesToEnter,statesForDefaultEntry)
                for anc in getProperAncestors(s,state):
                    statesToEnter.add(anc)
        else:
            for t in state.transition:
                for s in getTargetStates(t.target):
                    addStatesToEnter(s,statesToEnter,statesForDefaultEntry)
     --begin modifications--
     for anc in getProperAncestors(s,state):
      statesToEnter.add(anc)
     --end modifications--
    else:
        statesToEnter.add(state)
        if isCompoundState(state):
            statesForDefaultEntry.add(state)
            for s in getTargetStates(state.initial):
                addStatesToEnter(s,statesToEnter,statesForDefaultEntry)
        elif isParallelState(state):
            for s in getChildStates(state):
                addStatesToEnter(s,statesToEnter,statesForDefaultEntry)


Chris

Received on Friday, 8 February 2013 18:51:42 UTC