W3C home > Mailing lists > Public > www-voice@w3.org > January to March 2011

[scxml] semantics of targetless transition versus Rhapsody Static Reactions

From: Jacob Beard <jbeard4@cs.mcgill.ca>
Date: Tue, 04 Jan 2011 16:09:00 -0800
Message-ID: <4D23B69C.60503@cs.mcgill.ca>
To: www-voice <www-voice@w3.org>

I have some questions about the semantics of targetless transitions as 
defined in the SCXML specification versus the semantics of Static 
Reactions described in "The Rhapsody Semantics of Statecharts".

First of all, the SCXML spec says here 
<http://www.w3.org/TR/2010/WD-scxml-20101216/#transition> that a 
targetless transition "is equivalent to an event handler in Harel State 
Table notation". Unfortunately, I have not been able to find a reference 
to an "event handler" in "The Rhapsody Semantics of Statecharts" or "The 
STATEMATE Semantics of Statecharts". However, both papers describe 
Static Reactions, and the semantics seem to be similar to targetless 
transitions in SCXML. In drawing a comparison to Harel Statecharts, 
would it be better for the SCXML specification to use the term "Static 
Reaction" as opposed to "event handler"?

Second, in "The Rhapsody Semantics of Statecharts", in Section 8, "The 
Basic Step Algorithm, Harel states that Compound Transitions are given 
priority over Static Reactions. What I was hoping someone could confirm 
is that the Algorithm for SCXML Interpretation doesn't respect this 
constraint. So, given the following SCXML snippet, if we are in state 
"foo", then on event "bar", doSomething() will be triggered and the 
statechart will stay in "foo":

<state id="foo">
<transition event="bar">
<transition event="bar" target="bat"/>

The reason for this is that transitions are selected with priority based 
on document order, regardless of whether or not they have a target. This 
is my understanding of the logic in function selectTransitions.

I'd appreciate any guidance anyone can offer. Thanks,

Received on Wednesday, 5 January 2011 00:10:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:07:42 UTC