Re: IR and XPath DM implementation

Hi Jim,

Thanks for the feedback.


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

Perfect. Did you have a particular structure in mind for these tests?
Manual testing seemed the easiest for most assertions - explained below.


>  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] for specifying the
> node, and *MAY* support XPath [XPath 1.0] 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.)
>
Please again refer to testdom001 [1] below. Here we:

(a) specify type="http://www.w3.org/TR/scxml/#DOMEventProcessor"
(b) use a CSS selector to select the target node ( target="#targetNode" )
(c) do not support interfaces other than 'CustomEvent', the default.
(d) node content only gets updated for event types equal to the send
"event" attribute value ('setcontent') [4].
(e) in the target node 'setcontent' event handler [4], both 'bubbles' and
'cancelable' can be inspected - which will be the default values for those
as they are not specified in the SCXML.
(f) for 'CustomEvent'(s) it seems there are no "any other initializable
attributes" right? only supporting the *must*s, so no other interfaces than
'CustomEvent' for now.
(g) the value for detail can also be read in the 'setcontent' handler [4].

Essentially, final stages are only reached if the prerequisites are in
place.
Not very scientific, but some aspects are a little hard to isolate in a way
that makes sense, so hoping the above is good enough.

>  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.
>
Please see testdom002 [2] ( supplying attribute, interface="invalid" ) and
testdom003 [3] ( supplying attribute, target="#invalid" ).
Both these should have the Outcome 'pass' if error.communication lands on
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.
>
Back to testdom001 [1]. Clicking the button here [5] should place the
'click' event on the SCXML interpreter's event queue. The transition here
[6] tests for it. We could add a cond attribute testing the _event.data
contents there if you don't mind specifying what it should be?

Here are some quick instructions for anyone to run the tests mentioned (not
streamlined, as these are rather ad-hoc).

- follow steps 1-2 here [7]
- in build.hxml [8] line 90-92, comment all tests except the one interested
in
- run "haxe build.hxml"
- open index.html [9]

Thanks,
Zjnue


[1] https://github.com/zjnue/hscxml/blob/master/test/js/testdom001.scxml
[2] https://github.com/zjnue/hscxml/blob/master/test/js/testdom002.scxml
[3] https://github.com/zjnue/hscxml/blob/master/test/js/testdom003.scxml
[4] https://github.com/zjnue/hscxml/blob/master/test/js/index.html#L28
[5] https://github.com/zjnue/hscxml/blob/master/test/js/index.html#L8
[6] https://github.com/zjnue/hscxml/blob/master/test/js/testdom001.scxml#L14
[7] https://github.com/zjnue/hscxml/tree/master/test
[8] https://github.com/zjnue/hscxml/blob/master/test/build.hxml
[9] https://github.com/zjnue/hscxml/blob/master/test/js/index.html