W3C home > Mailing lists > Public > www-voice@w3.org > January to March 2013

Re: ISSUE-825: comments from Darmstadt [SCXML-LC-Comments]

From: David Junger <tffy@free.fr>
Date: Tue, 22 Jan 2013 17:28:19 +0100
Message-Id: <1C1755D4-67A6-4398-8F18-B4853821CFC2@free.fr>
To: Voice Browser Working Group <w3c-voice-wg@w3.org>, "VBWG Public (www-voice@w3.org)" <www-voice@w3.org>
> Especially the logic around "filterPreempted" is still somewhat fuzzy to us.

I agree that the recommendation does a poor job of explaining that in a concise way. But it boils down to this:
When you enable a transition (going in transition order), you preempt any further transition whose source state is going to be exited by that transition during the microstep (even if the source state is re-entered in the same microstep).


> - Sending events via the basichttp ioprocessor should allow for the other party to send events in the response.

basichttp is optional and simply doesn't (and is not going to) work for a client-server paradigm. It's a shame that the recomendation doesn't try to define some client-server communication, we'll have to work on standardizing that in the future (actually, I would really like to discuss it with other implementers so we can all do it the same way(s) and publish a spec).


> - When embedding an interpreter, #_parent could be specified to send events to the embedding application.

Note that special ("#_") target values are only defined for type="SCXML". But the embedding app won't be an SCXML interpreter and doesn't necessarily know what to do with SCXML events (other than using the SCXML interpreter's API to respond to them but we haven't defined that yet). Even if the app can receive events, it will be a different type of events, and therefore a different type of <send>, which can have its own definition of "#_parent" that makes sense there. For example, the type="DOM" works very well when embedding in DOM-enabled documents, but "#_parent" in that context simply targets the DOM element with id="_parent".

Your implementation might (should?) have (I haven't looked, sorry) another platform-specific <send> type where you define the meaning of targets and how the sending transforms and encodes the event. That could mean sending events to your API where the application using your implementation will define callbacks for handling received events. You could also, for example, have a <send> type to interact with a (possibly remote) Mac OS by sending AppleEvents, completely bypassing your API, and define "#_self" for that type as the local Mac rather than the SCXML interpreter's immediate environment.
Whatever makes sense.

			David
Received on Tuesday, 22 January 2013 16:28:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 January 2013 16:28:57 GMT