Re: [scxml] sixth WD of SCXML is published

Kazuyuki Ashimura wrote:
> Hi www-voice,
> 
> The sixth Working Draft of "State Chart XML (SCXML): State Machine
> Notation for Control Abstraction" has been published as follows.

Hello. My name is Greg Beauchesne. I guess I'm new here, but I've been
working on an SCXML implementation of my own and I figured that means I
should probably get in on this list.

So, without further ado...

1. I'm glad that the whole event name prefix issue has been updated to 
use tokens. This had been causing me issues with event names like "up" 
vs. "update".

2. Would it be possible for transition/@event to be of type NMTOKENS 
instead of NMTOKEN? As it stands, if I want to have the same transition 
be taken for two completely different events, with all of the associated 
executable content, I have to copy and paste the entire transition 
definition or otherwise use scripted functions to achieve common 
functionality. I think this would not break anything, since NMTOKEN 
already forbids whitespace. (Although technically I guess it's not 
NMTOKEN anyway, according to the schema in D.1)

3. I also like the new expr vs. non-expr attributes; this really 
clarifies when a string or expression should be used. On <send> and
<invoke>, I would say that @id and @idlocation is inconsistent with the
rest (@idexpr instead of @idlocation would probably match better), but
I realize this is probably for compatibility with previous WDs, not to 
mention that it is the one attribute that acts as an lvalue.

4. Along the lines of the expr/non-expr attributes, I would see
value in something similar for <log>. It seems to me that @label is not
intended to be replacement for @expr (i.e. <log label="test"/> is not
necessarily the same as <log expr="'test'"/>, especially since @expr is
required and @label is not). So maybe something like <log message="My 
message"/>?

If that were the case, though, it would probably get confusing as to 
whether to use @label or @message. What was the intent behind the @label 
attribute?

Alternatively or in addition, I think <log> could support child content 
(at least text nodes) as an alternative to either the @label or @expr 
attributes. <assign> and <data> already do this. For example, this:

<log>A thing happened</log>

....would be the same as this (assuming a compatible scripting language):

<log expr="'A thing happened'"/>

5. Section 9 on IDs does not specify the scope of uniqueness. I know
that the XML ID type specifies that it is unique throughout the
document, but it seems like states/sends/invokes/data model fields would 
all be in different namespaces (not to be confused with XML namespaces). 
I would think it to be pretty useful for an <invoke> or a <send> to 
share the ID of the <state> that contained it. If the intent was to 
forbid this sort of thing, I think that should be explicitly stated.

6. Is the default transition on history states permitted to have 
executable content? The algorithm seems to say no (the transition is 
just used as though it were the history value), while section 3.11.2 
does not say. If the answer really is "no", is there any reason to have 
a <transition> child as opposed to just an attribute with the default 
targets, other than consistency? (i.e. <history default="blah"/> seems 
just as good as <history><transition target="blah"/></history>)

7. The algorithm seems to potentially run into infinite recursion on 
default history state transitions if multiple default history state 
transition targets create a circuit (i.e. it targets either itself or 
another history state that then targets the original history state). A 
potential solution (assuming no executable content from #6 above) would 
be to simply forbid the default history state transition from having a 
sibling history state as a target. There is no reason this would be 
necessary, since A) before the history values are assigned, setting the 
target of H1 to H2 would have the same result as setting the target of 
H1 to the target of H2, and B) all sibling history state values are 
assigned at the same time, which eliminates the default transitions -- 
there is never a time when one sibling history will be using its default 
transition and the other will not.

-------------------
Lastly, here are some proofreading errors:

Section 3.2.2: Last paragraph -- in the text '...an "initial" attribute
or am <initial> element...', I'm assuming "or am <initial>" should be
"or an <initial>".

Sections 4.1.6, 4.3.3, E.1, E.7, G.1: The examples don't appear to have 
been updated for the new expr and non-expr attributes.

Section 10.3.3.1: The XPath in the <assign> is incorrect. 
"city[id='nyc']" should be "city[@id='nyc']".

Section B: addStatesToEnter() uses the "LCA" variable in its history 
state handling, but it's never actually assigned a value. (I expect this 
is from being moved from enterStates() in the previous WD, which means 
that a likely correction is "root".)

Section C: scxml/@initialstate in the example should be scxml/@initial.
-------------------

Those are my comments for now. Thank you for your work on SCXML.

-- Greg

Received on Wednesday, 4 November 2009 07:07:53 UTC