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

Re: Soliciting Comments from SCXML Users

From: David Junger <tffy@free.fr>
Date: Wed, 9 Jan 2013 12:24:56 +0100
Message-Id: <9F6CFC6A-D2EE-4363-BD1A-28AF4C981D8D@free.fr>
To: "VBWG Public (www-voice@w3.org)" <www-voice@w3.org>
I am still working on JSSCxml, a Web browser implementation of SCXML.
JSSC is in active development, already quite capable (and largely conformant), and distributed under a MIT license.
It includes and powers a graphical viewer/debugger for SCXML, which should also become a graphical editor in the future.

With DOM events, it is very good at interacting with its parent Web page. It forces you to write robust event-based UI code while the complexity of managing a Web app is tamed by the state chart.
What SCXML lacks in its ancestral area of dialog management compared with dedicated languages is grammars and parsing. Adding them is easy, but it'll always take a bit more code. However, SCXML makes up for it with its core expressivity (<history> and <parallel> in particular give you complex behavior in a way that's incredibly easy to design) and is orders of magnitude easier to debug than typical CCXML / VoiceXML implementations. If you've ever worked with those, you surely remember the pain. Cryptic debug logs are over, instead you can litterally look at your state chart as the application takes transitions through it. I think that point will be decisive in encouraging a <transition target="scxml"/> for the dialog management world.

Now some specific remarks:

The value at an undefined location is undefined, but it does not necessarily prevent the ECMAScript interpreter from assigning a new value to it (if the location points to a yet-undeclared property of an existing object). It may be desirable to let the ECMAScript datamodel behave like ECMAScript and allow such assignments to undeclared locations, raising an error when and only when the ECMAScript interpreter does. Certainly wouldn't hurt my implementation, I'd just have to remove some ugly code.

I have noticed a few critical problems with the new definition of the DOM send type. Sorry ;)

D.3.1 second paragraph:
- the name of the CustomEvent's custom property is "detail" without an "s"
- in the browser, it is impossible to set the value of many event properties (they are read-only to content JavaScript) so a browser implementation cannot be conformant with the current requirement that any event property named in namelist or <param> be set to the corresponding value (no error will be raised by the attempt, it will simply leave the value unchanged).

- It is not practical to prevent Element instances (such as those representing SCXML states and other elements) in the browser from implementing the EventTarget interface, and neither is it practical (without native support) to have an inline <scxml> document in HTML (an <scxml> tag with a 'src' attribute is fine).
- It is irrelevant at this point that the <scxml> element and its children implement it, since it cannot be used to listen to all DOM events anyway, because unlike with SCXML events, DOM events must have a registeredd listener in their name before anything will happen. Just cut that out of the recommendation.
- Nothing about <content>? For CustomEvents, it shouldn't be a problem to be consistent and say that the <send> element may have one <content> child excluding any namelist and <param>s, and that the event's "detail" property must be set to the child's text contents (or possibly to that content interpreted as JSON).

As I have pointed out before, the 'basichttp' I/O Processor is incompatible with a client-side implementation, but since that Processor is optional it's all right.

I'd like to attract your attention to a couple of recent developments of HTML that deal with sending/receiving events and could inspire SCXML:

Received on Wednesday, 9 January 2013 11:25:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 January 2013 11:25:27 GMT