- 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 UTC