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

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

From: Voice Browser Working Group Issue Tracker <sysbot+tracker@w3.org>
Date: Fri, 01 Feb 2013 14:50:59 +0000
Message-Id: <E1U1HxD-0000fk-Ur@tibor.w3.org>
To: w3c-voice-wg@w3.org,www-voice@w3.org
ISSUE-829: exiting parallel due to external transition [SCXML-LC-Comments]

https://www.w3.org/Voice/Group/track/issues/829

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>
        <state id="s2" />
      </parallel>
    </scxml>
[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 14:51:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 1 February 2013 14:51:02 GMT