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

DOM in _event.data and KVPs

From: Stefan Radomski <radomski@tk.informatik.tu-darmstadt.de>
Date: Sat, 30 Mar 2013 16:44:22 +0000
To: "www-voice@w3.org" <www-voice@w3.org>
Message-ID: <B2AF6FD1-6976-4D35-A2A2-67DDB3969FBA@tk.informatik.tu-darmstadt.de>
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">
 <content>
   <books xmlns="">
     <book title="title1"/>
     <book title="title2"/>
   </books>
 </content>
</send>
[]
<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"?>
<books>
 <book title="title1"/>
 <book title="title2"/>
</books>

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
Stefan
Received on Saturday, 30 March 2013 16:44:47 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 30 March 2013 16:44:52 UTC