DOM Event I/O processor

I have now posted all the tests I have in the Implementation Report Test Plan document:  http://www.w3.org/Voice/2013/scxml-irp/

You will notice that there are no tests for the DOM event i/o processor.  This is partly because I don't have access to a suitable environment to develop them in, but the larger issue is whether we will get enough implementations to keep the processor in the final spec.  W3C policy is that we must produce at least two interoperable implementations of each feature in the final Recommendation document (where "interoperable implementations" means that they pass the kinds of tests that are in the test plan document.)

So the bigger question is: are there two people/groups who have implemented the DOM event i/o processor and who want to make their implementations interoperable?  If so, it will make sense for them to cooperate on writing the tests, rather than for me to guess blindly.    These tests might not need to use the full .txml abstraction if we assume that implementations using the DOM event i/o processor are also using an ECMAScript datamodel.

So please let the list know if you're interested in participating in this effort.   For reference, I'm including the relevant assertions below.  There are 10 of them, and we would need a test for each (and two implementations that pass the test.)


-          Jim

579.  The SCXML Processor MUST support sending DOM events to any node in the document by selecting the DOM Event I/O processor (type="http://www.w3.org/TR/scxml/#DOMEventProcessor") and specifying the node as the target.

580. Processors MUST support CSS notation [CSS2] for specifying the node, and MAY support XPath [XPath 1.0] or other notations.

581.  The SCXML Processor MUST support sending events that implement the CustomEvent interface.

582.  The Processor MAY support sending events that implement other interfaces. In this case, the Processor MUST support an additional attribute on <send>, called 'interface', that allows the author to specify the interface to use. The default value of this attribute MUST be 'CustomEvent'.

583.  The Processor MUST use the value of the 'event' attribute as the type of the DOM event.

584.  The Processor MUST support two additional attributes on <send>, called 'cancelable' and 'bubbles', which can be used to set the corresponding properties of the event. The default value for 'cancelable' MUST be 'false'. The default value of 'bubbles' MUST be 'true'.

585.  The Processor MUST populate any other initializable attributes of the event with the values of any matching keys specified via "namelist" or <param>.

586.  If the specified DOM event type has a 'detail' attribute, the Processor MUST populate it with any remaining data (i.e., values specified by 'namelist', <param> or <content> that are not used to populate the event's initializable attributes.)

587.  If the specified event is not a legal DOM event or if the specified node cannot be reached, the SCXML Processor MUST place the error error.communication in the internal event queue.

588.  The DOM Event I/O Processor implementation MUST add a function to the DOM scripting environment that takes a DOM event as its argument and adds a corresponding event to the SCXML Processor's external event queue. The function MUST use the type of the DOM event as the name of the SCXML event and MUST place a shallow copy of the DOM event in _event.data.