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

SCXML: hints attribute, late data binding and a bug

From: Johan Roxendal <johan@roxendal.com>
Date: Sun, 2 Jan 2011 14:16:05 +0800
Message-Id: <BF0667ED-2AE3-44CB-8956-4124432D9AA5@roxendal.com>
To: www-voice@w3.org

I'm currently implementing an SCXML processor in Python at <a href="http://code.google.com/p/pyscxml/">http://code.google.com/p/pyscxml/</a> and I've run into some issues I was hoping to get feedback on. 

the description of the hints attribute of send is pretty vague (presumably intentionally so) but I just need to pointed in the right direction as to its associativity when translating a send block into the scxml message xml format. in Example 3 at http://www.w3.org/TR/scxml/#N113A2 three datamodel slots are sent and the hints attribute is set to "email headers". in the resulting message xml, the property <scxml:property name="jsoncontent"> gets a hints element as a child, whereas the other properties don't. is there any particular reason why this is so? how do i know to which property the hints attribute refers?

question 2: 
will the behavior of late data binding be added to the algorithm? I guess i could squeeze it in there myself  i'm assuming such data should be bound after the execution of transition content and before the onentry of the state that wraps the datamodel tag? and then the datamodel blocks are ignored at subsequent state entries?

and a bug report:

one of my users discovered the following history-related bug (excuse the big paste):

	<state id="outer">
			<transition target="process">
				<send event="e1" />
				<send event="e2" />
			<log expr="'Entered outer'" />
		<state id="process" initial="s1">
			<history id="h" type="shallow" />
			<state id="s1">
				<transition event="e1" target="s2" />
		<state id="s2">
			<transition event="e2" target="h">
				<send event="quit" />
		<transition event="quit" target="f" />
	<final id="f" />

at initialization, the machine above will stop at s1 with two evens in its external queue: e1 and e2 (with the log "entered outer" having fired once).  e1 will bring it to s2, and from there e2 will bring us back to s1 via the history state. all of this is good and well with one exception: the log "entered outer" fires again, as a result of the e2 event. 

i've double checked my interpreter against the algorithm description in the standard and feel pretty convinced that I made no simple transcription mistake. 

many thanks,
Johan Roxendal
Received on Sunday, 2 January 2011 10:23:06 UTC

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