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

RE: ISSUE-829: exiting parallel due to external transition [SCXML-LC-Comments]

From: Jim Barnett <Jim.Barnett@genesyslab.com>
Date: Fri, 1 Feb 2013 16:25:53 +0000
To: Voice Browser Working Group <w3c-voice-wg@w3.org>, "www-voice@w3.org" <www-voice@w3.org>
Message-ID: <57A15FAF9E58F841B2B1651FFE16D28101CF53@GENSJZMBX03.msg.int.genesyslab.com>
  The reason for this choice was our desire to remain consistent with UML.  (First of all, the UML state machine notation is widely used and an excellent 'salesman' for scxml, second of all Harel consulted on the UML state notation.)  UML specifies that on a transition between parallel siblings, the entire <parallel> parent is exited and re-entered.  To get that behavior, we use LCCA in place of LCA.   Given that definition, it is natural for a transition that exits and reenters a single child state to have the same behavior.  Transitions that exit and re-enter a state are treated the same way everywhere else as those with separate sources and targets, so we didn't see any justification for adding a special case here.  

As for why 'external' is the default, that's because the definition really does seem to work that way.  When you say "if a transition is marked 'internal' and all its target states are descendents of its source, it behaves like X, otherwise it behaves like an external transition", you're really saying that 'external' is the default and 'internal' can hold only if very specific conditions are met.  Most transitions in most SCXML apps I have seen are a) external - in the sense that their target is not a descendent of their source - and b) don't indicate their type.  If we made 'internal' the default, we'd have the odd case that those transitions would be nominally 'internal' but would behave as external transitions.  

That said, it  makes perfect sense for your GUI to default to 'internal'.

-----Original Message-----
From: Voice Browser Working Group Issue Tracker [mailto:sysbot+tracker@w3.org] 
Sent: Friday, February 01, 2013 9:51 AM
To: w3c-voice-wg@w3.org; www-voice@w3.org
Subject: ISSUE-829: exiting parallel due to external transition [SCXML-LC-Comments]

ISSUE-829: exiting parallel due to external transition [SCXML-LC-Comments]


Raised by: James Barnett
On product: SCXML-LC-Comments

Consider the following:

    <scxml xmlns="http://www.w3.org/2005/07/scxml" version="1.0">
      <parallel id="p">
        <state id="s1" initial="a">
          <state id="a" />
          <state id="b" />
          <transition event="e" target="b" />
        <state id="s2" />
[From Gavin Kistner [phrogz@me.com]]
When initially run, this enters p/s1/a and p/s2.

Because the transition has no type attribute, it defaults to "external". (I personally think this is a terrible default, counter-intuitive to almost every use case I personally envision using SCXML for. Every editor I write will default to explicitly setting this attribute to "internal". I'd love to fork a separate thread about why this defaults to "external".)

Per the specs, external transitions find the LCCA of the transition source and target(s) and then exit and re-enter the states underneath that scxml/state. In this case the LCCA is the root scxml. It is not the 'p' because <parallel> are excluded from the LCCA test.

As such, taking the transition from s1/a to s1/b causes the machine to exit 'a', 's1', and 's2', and even 'p' itself. I find the fact that we exit 's1' reasonable (for an 'external' transition), but I find it surprising that we exit 's2' and 'p'.

Is there a strong reason for using the LCCA instead of the LCA (least common (proper) ancestor of any type)? Is there a strong reason to wish to exit all concurrent siblings (inside a parallel) when re-entering one state?

Received on Friday, 1 February 2013 16:26:20 UTC

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