Re: IR and XPath DM implementation

Zjnue,
   I think that these tests will be complicated, and I agree that they 
will probably be manual.  I wouldn't bother with the .txml files and 
xslt transformations (which are intended to generalize the tests for 
as-yet-unseen platforms).  Whatever test format you and David agree on 
will be fine.  If a third person comes along and wants to run them, we 
can try to figure out how to generalize them at that time.

  - Jim
On 10/26/2014 1:05 PM, Zjnue Brzavi wrote:
> 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
>