RE: DOM in _event.data and KVPs

Taking the first element makes me nervous because it means throwing out the rest and losing information.  If we keep the whole thing as a string at least there's the possibility (given suitable libraries) of converting it back into XML and storing it in the datamodel.  I think that it's safer to keep everything in some possibly-not-very-friendly format, than to try to guess at what to keep in a more usable format.  

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.  

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.  

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.)

- Jim

-----Original Message-----
From: Stefan Radomski [mailto:radomski@tk.informatik.tu-darmstadt.de] 
Sent: Monday, April 01, 2013 4:41 PM
To: David Junger
Cc: VBWG Public (www-voice@w3.org)
Subject: Re: DOM in _event.data and KVPs

On Apr 1, 2013, at 9:54 PM, David Junger <tffy@free.fr>
 wrote:

> I agree that it's nice for authors to know there's always going to be a Document, but using <content> as the root doesn't work semantically and is inconsistent with what you'd get if you used 'src' instead of <content> (the spec is quite clear that those should be equivalent).

That's a good point.

> Jim's solution is not the most flexible but it's not too hard to wrap a list of nodes into a root element, and it could be done as in HTML parsing: if the parser is told (using the 'type' attribute on <content>), or guesses, the document type, then it can insert the missing root. Then we'd have problems only for node lists where the type is unspecified (or unsupported) and heuristics fail.
> 

Well, let's look at our options here:

1. Introduce an additional root element
- Inapplicable because, application developers would expect the same DOM whether they specify it via content.src or inline. That's your argument from above and I agree.

2. Realize that multi-rooted XML in content is itself not a XML document and treat it as space-normalized strings
- Applicable but somewhat unintuitive for application developers. This is Jim's suggestion.

3. Always represent _event.data as a DocumentFragment
- This penalizes application developers who use only a single root element as all the methods from document are unavailable.

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.

5. Treat multi-rooted XML in <content> as an error
- Not sure whether this is preferable to any variant, but it's one way to make it explicit for application developers. The implied assumption is that no one wants space normalized XML fragments.

6. Only take the first element of content
- This still might leave application developers wondering what happened to the rest of the document but provides a "path to a solution" for application developers as they will see a DOM in _event.data to start with.

Personally, I'd go for:
1. Multi-rooted XML in content?
2. Log a message and take first element as root of new document.

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).

> 
>> 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? 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. 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.

Regards
Stefan

Received on Tuesday, 2 April 2013 13:37:15 UTC