RE: Shocked by new SCXML Draft

Hi Jim,

 

thanks for your reply. I would like to apologize if my email sounded too
harsh. Please understand that this wasn’t my intention. When I read the
draft my first understanding was that the profiles that have been listed
were a must. I missed the MAY part after the MUST part in the first profile
paragraph. Sorry for that. But apparently I’m not the only one who
understood it that way J

 

A suggestion from my side would be to place the ECMA and XPath profile under
“9.2 Optional Profiles”. That way the draft structure would be “9.1 Minimal
Profile”, “9.2 Optional Profiles”, “9.2.1 ECMAScript profile” and “9.2.2
XPath profile”. That would make the draft more clear at that point.

 

I see now that some of my other remarks (such as the reference to “_data”)
are linked to the ECMAScript profile. Nevertheless the content of the remark
is still valid.

 

Once again, sorry, if my email sounded too harsh,

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

 

 

 

De : www-voice-request@w3.org [mailto:www-voice-request@w3.org] De la part
de Barnett, James
Envoyé : Freitag, 23. Mai 2008 18:06
À : Stefan Maton; www-voice@w3.org
Objet : 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