Re: DOM in _event.data and KVPs

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

> A node-set is not a legal XML document, so in your example with <books>...</books><authors/>, the processor should treat it as a string.  Off the top of my head, this sounds OK to me.  Document authors who want XML under _event.data will need to put in the root node themselves.

Le 1 apr 2013 à 12:40, Stefan Radomski a écrit :

> […] there ought to be a topmost container element like <content>. I guess I am in favor of this approach as there are no ambiguities of which node type _event.data is when XML is given.

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

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.


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

			David

Received on Monday, 1 April 2013 19:54:55 UTC