W3C home > Mailing lists > Public > www-voice@w3.org > January to March 2013

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

From: Jim Barnett <Jim.Barnett@genesyslab.com>
Date: Fri, 8 Feb 2013 21:21:26 +0000
To: Jim Barnett <Jim.Barnett@genesyslab.com>, Voice Browser Working Group <w3c-voice-wg@w3.org>, "www-voice@w3.org" <www-voice@w3.org>
Message-ID: <57A15FAF9E58F841B2B1651FFE16D28101FB4A@GENSJZMBX03.msg.int.genesyslab.com>
  After looking at this a bit, I think that Chris' analysis is correct.  The current algorithm adds ancestors when the history state has a value, but not when we are using its default value.  That's a bug and the two cases should be treated the same way.  If you make the change Chris suggests, the problem should go away.  I'm also wondering whether we shouldn't refactor enterStates to make it clearer, but that will take more thought.  

- Jim 

-----Original Message-----
From: Jim Barnett [mailto:Jim.Barnett@genesyslab.com] 
Sent: Friday, February 08, 2013 1:51 PM
To: Voice Browser Working Group; www-voice@w3.org
Subject: RE: ISSUE-830: Bug in transition with target of history state [SCXML-LC-Comments]

  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]


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:


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

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

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

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

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:

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


Received on Friday, 8 February 2013 21:21:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:07:43 UTC