RE: IR and XPath DM implementation

Zjnue,
That's great news about the XPath data model.

I'm interested in retaining the DOM Event I/O Processor if other people are.  To do so, we need to write a  test for each normative assertion in the spec ( a normative assertion is one containing a "must" "should" or "may", but in practice only the "musts" get tests.)    There are (roughly) 9 such assertions (see below), so we would need 9 tests (though we might write one test for multiple assertions, or write multiple tests for one assertion.)

If someone wants to work with Zjnue on these tests, that would be very helpful.  I will point out, though, that if we don't get two implementation reports for the DOM Event I/O Processor in time, it will not disappear completely.   We will be forced to remove it from the SCXML 1.0 specification, but we will publish it as a separate Working Draft.  We can then move it to recommendation status on its own schedule.  (The same holds for other Event I/O Processors or data models that people might want to standardize.)


-          Jim

Here are the assertions (from Section C.3):

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

2.       Processors MUST support CSS notation [CSS2]<file:///C:\Users\jabarnet\W3C\WWW\Voice\Group\2005\HST\SCXMLNotation.html#CSS2> for specifying the node, and MAY support XPath [XPath 1.0]<file:///C:\Users\jabarnet\W3C\WWW\Voice\Group\2005\HST\SCXMLNotation.html#XPATH1> or other notations.

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

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

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

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

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

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

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

From: Zjnue Brzavi [mailto:zjnue.brzavi@googlemail.com]
Sent: Wednesday, October 22, 2014 4:52 PM
To: www-voice@w3.org
Subject: IR and XPath DM implementation

Hi,

Just a quick note to say that hscxml [1] now implements the XPath data model, to the extent that it passes all required XPath specific tests. While hscxml cross-compiles to a variety of targets (Neko, C++, JS, and Flash ..with others likely to follow), the XPath data model is Flash specific, due to the library in use. This may change in future, but the main goal of this implementation is to help the SCXML specification progress to Recommendation phase asap.

The primary compilation target for the non-XPath specific tests is Neko. All these tests pass for both the ECMAScript and hscript data models. Please find the hscxml IR here [2].

Finally, it would be wonderful to retain the work related to the DOM Event I/O Processor, not only as an acknowledgement of efforts over the years, but also because defining basic integration points seems quite fitting for an accessible technology.

The DOM Event I/O Processor is supported in hscxml and there are 1 or 2 basic tests for it already [3]. If anyone else is willing to help push that forward, please let us know.

br,
Zjnue

[1] https://github.com/zjnue/hscxml
[2] https://github.com/zjnue/hscxml/blob/master/test/files/report/scxml10-ir-results-template.xml
[3] https://github.com/zjnue/hscxml/blob/master/test/js/testdom001.scxml
https://github.com/zjnue/hscxml/blob/master/test/js/testdom002.scxml