Re: DOM in _event.data and KVPs

Le 2 apr 2013 à 15:36, Jim Barnett a écrit :

> Adding a 'type' attribute to <content> strikes me as a perfectly reasonable platform-specific extension, but if we put it in the spec, one of two things happens:
> 1. We try to spec it out fully, in which case we have to specify all the values of the attribute and how they interact with the datamodel, event i/o processors, etc.  This will delay us for a year, and I'd really like to get 1.0 done soon.
> 2.  We don't spec it out fully, and say that the interpretation of the value is platform-specific.  There's no interoperability that way, so it's not really any different from making the attribute itself platform-specific.  

Its value should be a MIME type. That doesn't guarantee that all platforms will treat all values equally, of course, but at least the values are standard. And we can add some standard interpretations like
- text/* : string
- application/*xml : XML parser, or string if the DOM is unsupported in the datamodel
- application/json : JSON parser, or string if JSON is unsupported
- anything else : string or platform-specific

Just like with I/O processors and datamodels, that means we have a few essential values defined in the spec, leaving room for extension.


> Finally, adding a 'type' attribute to <content> doesn't help us when we're getting data from an external source (i.e. via an external event).  I think that this is the most problematic case because the app may be dealing with a legacy data source that can't modify its format.

I'm not sure why the type attribute isn't helpful there. If the author can't change the data format, they may still know what it is so they can tell the interpreter. Maybe the legacy data source is polite enough to send a Content-Type header, too.

> However, I do think that we should explicitly call out the possibility of JSON.  There should be a clause saying "if the content is JSON and the processor supports JSON, it must build the corresponding ECMAScript structure and use it as the value of _event.data".  (This sidesteps the question of whether JSON is mandatory.)


Agreed. Unless the author explicitly specifies a different type.


Le 1 apr 2013 à 22:41, Stefan Radomski a écrit :

> 4. Have some heuristics together with content.type for clarification
> - I am not sure, whether this is suited to resolve the issue, if you specify content.type as XML and have it multi-rooted you'd still need the interpreter introduce a root element. Something which I'd prefer the user to do.

I can see that being useful for HTML fragments, not sure for what else. I guess if there isn't another use case we should just treat HTML as text and let the receiver parse it or just put it in some innerHTML.

Anyway, the type attribute is still relevant because the platform may have specific parsers for more data types which may not be easily identifiable otherwise (basically anything that isn't XML). In fact, if you have some JavaScript in <content> it could look very much like JSON, the interpreter may decide to parse it as such, but maybe it isn't quite valid JSON after all so you'd want to tell the parser to treat is as text/javascript instead.



> This is in line with what our interpreter does if we encounter multiple elements where only a single one is allowed (e.g. <content> itself).

That's what JSSC does too. But <content> should be able to contain anything. I'm with Jim on this, multiple children should not be truncated, even if we don't parse them.

So if there is more than one child element, treat the content as text. Unless the author specified an application/*xml type, then create an error document like the DOMParser would.
If there is exactly one child element, use the type if provided (so authors can force text interpretation). If no type was supplied by the author, try to parse as XML and use text if it fails, with a warning.
If there is no child element and the author didn't say what type it is, try JSON if it looks like JSON (and try other platform-specific parsers if it looks like they might fit). In case of a parsing error then treat as text and give a warning.
If there is no child element but the author said what type it is, use only the required parser on the textContent and raise an error if it failed.

>>> As the expr attribute of content is already subject to evaluation by the datamodel and it's somewhat obvious to return JSON for nested ECMAScript data structures in expr
>> 
>> ECMAScript objects don't map to JSON in general. And passing actual ECMAScript references to local targets is often preferable even when the structure can be stringified.
> 
> Huh? I was under the impression that e.g. an invoked SCXML session does not share the datamodel with its parent?

Indeed it doesn't. And sharing objects is not the same as sharing variables (each datamodel has its own reference, possibly in a different location, to the same object). But something is shared, and it is true that SCXML sessions theoretically shouldn't share their data. Still…

> In fact it could run on a completely different host. So passing "references to local targets" would just end up as a potentially undeclared identifier in the other component, if I understood you correctly.

Of course, for remote targets there is no choice but to stringify the objects as best you can.

> It might work if you cannot separate datamodels due to running in the same JS context, but it is nothing the standard allows as far as I read it.


Surely you can have your JS runtime create as many global contexts as you like, while still being able to share objects betweeen them. I do it for JSSC by creating hidden <iframes>, which have their own global Window. You run a separate v8 for each session?

I don't think it's much of a problem. SCXML interpretation is synchronous so there is no risk of race conditions. The author just needs to be aware that it is the same object, not a copy. It is normal JavaScript behavior (you can pass objects between windows by reference if the security restrictions allow it) so they wouldn't be surprised. And the spec says that values can be any value allowed in the datamodel. Well, references are values in ECMAScript.

There are good reasons to allow sending references. Obviously, it's much faster than copying a complex object and it saves memory. It also preserves all the prototype chains and references.

			David

Received on Tuesday, 2 April 2013 17:23:23 UTC