Shocked by new SCXML Draft

Hi everyone,

 

please let me introduce myself: My name is Stefan Maton, founder of Sidéma,
a Belgian software development outsourcing company. Since August last year
I’ve been working on a C++ version of the SCXML draft supporting what I call
a simple view of the SCXML draft. I’ve been working with voice recognition
based picking applications since several years (one of Ford Motor Company’s
biggest European Warehouses is running my software). I’ve also experience
with AI systems specially targeted for computer games.

 

Since the target platforms of Simple SCXML (SSCXML) is Win32 and WinCE, it
has been implemented to be easily usable and fast. Due to the specific
platforms (specially WinCE and thus handhelds) and application areas
(picking applications and computer games) any JIT interpretation of the
scxml tree is a big no-no. SCXML therefore translates the scxml nodes into
specific classes. Also, since speed and memory footprint are important,
there is currently no link to Ecmascript within SSCXML. Ecmascript can be
and is slow when interpreted on PDAs, and is certainly not used in game
development (specially the AI field of game development).

 

Currently I have a ongoing beta test of the first version of SSCXML which
should be released in a couple of weeks.

 

Before I come to my reaction to the current draft, I would like to express
that I really like the work you do. The February 2007 draft was very good
and allowed to implement more than 90% of what is actually needed in real
business world.

 

That said, I took a look at the current version of the SCXML draft today and
I must admit that I’m a bit shocked about the even deeper linkage of
Ecmascript with SCXML.

 

Here’s what I think of the new or changed elements of the current draft:

 

Pros:

-          Naming of scxml and _name: Useful to quickly identify the scxml
that has been loaded.

-          Changing name of <data> to id: It’s more conformant with the rest
of the identification schemes of scxml.

 

Cons:

-          Making version of <scxml> required: Doesn’t make any sense if the
only legal value is “1.0”. An instance should return “1.0” if no version is
given. Also, why link the version attribute to the version of the SCXML
definition (your draft when released) and not to the version of the actual
state machine?

-          Profile of <scxml> : Although it might sound interesting to tell
the application which modules are needed to run a given scxml, you must be
aware that the scxml descriptions are written for a specific application.
You cannot run a voice recognition scxml with an application which regulates
traffic lights. Also, most, if not all, scxml descriptions rely on data
injected by the application (through external sensors) or provided by
themselves in case of <assign> and/or <data>. I currently see no state
machine working without any data. Hence a “core” profile doesn’t really make
sense as you always rely at least on the “ecma” profile.

-          _event as system variable: Within a transition it doesn’t really
make sense to use “_event.name==abc” to recognize an event. Unfortunately,
relying more and more on ecmascript and the definition of the different
expression evaluations, you’re forced to use _event as a base to create a
valid expression that can be evaluated. But this makes the code longer than
necessary. The event attribute of <transition> should not be an expression.

-          _data to access datamodel: Excuse me… but have you read your
examples created with this draft? Using _data to access the datamodel does
increase the scxml file considerably. Consider a data called “a” in your
datamodel. Which other data could be meant when you write “a” in an
expression? Also, if you want to be consistent with your idea, when doing a
<send> with namelist, you would have to write “_data.a _data.b _data.c”
instead if “a b c”…

-          Conformance only if…: I absolutely understand that you have to
include some criteria to determine whether yes or no an scxml interpreter is
conformant. Unfortunately, the draft has Ecmascript all around the place,
even stating that Ecmascript is necessary to declare an scxml interpreter
conformat. Well… it’s ok for an interpreter as are the java implementations
of your draft. But an implementation like SSCXML, which is more an executor
than an interpreter, there is no real need for Ecmascript. In fact, in game
development, one would rather use Lua or Python than Ecmascript
(Javascript). 

 

Not clear:

-          Sendid of <send>: I don’t really grasp the idea of this
attribute. Will this set a value into the data model? If yes, why not do
this with an <assign> executable being a child of the <send>? Or will this
be attached to the sender id which can be passed to the event handler?

-          _sessionID: Can be useful but in most cases this will be
meaningless for other cases than logging? I’m not sure where to use this in
a meaningful way.

 

Suggestion:

-          Src in <datamodel>: It would be interesting in having a src
attribute directly within datamodel. I’ve implemented this into SSCXML. The
reason is that you can specify data (shared or user specific) directly at
the root (instead of embedding it into a <data>-tag). In the same time, this
would allow data overloading. An example would be:

within scxml:
<datamodel src="Data/Userdata.xml">
      <data id=”grammar” expr=”pick.bnf”/>
      <data id="picks" src="Data/DMSource2.xml"/>
</datamodel>

within Userdata.xml:
<datamodel>
    <data id=”name” expr=”Stefan”/>
    <data id=”language” expr=”german”/>
    <data id=”mic_gain” expr=”1.0”/>
</datamodel>

within DMSource2.xml:
<pick>
    <position>11-C</position>
    <amount>1</amount>
    <unit>Stück</unit>
</pick>



-          Decouple Ecmascript and SCXML: Looking at the different
conditions and expressions that can be embedded within the scxml, there is
no real need to force the SCXML standard to use Ecmascript. In fact any
expression parser which can handle normal and boolean expressions and which
can hold a set of data is ok. The only specification you need to give is the
way the data is represented when attaching it as a namelist in <send> or as
a return value when a expr is evaluated within an <assign>. By decoupling
Ecmascript and SCXML (and implicitly XPath) the draft would be much more
flexible since not only targeted at the java platform.

 

I can understand if you’ll see this mail as just another mail from a user
who is not happy about the changes that have been made by you. But to be
honest, I feel rather concerned about all this since part of my business
will rely on this. As far as I know I’m (or I’ll be in the next couple of
weeks) the only provider of an implementation for C++ on Win32 and WinCE of
this draft. At least, no other provider pops up on different search engines
when looking for “scxml c++”. You can take a look at my implementation here:
http://www.sscxml.com

 

Also, I’m seeing the potential of this standard in different business areas
of application and game development.

 

Thank you for your attention,

Stefan Maton

---------------------------------------------------

Sidéma

Rue Lefin 4, 4860 Pepinster, Belgique

Web: http://www.sidema.be

Email: maton@sidema.be

GSM: ++32 (0)494 / 11.53.65

TVA BE 0713.367.395