RE: Shocked by new SCXML Draft

Stefan, 

We will reply to your comments in more detail later, but I would like to clarify one thing:  the whole purpose behind introducing profiles into SCXML was precisely to decouple the language from specific data models and give implementations the choice of what they want to support.  Neither the Minimal profile nor the XPath profile require support for ECMAScript.  Only the ECMAScript profile requires support for ECMAScript and there is no requirement that your implementation support that profile.  

 

We also intend for implementations to be able to define their own profiles if they want to introduce new data models.  If you look at the Shale example in appendix E2, you will see that it uses an 'el' profile, which is not defined in the SCXML specification.  This is a extension profile that was built by an Apache Commons user to allow him to use EL as his data model language.  

 

We haven't not yet decided which profiles will be mandatory from a conformance standard (well, except for the minimal profile), but in general the point of a profile such as the ECMAScript profile is to state:  IF you support ECMAScript, then this is how you should do it.  We are trying to give implementations flexibility to choose their own data models while preserving interoperability among those that choose the same model.  

 

 

- Jim

 

________________________________

From: www-voice-request@w3.org [mailto:www-voice-request@w3.org] On Behalf Of Stefan Maton
Sent: Thursday, May 22, 2008 7:25 AM
To: www-voice@w3.org
Subject: 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