RE: DOM Event I/O processor

David,
That is an interesting idea, but it will remain academic until we find a second implementation.  If I understand your proposal correctly, I also like the first targeting scheme:
<send type="DOM" document="docname" target="#someNode" .../>

As I understand this, the target="" syntax would be the same as in the case where you're sending to a node in your own document.  The 'document' attribute would simply allow that syntax to be applied to another document.  That seems like a pretty clean solution.


-          Jim

From: David Junger [mailto:tffy@free.fr]
Sent: Tuesday, April 16, 2013 10:45 AM
To: Voice Public List
Subject: Re: DOM Event I/O processor

Le 16 apr 2013 à 16:05, Jim Barnett a écrit :


You will notice that there are no tests for the DOM event i/o processor.  This is partly because I don't have access to a suitable environment to develop them in, but the larger issue is whether we will get enough implementations to keep the processor in the final spec.  W3C policy is that we must produce at least two interoperable implementations of each feature in the final Recommendation document (where "interoperable implementations" means that they pass the kinds of tests that are in the test plan document.)

So the bigger question is: are there two people/groups who have implemented the DOM event i/o processor and who want to make their implementations interoperable?  If so, it will make sense for them to cooperate on writing the tests, rather than for me to guess blindly.    These tests might not need to use the full .txml abstraction if we assume that implementations using the DOM event i/o processor are also using an ECMAScript datamodel.

So please let the list know if you're interested in participating in this effort.   For reference, I'm including the relevant assertions below.  There are 10 of them, and we would need a test for each (and two implementations that pass the test.)

I could write the tests, but AFAIK my implementation is the only one that supports DOM events.

Also, I remember someone raising an interesting issue about the DOM I/O processor:
When the SCXML interpreter runs in a Web browser, as mine does, the document whose DOM is targeted by DOM events is naturally the HTML document containing the SCXML interpreter. But what about the other way around, SCXML interpreters that can invoke web browsers and other DOM-enabled systems? how do they target a particular DOM ? That could also be useful in my implementation to let authors target a different tab or window in the browser (Torbjörn wanted to do that for his Dialog Web Lab interface, I recall).

This becomes particularly intersting because, while XPaths can be appended to a URI, CSS selectors, which we agreed are most familiar to DOM users, do not have any kind of support for targeting a document.
Besides, a document URI is not equal to a parsed DOM instance of that document, and a DOM can exist that has no source URI.

I propose that each platform defines its way of naming DOMs and passing the events. For example, EventSource and Channel Messaging allow different JavaScript contexts (running in different processes or even on different machines) to exchange DOM events so the target need not be local.

Some external code on the platform must register available targets to the SCXML interpreter, assigning a name to that DOM.
Also, when invoking a DOM-enabled system, the invokeid would be used as the name for that DOM.

When sendin a DOM event, we would need either
- a new attribute: <send type="DOM" document="docname" target="#someNode" .../>
- a custom 'target' scheme: e.g. <send type="DOM" target="documentName: #someNode" .../>

For the record, I prefer the first solution even though semantically it is not very nice to split the target over two attributes.

                                    David