Re: SCXML errata document published

Hi Jim,

[hope you don't mind I Cc the list]

Le jeudi 25 février 2016 à 14:18 -0500, Jim Barnett a écrit :
>    Thank you for your detailed comments.  I think that you have 
> uncovered three errors that need to be added to the errata document, but 
> in the other cases the existing text is correct.   Going through your 
> issues in order:
> 
> 3.2.2  It is true that the specification does not allow an <initial> 
> child on <scxml>, but adding an <initial> child to <scxml> in the 
> algorithm is not a problem because it is done _after_ the document is 
> validated against the schema.  Furthermore the prose makes it clear that 
> this is done only to simplify the statement of the algorithm.

Yes, I understand. It was just to be more clear to an implementer who
would see that <scxml> can contain <state>, <parallel>, <final>, but
*not* <initial> as a traditional <state> would, because it's a *special*
kind of state; without explanation, he may think this is an oversight. I
say that because I was tempted at first to implement <scxml> with the
same implementation as <state>.

> 3.5  For the omitted target attribute, the two important statements are 
> in section 3.13:
> "If the transition does not contain a 'target', its exit set is empty." 
> and "If a transition does not contain a 'target', its entry set is 
> empty. "  Those two statements plus the rest of 3.13 specify the 
> behavior.

Yes, I understand that from an implementer point of view, you should
stick to this precisely defined behavior. But from a user's point of
view, there is no explanation of what it *means* to have no target
attribute.

> In addition, in the informative overview 3.1.5 there is the 
> following statement:  "If the 'target' on a <transition> is omitted, 
> then the value of 'type' does not have any effect and taking the 
> transition does not change the state configuration but does invoke the 
> executable content that is included in the transition."

Yes, this is why I said there was a text implying that we stay in the
same state, but first it is located in a section about types, which to
me was not very related, and second the wording "does not change the
state configuration" was not so obvious. And the wording about the type
having no effect makes you think this has something to do with adding a
type to your transition, while it is not. Indeed, you could completely
omit talking about the type:

        If you omit the 'target' attribute on a <transition>, taking the
        transition does not change the current state configuration but
        does invoke the executable content that is included in the
        transition. Note that this is different from a <transition>
        whose 'target' is its source state. In the latter case, the
        state is exited and reentered, triggering execution of its
        <onentry> and <onexit> executable content.

Well, after trying to reword it three times I almost got back to the
original text, so maybe the wording is not so bad… It's just that the
thing about the type confuses things a bit, I think.

> D. The definition of isAtomicState() should be clear from the definition 
> of atomic states in the text of the specification.

Yes it is clear, it's just that *every* function is defined in the
specification, except this one. What I wanted is just something at the
end of D “Procedures and Functions” like:

        function isAtomicState(state1)
        
        Returns 'true' if state1 is an atomic state. Otherwise returns
        'false'.

Like it is, e.g., for isDescendant(), even if it is quite obvious too.

> D.  'binding' global variable.  This is an error.  As you suggest 
> 'binding' should be set in interpret():
> ...
> binding = doc.binding
> if binding == "early":
>          initializeDatamodel(datamodel, doc)
> ....

OK, right.

> D.  You are right that "Finally call enterStates on the initial 
> configuration" is incorrect.  It should read "Finally call enterStates 
> on the one item list containing the <initial> transition that was 
> created from the 'initial' attribute."

OK, being more specific is better, but the wording still seems to imply
<initial> is a transition, as well as the 'initial' attribute, while it
is a *state*. Maybe something like:

        Finally call enterStates on the one item list containing the
        transition in the document's <initial> state.

> G.1  You are right that the <transition> should have a 'target' 
> attribute, not 'next'.

OK, thanks.

> As for the complexity of the algorithm, implementations can simplify it 
> considerably.  In particular, we put in the explicit sort statements to 
> make it clear that it was important that the list be in the specified 
> order.  I think that the algorithm constructs the list in that order, 
> but we didn't want to rely on that implicit ordering.

OK, thanks for the explanation. Still, has someone really *proved* it? I
think it would be very nice if it was proven so, as one could remove all
the sort operations and simplify things quite a bit.

Thanks a lot for your feedback!
-- 
Benjamin Cama <benjamin.cama@telecom-bretagne.eu>

Received on Friday, 26 February 2016 09:54:00 UTC