Comments on the SCXML specification

Hi,

First, I am new to this list. Some months ago, when the SCXML
specification was still a draft, I read it and try to implement a subset
of it for a project I am working on. During this period, I spotted a few
mistakes and ambiguities that I want to share today. Sadly, it is a bit
late now that it has become a proposed recommendation, but I hope it
will still be useful. Following is the list of what I wrote down and
which is still present in the final version.


3.2.2: <initial> is not listed as a possible child to <scxml>, although
such child is present when converting the "initial" attribute of an
<scxml> tag, as explained in the "interpret()" procedure definition in D
(and also in 3.1.4):

        In order to interpret an SCXML document […] convert initial
        attributes to <initial> container children with transitions to
        the state specified by the attribute.

Maybe it is not allowed to put it there *before* the transformation
happen? (I think it is so so that no executable content from an initial
document state can exist, is it?) It should be clearly stated that it is
not possible if so, I think.


3.5: The "target" attribute of a <transition> is not required, but I see
almost nowhere what it means when "target" is omitted. In 3.1.5 about
transition "type" (which is not where I look when looking for something
about the "target" attribute), the last paragraph seems to imply that a
targetless transition transitions to itself, but I am not sure. I think
it should be specified here more clearly. The same is true for other
optional attributes that look not so optional at first, e.g. a "target"
for <send> in 6.2, even if it is specified later that a targetless send
must place the event on the external queue of this session (C.1).


D: In the datatypes and function/procedure definitions, every function
used in the following algorithms is defined except for
"isAtomicState()". Is it too obvious to be defined, or should it still
be added?


D: In the global variables definitions, there is "binding", which is
seldom used; in "interpret()", it is the "binding" attribute of the
document that is taken into account, while in "enterStates()" "binding"
is indeed used, but not defined anywhere. Should "binding" be set from
the doc value in "interpret()" to allow its use in "enterStates()"?


D: In the "interpret()" procedure, it is not clear that
"enterStates([doc.initial.transition])" has for argument the list of the
lone document's (top) initial state transition, which is created from
the "initial" attribute. Well, it is more clear when you have the
aforementioned transformation clearly in your head, but at first, it
looks a bit weird as there does not seem to be any "initial" state's
transition to choose from. Furthermore, the text specifies:

        Finally call enterStates on the initial configuration

which is not even correct as enterStates() is called with *transitions*
as argument.


G.1: In Main.xml, state "Test2" has a transition with a "next"
attribute, which I think is a typo for "target".


Finally, in the implementation algorithm (D), it looks to me like one
could relax the ordering constraint of the variables "configuration" and
"statesToInvoke". My goal is to simplify the implementation, by e.g.
using simple list so that I do not have to sort it every time before
using it. The rationale behind that is that states are always added to
these two list in document order (= entry order), and states are removed
from it either entirely (when clearing) or in reverse document order
when e.g. exiting child states. I can not prove it, but the way it
looks, it seems that just by the way these list are modified, the states
will always stay in document order, thus we do not need to sort them
before using them. For "statesToInvoke", the relevant places are:

      * mainEventLoop() where it is used sorted, and then cleared
      * exitStates() where some states are deleted
      * enterStates() where states are added in document order
      * The last to procedures being called from microstep(), which
        enters and leaves states in a way which seems to respect
        document order

As I said, it is just a feeling I have, and for my simple implementation
without compound states nor history, it obviously works. It looks like
it could work the same for the full implementation. I would like to hear
from someone on this, even if the emphasis of your implementations may
not be trying to avoid a sort() on a list for optimization.

The reason I am trying to "optimize" this way is because my
implementation is not really an SCXML interpreter, but a static
transformation (through XSLT) from SCXML to C, using the simplest
list/queue implementations as possible, having a lot of things
statically defined. This may not be the goal of SCXML, but the
specification served me well as a guide for a flexible state machine
implementation with "proven" interpretation.

Thanks for the good specification anyway, which helped me well, and I
hope will continue if I implement more features. I hope my remarks were
helpful.

Regards,
-- 
Benjamin Cama <benjamin.cama@telecom-bretagne.eu>

Received on Friday, 5 June 2015 10:46:51 UTC