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

  To reply to your first question,  the interpretation of 'hints' is
completely platform-specific.  (We've borrowed this concept from CCXML,
which finds it useful.  The idea is to allow implementations to offer
their own special optimizations without trying to figure out how to
standardize them across platforms.)    We're going to change the example
you refer to so that <hint> becomes a direct child of <payload>, and add
an explanation that in this case the platform has chosen to incorporate
'hints' into the message, but another platform might do something
different with it, including ignoring it.  (The existing example is
technically correct, since the platform can do _anything_ it wants with
'hints', but it's not at all clear why the platform would embed <hint>
inside a <property>, so that makes things pretty confusing.)

We will discuss your bug report on <history> when we review our
outstanding issues with the algorithm in about a month.

Jim Barnett

-----Original Message-----
From: [] On
Behalf Of Johan Roxendal
Sent: Sunday, January 02, 2011 1:16 AM
Subject: SCXML: hints attribute, late data binding and a bug


I'm currently implementing an SCXML processor in Python at <a
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 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

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 Wednesday, 5 January 2011 21:34:00 UTC