comments on SCXML W3C Working Draft 24 January 2006

comments on SCXML W3C Working Draft 24 January 2006

SCXML is intended to provide an (xml-based) programming language to 
support, among other things, telecom call control - although you are 
clearly committed to SCXML as a solution you should be aware of what I 
see as being drawbacks to this solution

overall issue:

SCXML adopts much of Harel Statecharts - Harel Statecharts is intended 
to be, first and foremost, an abstract design language - as such the 
language encourages deferral of implementation decisions by supporting 
unconstrained event propagation (event broadcast) and non-determinism - 
however, SCXML is intended to be a (telecom call control) programming 
language - as such programmers should expect to be able to use the 
language to eliminate unwanted non-determinism and exert control over 
event propagation

specific issues:

an event from the environment is not explicitly associated with a call 
(leg), however, the notion of a call is central to telecom call control 
- instead events must be implicitly coded to carry information 
associating an event with a call

delayed events are not specified as timed transitions - instead the 
delay duration info is buried in a sent (but not really sent) event - 
this means that a delayed event cannot be portrayed graphically, 
diminishing the utility of statechart's graphical syntax

arriving events that aren't explicitly handled are silently ignored - 
this is dangerous for telecom features

the language does not support parameterized statecharts which restricts 
statechart re-use

the language does not provide enough control over otherwise 
non-deterministic transition execution - the language provides only two 
priority rules

one transition priority rule is not reflected by the graphical syntax 
(the 'text order' rule) which diminishes the utility of the graphical 
representation

the language does not support dynamic creation of statecharts which 
complicates development of features such as n-way call-waiting, n-way 
conferencing

broadcast events are seen by all submachines in a statechart which can 
lead to lack of modularity between submachines (tight coupling)

where i'm coming from:

five years ago, the research group I'm part of at AT&T was motivated 
for the same reason you were to come up with a telecom feature control 
language for use in a home-brew VoIP application server - we also took 
a close look at the various statecharts dialects but rejected them for 
the some of the reasons I cite above - our eventual solution took the 
form of a statecharts dialect called ECharts that we developed 
ourselves - the ECharts language was used to program the consumer VoIP 
feature set marketed by AT&T as AT&T CallVantage - ECharts is now used 
within AT&T for a number of next-generation feature programming 
research projects - the ECharts language was recently granted open 
source status by AT&T under the Common Public License - we're just 
finishing up the user manual prior to releasing ECharts publicly, 
however we've published a number of papers describing different aspects 
of the language, including a comparison of the language with other 
popular statecharts dialects -  you're invited to visit 
http://www.echarts.org to obtain a draft copy of the user manual and 
the aforementioned papers

--
Gregory W. Bond
AT&T Labs - Research
180 Park Avenue, Rm. D273, Bldg. 103
Florham Park, NJ, 07932-0971, USA
tel: 973 360 7216 fax: 973 360 8091