Re: Comments on the SCXML specification

Hi Benjamin,

I've not been spending time on this recently, but my implementation tries
to stay very close to the interpretation algorithm lined out in the spec:
https://github.com/zjnue/hscxml/blob/master/src/hsm/scxml/Interp.hx
Perhaps you will find answers there to some of your questions - for
instance, the isAtomic filter criterion.
However, what may be most interesting to you, is that I have also skipped
some of the sorting steps you mention and it does not seem to affect the
tests, so it may very well be redundant (I stand to be corrected on that).

Hope it helps,
Zjnue

On Wed, Jun 3, 2015 at 9:28 PM, Benjamin Cama <
benjamin.cama@telecom-bretagne.eu> wrote:

> 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>
>
>
>
>
>