RE: [scxml] sixth WD of SCXML is published

Greg,
  We will reply to the rest of your comments as we have time to review
them.  Here are responses to a few of them:

5. Section 9 on IDs does not specify the scope of uniqueness
>> The section states:  "The values of all attributes of type "id" MUST
be unique within the session."  

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
>>  We will look at this more closely, but in general SCXML and all
other state machine languages are so rich in possibilities for infinite
loops that we can never hope to eliminate all of them.

And from your email of Nov 11

1. In section 3.5.2, where it says "the 'target' of the transition must
be a descendant of the <initial> element's parent <state>", was it
actually intended to say "descendant" and not "child" here? I ask
because if it is actually supposed to be "descendant", then there are
some issues that may need to be addressed regarding <initial> and
<parallel>. I can elaborate, but I want to make sure this is the case
first.

>> yes, the intent was 'descendant', so we would like to hear about the
issues with <initial> and <parallel>

4. What are the semantics of the in() predicate in any of the
intermediate places where executable content is used? What I mean by
this is that just about everywhere that executable content is used
except for transition/@cond, the current state configuration is in the
middle of being modified (onentry, onexit, (state |
parallel)/transition, initial/transition).
If the answer here is "add/remove states in the configuration when the
algorithm says so," then OK. I just wanted to make sure, since 8.1,
10.2.5.1, and 10.3.4.1 don't say anything about this.

>> Yes, the intent is to add/remove states following the algorithm.

9. Are there any plans for state machine instance serialization? i.e. I 
want to take a running instance, save its configuration, history states,

event queue, etc. to a byte array, and then restore it at a later time

>> We have discussed this and think it's out of scope, at least for the
first version of the spec. We expect that most implementations will
support something like this, and are interested in suggestions for
things that we could add to the spec to make serialization easier, but
we don't see the need for a standard serialization format at the moment.

= Jim Barnett

-----Original Message-----
From: www-voice-request@w3.org [mailto:www-voice-request@w3.org] On
Behalf Of Greg Beauchesne
Sent: Sunday, November 01, 2009 10:02 PM
To: VoiceBrowser
Subject: 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



					
-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

Received on Wednesday, 11 November 2009 21:16:52 UTC