Re: IR and XPath DM implementation

Le 22 okt 2014 à 23:10, Jim Barnett <jim.barnett@genesys.com <mailto:jim.barnett@genesys.com>> a écrit :
> 
> 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.)
>  
> 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 <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 MUSTsupport 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 ProcessorMUST 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. <>

As you kow, I am of course very interested in DOM event support. The above requirements cover DOM interaction with only one document, so we should add a little more about picking a target document. Also, something about event_origin. Some suggestions:

10. If cross-document DOM communication is supported, whenever the event is targetted at a URL, a DOM Window, or an invocation of those, the default and only acceptable value of the optional 'interface' attribute for <send type="DOM"> is 'MessageEvent'.

11. When the postMessage interface (https://html.spec.whatwg.org/multipage/comms.html <https://html.spec.whatwg.org/multipage/comms.html>) of multiple documents in its browsing context can be called by the interpreter, it SHOULD expose a list of reachable Window objects to the datamodel and support those objects as the evaluated value of 'targetexpr'. It MAY provide a unique string value (which MUST NOT be a valid CSS selector or XPath) as an alternative to passing the Window object directly. When <send> is executed with a target which is a Window object or the name assigned to it, a supporting interpreter MUST attempt to convert the event to a DOM MessageEvent and post it to the target Window.

12. When posting a DOM event through the postMessage interface, the targetOrigin of the message MUST be set to the value of the SCXML event's targetOrigin field if present, or "*" by default. All other fields specified for the event MUST be included in the data property of the DOM MessageEvent.
(12 is entailed by 6 but it should have a separate test, as it is dependent on optional support for postMessage)

13. When a DOM MessageEvent is passed to the interpreter through its environment, the DOM event's 'source' property SHOULD be used as the value of the origin field for the SCXML event. The interpreter MAY instead replace a Window object with the string identifier that has been associated with that Window as the value of the event.origin field.


To do more (in particular, to support Web workers, EventSource, MessageChannel and WebSockets), which are all persistent, we'll need to extend <invoke> along the lines of http://www.jsscxml.org/connect.html <http://www.jsscxml.org/connect.html> ; then we can define how <send> behaves with those types of DOM invocations. I think we can have a single <invoke type=DOM> which would look at its target to pick the appropriate behavior:
Empty -> open a BroadcastChannel
Window object/name -> open a MessageChannel
HTTP URL -> listen to an EventSource
WebSocket URL -> open a WebSocket connection
The events in all cases are MessageEvents so I think it would work with just one type, the only difference is how you establish the connection.
Then there's the question of how we post events to an event-stream. And how we invoke WebWorkers. Maybe for WebWorkers we can simply use type=DOM with a src instead of target, since they'd be actual invocations rather than mere connections. Maybe not clear enough? but again, communication with WebWorkers is done through MessageEvents like all the rest so it makes sense to use the same type.

I don't have much time to work on JSSC at the moment, but I can at least look at any test suggestion and see if JSSC likes it.
Currently JSSC does not support cross-document messaging, only type=DOM with CSS or XPath targets.


			David