Re: DOM in _event.data and KVPs

Le 1 apr 2013 à 01:20, Jim Barnett a écrit :

> So in this case, the output of <content> is the <book> node, and you would build the DOM for that and put it under _event.data.

The output should be a Document with that node as root, not the Node itself.

> If content had multiple children, you would put multiple such nodes under _event.data.  If that's not clear from the spec, could you suggest wording that would make it so?  Would it suffice to say "relevant DOM structure(s)" or do we need something more specific?

Yes, authors should know what structure(s) to expect.
Unfortunately, the standard DOMParser that is already implemented in some browsers only accepts full documents, and returns an error document in other cases, so we have no standard to follow if we wish to allow multiple children elements in <content>.

http://domparsing.spec.whatwg.org/#dom-domparser-parsefromstring

I propose this:
- add an optional 'type' attribute to <content>, which should overrule the following heuristics and facilitate the integration of additional, platform-specific <content> parsers

- if the XML in <content> is a full Document (i.e. it has exactly one root element, which is the only Element child of <content>), return a Document as per the DOMParser algorithm (use the 'type' value from <content>)
- else if there are multiple Element children of <content>, return a DocumentFragment with all the children nodes, including text nodes
- else try interpreting as JSON or whatever
- if nothing works, return the text content as a string

In any case, do not return something which points to (part of) the SCXML DOM, which means the nodes have to be cloned or re-parsed or removed from their original parent before being put into the new Document or DocumentFragment.

			David

Received on Monday, 1 April 2013 08:35:54 UTC