RE: Sharing state with invoked SCXML interpreters [was DOM in _event.data and KVPs]

That's a good question.  I'm no expert on JavaScript, however if you are using the SCXML Event I/O Processor, you can do whatever you want since its implementation is platform-specific.

It's worth some thought whether we need to say anything about serialization when using the Basic HTTP Event I/O Processor.  However even if we specified something for it, the spec still wouldn't say anything about how to pass data with the SCXML event i/o processor because you're not expected to interoperate with anyone else's implementation using it.  

- Jim

-----Original Message-----
From: David Junger [mailto:tffy@free.fr] 
Sent: Wednesday, April 03, 2013 9:18 AM
To: VBWG Public (www-voice@w3.org)
Subject: Re: Sharing state with invoked SCXML interpreters [was DOM in _event.data and KVPs]

Le 3 apr 2013 à 14:31, Jim Barnett a écrit :

> Section 6.4.4 of the spec makes it clear that there is no sharing of state between a parent and child.  That has always been the intent.

All right, all right. I have a question then. Look at this:

<data id="d" expr="{}" />
.
<assign location="d.d" expr="d" />
<send target="#_parent" event="whatever">
	<param name="someData" expr="d"/>
</send>

It is agreed that we can't pass 'd' itself by reference because that would mean sharing data.

Now, if we make no assumption about 'd', we can't stringify it into JSON in the general case (and certainly not in this particular case). It is possible to encode cyclic references into an executable JS serialization, or produce a clone that can be passed by reference because it wouldn't reference anything referenced in the source datamodel, but there is no standard way to accomplish either.

another example:

<fetch target="http://www.w3.org/TR/scxml/" callback="saveDoc"/> . <transtition event="saveDoc" cond="_event.data.status==200">
	<send target="#_parent" event="RTFR">
		<param name="recommendation" expr="_event.data.response"/>
	</send>
</transition>

Here we try sending a Document object to the parent. Even if we removed cyclic structures (i.e. links to parent and ownerDocument), JSON is clearly not the right serialization. Serializing to HTML would be nicer.

Yet just serializing to HTML would lose any custom properties and event listeners attached to the Document and its nodes. Basically, a good serialization for JS objects is *hard*.


So, would the recommendation recommend a particular method of cloning/serializing and what to do when that method fails? do we leave that to each implementation? set JSON as a baseline but allow refinement?

			David

Received on Wednesday, 3 April 2013 14:34:17 UTC