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

RE: SCXML: hints attribute, late data binding and a bug

From: Jim Barnett <Jim.Barnett@alcatel-lucent.com>
Date: Sun, 2 Jan 2011 08:26:49 -0800
Message-ID: <E17CAD772E76C742B645BD4DC602CD8103BC6656@NAHALD.us.int.genesyslab.com>
To: "Johan Roxendal" <johan@roxendal.com>, <www-voice@w3.org>
Johan,
  For your second question, yes, following section 5.3.3 the data should
be bound after the transition content and before the <onentry> and
should be ignored in subsequent entries.

I will reply to your other two questions once we've had a chance to
discuss them in the group.

- Jim Barnett

-----Original Message-----
From: www-voice-request@w3.org [mailto:www-voice-request@w3.org] On
Behalf Of Johan Roxendal
Sent: Sunday, January 02, 2011 1:16 AM
To: www-voice@w3.org
Subject: SCXML: hints attribute, late data binding and a bug

Hello,

I'm currently implementing an SCXML processor in Python at <a
href="http://code.google.com/p/pyscxml/">http://code.google.com/p/pyscxm
l/</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):

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

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


					
-------------------------------------------------------------------------------------------------------------------
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 Sunday, 2 January 2011 16:27:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 2 January 2011 16:27:29 GMT