W3C home > Mailing lists > Public > www-voice@w3.org > October to December 2010

SCXML local transitions

From: <Pierre.Wellner@inficon.com>
Date: Tue, 5 Oct 2010 14:21:34 -0400
To: www-voice@w3.org
Message-ID: <OF7D4C9BC2.2E6EA5F6-ON852577B3.0063CE2F-852577B3.0064A71B@inficon.com>
SCXML transitions are currently defined as external, so when a
transition is executed, its source state is exited.  Has the committee
considered support for local transitions?  For a summary of local
versus external transitions (and how to draw them) see this wikipedia
entry:

http://en.wikipedia.org/wiki/UML_state_machine#Local_versus_external_transitions

Local transitions are particularly useful when default behavior is
specified at a high level.  The problem with high-level external
transitions that cause small changes between lower-level siblings is
that they force the exit and re-entry of the entire tree, even when
the resulting configuration differs little.  Local transitions exit
only the states that leave the configuration, and enter only the
states that are added to the configuration.

As an illustrative use case, consider an ATM with four hard keys
beside its screen, and  that displays an option by each key (e.g "cash",
"balance", "change PIN", and "print balance").  Users can highlight an
option by pressing the associated key, change their highlighted
selection as may times as they like, and then press a big green
"enter" button after they are satisfied with the selection.

In the scxml snippet below there is one state per selectable option.
Each state highlights its option upon entry, and dehighlights its
option upon exit.  One transition per key is specified at the parent
level.


<state id="selectOption"> 
  <transition event="key1" target="cashSelected" /> 
  <transition event="key2" target="balanceSelected" /> 
  <transition event="key3" target="pinchangeSelected" /> 
  <transition event="key4" target="printSelected" />
 
  <state id="cashSelected" >
    <onentry> <log expr="highlight cash" /> </onentry>
    <onexit> <log expr="dehighlight cash" /> </onexit>
  </state>
 
  <state id="balanceSelected" >
    <onentry> <log expr="highlight balance" /> </onentry>
    <onexit> <log expr="dehighlight balance" /> </onexit>
  </state>
 
  <state id="pinchangeSelected" > 
    <onentry> <log expr="highlight pin change" /> </onentry>
    <onexit> <log expr="dehighlight pin change" /> </onexit>
  </state>
 
  <state id="printSelected" >
    <onentry> <log expr="highlight print balance" /> </onentry>
    <onexit> <log expr="dehighlight print balance" /> </onexit>
  </state>
</state>



Because transitions are external, all the options are de-deselected
before a new one is selected.  If these transitions were local, then
only the required option would be de-highlighted before the new one is
selected.


Can the comitee consider adding support for local transitions?
Implementation is not difficult.  The difference is that for local
transitions, enterStates() and exitStates() would add fewer states to
their OrderedSets.  enterStates() would add only the inactive states
up to the lowest common active ancestor.  exitStates() would add only
the active states up to but not including the lowest common active
ancestor.

Best regards,

Pierre Wellner
Inficon


***********************************************************************
NOTICE: - This message including any attachments is intended only for the 
use of the designated recipient(s) named above and may contain 
confidential information protected by law.  If you are not the intended 
recipient, you are hereby notified that any disclosure, copying, 
distribution, or the taking of any action in reliance on the contents of 
this information is strictly prohibited.  If you have received this 
transmission in error, please notify the sender immediately by e-mail and 
delete the original message including any attachments.
*********************************************************************** 
Received on Wednesday, 6 October 2010 08:51:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 6 October 2010 08:51:13 GMT