W3C home > Mailing lists > Public > www-voice@w3.org > January to March 2013

RE: DOM in _event.data and KVPs

From: Jim Barnett <Jim.Barnett@genesyslab.com>
Date: Sun, 31 Mar 2013 23:20:06 +0000
To: Stefan Radomski <radomski@tk.informatik.tu-darmstadt.de>, "www-voice@w3.org" <www-voice@w3.org>
Message-ID: <57A15FAF9E58F841B2B1651FFE16D281033B65@GENSJZMBX02.msg.int.genesyslab.com>
   For test 561,  you assumption is correct.  The relevant section of the spec is in 5.6.2  "If the 'expr' attribute is not present [on content], the Processor MUST use the children of <content> as the output."  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.  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?  

In 562, you are right that KVPs are key-value pairs, and there are three cases: XML, KVPs or a space-normalized string.  Your implicit question is whether there could be a <content> element whose child/children specified KVPs as opposed to a string (or XML).  I would think that would be possible if the content was unambiguously JSON.  However we say that support for JSON is optional, so if you don't support JSON, the children of <content> are either XML or a string (to be space normalized).  The language making JSON optional is left over from the days when we thought we might make this datamodel mandatory to implement, (and we didn't want to constrain implementations excessively.)  Perhaps it would be better to get rid of the fuzziness.  We could either remove JSON from the datamodel altogether, or make it a mandatory part.  Which would you prefer?  (Of course, whichever one we choose, implementations are free to define their own datamodel that makes the opposite choice. ) 

- Jim

-----Original Message-----
From: Stefan Radomski [mailto:radomski@tk.informatik.tu-darmstadt.de] 
Sent: Saturday, March 30, 2013 12:44 PM
To: www-voice@w3.org
Subject: DOM in _event.data and KVPs

Hi there,

as I am working my way through the tests, I came onto test561, where the content of send is XML. The test assumes that _event.data is a DOM and operates on it:

<send event="foo">
   <books xmlns="">
     <book title="title1"/>
     <book title="title2"/>
<transition event="foo" cond="_event.data.getElementsByTagName('book')[1].getAttribute('title') == 'title2'" target="pass"/>

My question is: How does the document in _event.data is supposed to look? At the moment I have:

<?xml version="1.0"?>
 <book title="title1"/>
 <book title="title2"/>

Which assumes that there is only a single element as the child of <content>. The alternative is to introduce a top-level element (e.g. <content>) and have the send contents as its child nodes - which is more generic but unspecified as far as I can tell.

Also in test562, it is written that "in the ECMA data model, test that processor creates space normalized string in _event.data when receiving anything other than KVPs or XML in an event". The test references C2, which talks about space-normalizing string literals from data elements, but not as part of content. Also, am I to assume that KVPs are key/value pairs? That is, I would have to distinguish three cases with the content in send:

1. content has at least one node of type element  -> use the DOM representation 2. content is only a node of type text  -> space-normalize 3. content is a set of key/value pairs  -> provide a hash in _event.data 

I guess the last case only applies with an empty <content> and the namelist attribute or param elements inside <send>?

Best regards
Received on Sunday, 31 March 2013 23:20:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:07:43 UTC