- From: Jim Barnett <1jhbarnett@gmail.com>
- Date: Sun, 26 Oct 2014 15:12:49 -0400
- To: www-voice@w3.org
- Message-ID: <544D47B1.1060004@gmail.com>
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 >
Received on Sunday, 26 October 2014 19:13:17 UTC