Re: [scxml] sixth WD of SCXML is published

Hello. I have some more comments on the SCXML WD:

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.

-

2. Section 4.1.2 says that send/@namelist separates its datamodel 
locations by space, but this is potentially incompatible with more 
complex expressions. For example, the XPath expression:

a/b[@attr='some value']

...would be improperly broken at a whitespace boundary. The actual 
method of specifying multiple names should probably be scripting 
language-dependent. XPath has sequences (well, 2.0 does, anyway), 
ECMAScript has arrays, etc.

-

3. The definition for <datamodel>/<data> is somewhat unclear. Section 
5.1 says "...all instances of the <data> element are created and 
initialized when the state machine is instantiated and may be accessed 
from any state at any time." whereas 5.2 says "All <data> tags are 
evaluated exactly once, at load time. Implementations thus MUST evaluate 
<data> elements at load time but MAY do so in any order they choose."

Does this mean, then, that if I have something like <data id="someValue" 
expr="random()" /> that all instances of a state machine in a particular 
session will end up with the same value for "someValue" but that it may 
differ if the SCXML document is reloaded?

If so, I assume the recommended alternative is to initialize the data in 
scxml/initial/transition ?

-

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.

-

5. parallel/history[@type = 'shallow'] -- Does it do anything useful? If 
not, could it be made useful by digging down a little deeper to the 
nearest children of a compound <state>? (Or does this stray too far from 
Harel semantics?)

-

6. What happens if a <history> with no default transition is the target 
of a transition? In the algorithm, it looks to me like this will create 
an invalid state configuration. Maybe this should have the same defaults 
that @initial does when unspecified?

-

7. When errors are raised at document load time, what is to be done with 
them? Implementation-defined? I ask because they are formatted in the WD 
as though they should be treated like dynamic errors (i.e. fed back to 
the state machine as an event) but this is not possible without a state 
machine instance. If I'm understanding correctly, the handling of these 
two error types is *very* different -- static (document load) errors are 
likely thrown as normal exceptions in whatever the implementation 
language happens to be (e.g. Java exceptions), and dynamic (runtime) 
errors are handled internally within the state machine without being 
directly reported to the external environment (and potentially ignored 
if there are no transitions to handle them).

-

8. I'm a little confused about scxml/@exmode='strict'. Section 3.1.1 
says that the interpreter should raise "error.unsupportedelement" when 
it encounters unrecognized executable content, whereas section F says 
unrecognized custom executable content must raise an "error.badfetch" 
event with scxml/@exmode='strict'. However, this is the only place 
"error.badfetch" is mentioned. It also says 
"error.unsupported.<element>" for unsupported SCXML elements. Which of 
these three is it? (I understand there are going to be inconsistencies 
of this nature in a work-in-progress, but I'm wondering which is the 
most likely/recent candidate.)

Also, regardless of whichever error code it happens to be, I'm not sure 
whether it's OK for me to make it a static error or if I have to wait 
until runtime execution hits that point to raise the error. None of 
sections 3.1.1, 3.12.6, or F give any clue if it's supposed to be static 
or dynamic (or implementation-defined).  At the moment, I just abort 
compilation with a static error, since all possible custom executable 
elements are known at compile time. I would guess implementation-defined 
is the way to go, since nowhere does it say in the WD when custom action 
elements must be bound to implementations (they could be bound pre- or 
post-document load, or even dynamically in regards to the needs of the 
document).

-

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 
(thus bootstrapping directly into a particular state configuration 
rather than finding a way there from the initial state via the defined 
transitions).

Obviously, things like serialization format and such would be 
implementation-defined, but I ask because there are semantic 
implications in how <onentry> and such might work. My current plan for 
my own implementation is just that executable code in <onentry> can 
access some extension variables and functions to determine if it's being 
entered normally or entered as part of a serialized load.

My guess would be "No, there are no plans for this, and it's outside the 
scope of the basic SCXML definition anyway." That's also fine, in which 
case I guess I'm looking for any best practices suggestions.

-

That's it for now. Thanks for reading.

-- Greg

Received on Wednesday, 11 November 2009 06:40:24 UTC