W3C

SCXML: Last Call Disposition of Comments

This version
Tue Feb 25 2014
Editor
Jim Barnett, Genesys

Abstract

This document details the responses made by the Voice Browser Working Group to issues raised during the Last Call period (beginning August 1, 2013 and ending November 7, 2013). www-voice.org( archive) mailing list.

Status

This document of the W3C's Voice Browser Working Group describes the disposition of comments as of February 25, 2014 on the Last Call State Chart XML (SCXML): State Machine Notation for Control Abstraction.It may be updated, replaced or rendered obsolete by other W3C documents at any time.

For background on this work, please see the Voice Browser Working Group Charter.

We received many comments on the First Last Call Working Draft and as a result made many substantive changes in the Second Last Call Working Draft. This document reflects only comments that we received on the Second Last Call Working Draft because the Second Last Call specifically requested that any remaining outstanding issues from the First Last Call be resubmitted in order to be considered for the Second Last Call.

Comment summary

Legend:

ACCEPTED Comment was accepted
REJECTED We did not make the requested change.
CLARIFICATION Comment only required a clarification.
DROPPED The feature in question was dropped from the spec.
DEFERRED The feature in question was deferred to a future version.

Results:

ID Title Date Opened Last Updated Disposition Acceptance Related Issues
ISSUE-835 Miscellaneous Typos and other Editorial Comments 2013-11-11 2013-11-11 ACCEPTED IMPLICIT NONE
ISSUE-836 Comments from the MultiModal Group 2013-11-12 2013-11-11 ACCEPTED IMPLICIT NONE
ISSUE-837 PFWG review of SCXML 2013-11-12 2013-11-11 CLARIFICATION IMPLICIT NONE
ISSUE-838 Request for invocation-started event 2014-01-03 2014-01-15 DEFERRED EXPLICIT NONE
ISSUE-839 Suggestions for onentry/onexit tags 2014-01-03 2014-01-15 REJECTED IMPLICIT NONE
ISSUE-840 More suggestions for onentry/onexit tags 2014-01-29 2014-01-29 CLARIFICATION EXPLICIT NONE
ISSUE-841 What is the state configuration during onentry/exit is executed? 2014-02-23 2014-02-23 CLARIFICATION IMPLICIT NONE
ISSUE-842 Invoking on stable configuration but sending on entry 2014-02-25 2014-02-25 CLARIFICATION EXPLICIT NONE

Issue detail


ISSUE-835 - Miscellaneous Typos and other Editorial Comments

Tracker (W3C Member only):

ISSUE-835

Opened: 2013-11-11

Last Updated: 2013-11-11 04:52

State: closed

Description:

(15 minor editorial comments, plus some comments on the IR tests.)

Notes:

Related e-mails:


ISSUE-836 - Comments from the MultiModal Group

Tracker (W3C Member only):

ISSUE-836

Opened: 2013-11-12

Last Updated: 2013-11-12 12:45

State: closed

Description:

The W3C Multimodal Interaction Working Group has reviewed the second LCWD of
SCXML [1] and believes that it is a very suitable implementation language
for Interaction Managers (IM's) in systems conforming to the Multimodal
Architecture (MMI Architecture) specification [2]. In multimodal systems,
IM's coordinate the activities of Modality Components (MC's), such as
speech, GUI, and gesture interpretation components, among others. SCXML is
an excellent complement to the event-based MMI Architecture since events are
one of the basic concepts of SCXML and most SCXML transitions are triggered
by events. These could include, for example, MMI Life Cycle events coming
from MC's. The declarative nature of SCXML also greatly simplifies development of
multimodal applications which may be complex and involve the interaction of
a number of MC's, each encapsulating additional complex functionality of
their own.

[1] SCXML: <http://www.w3.org/TR/2013/WD-scxml-20130801/>http://www.w3.org/TR/2013/WD-scxml-20130801/
[2] MMI Architecture and Interfaces: <http://www.w3.org/TR/mmi-arch/>http://www.w3.org/TR/mmi-arch/

Best regards,
Deborah Dahl
W3C Multimodal Interaction Working Group Chair

Notes:

Related e-mails:


ISSUE-837 - PFWG review of SCXML

Tracker (W3C Member only):

ISSUE-837

Opened: 2013-11-12

Last Updated: 2013-11-12 12:49

State: closed

Description:

Below are comments prepared by the Protocols and Formats Working Group
on "State Chart XML (SCXML): State Machine Notation for Control
Abstraction" Last Call Working Draft of 1 August 2013
http://www.w3.org/TR/2013/WD-scxml-20130801/. Consensus to send as PFcomments is archived at
https://www.w3.org/2013/10/16-pf-minutes.html#item02.

This is an unusual review as we are not talking about accessibility as a
specific "this is an inaccessible feature" however, but the issues,
although more global, are just as important. Overall we are concerned
with how people with hearing, speech and cognitive impairments are going
to be affected by these applications and what requirements are necessary
so that they can be used by people with different user scenarios. For
example, speech triggered applications will need an option to type text
etc. In the mean time we suggest the following:
*Issue one.* We would like to see a standard way to reach a human
operator for additional assistance and accessibility support.
Many people a struggle with critical services and help because of
complex phone answering systems. People with even mild hearing, speech
or cognitive challenges are especially disadvantaged and can be excluded
from these services.

As many emergency and critical services are now using these automated
answering systems, we need to make them as easy as possible to use on
any phone. Further, people abilities vary and deteriorate at times
stress or of ill health. People therefore need to be familiar and
comfortable with a standard way to reach an operator, so that they can
easily get service in times of stress or panic. We therefore propose to
standardize how a user can reach a human on all phone systems. We
believe this would make automated phone systems usable by as many people
as possible.

We propose that a digit or combination (such as the "zero" digit) be
standardize for reaching a human operator on all phone systems with
automatic menus. On any answering system, pressing a "0" would take you
to a human operator.

For example if the zero digit was standardized to reach a human, then in
any conformant system:

  * a, At any time on any system "0" will take the user to a human operator,
  * b, the "zero" digit can not be assigned for anything else and hence can not support a follow on menu, and
  * c, in every system file there is a default extension for the "zero" digit identified, without which the file is invalid and will not work at all.


Anecdotal evidence: Places that I have not managed to reach a human
operator after five attempts include the police and my doctors
office. Typically it takes me three of four attempts to reach the right
extension at my health service!

*Issue two*. We suggest standardizing error recovery from the user
perspective.
With these systems often people with disabilities are more likely to
make errors. We then get thrown off the line (see above ) and need to
start again. There should be a easy way to recover from an error, such
as when ever there is an error the user has an option to either

  * return to the main menu,
  * the previous menu or
  * a human operator for help (most important)

FYI we are putting together a task force to addressees accessibility and
cognitive disabilities. If this is of interest to any of your members
please let us know!
--

Michael Cooper
Web Accessibility Specialist
World Wide Web Consortium, Web Accessibility Initiative
E-mail cooper@w3.org <mailto:cooper@w3.org>
Information Page <http://www.w3.org/People/cooper/>

Notes:

Related e-mails:


Issue detail


ISSUE-838 - Miscellaneous Typos and other Editorial Comments

Tracker (W3C Member only):

ISSUE-838

Opened: 2014-01-20

Last Updated: 2014-01-21 04:52

State: closed

Description:

as we continue to use SCXML for various applications, there is one deficiency
that always bugged us. Consider that you have a state that will invoke
something and you'd like to send some event to it right-away. You cannot use
<send target="#_invokeid"> in an onentry element as the invoker will not yet
exist, it is only invoked when a stable configuration is reached (see
procedure mainEventLoop in the draft). Thus forcing you to use a delay
attribute.
[...]
Is anyone else bugged by this behavior and resorted to the delayed send
idiom, is there something more straight-forward or did we misinterpret the
SCXML draft at some point?

Notes:

Related e-mails:


ISSUE-839 - Allow only Single onentry, onexit elements.

Tracker (W3C Member only):

ISSUE-839

Opened: 2014-01-20

Last Updated: 2014-01-21 04:52

State: closed

Description:

We are working on an SCXML-Editor. Between reading the draft and parsing the scxml we noticed that onentry/onexit tags can occur 0 till inf times for a state.

Would it not be better to have 0 or 1 occurrence?

That would avoid the question: How can I exit a state multiple times without re-entering before?

The code from each handler would then be concatenated.

Please note either way:
The final state 3.7.2 ( http://www.w3.org/TR/scxml/#final )
considers one entry of onentry/onexit tags only.
While the schema does not:
http://www.w3.org/2011/04/SCXML/scxml-core-strict.xsd

Notes:

Related e-mails:


ISSUE-840 - More suggestions for onentry/onexit elements.

Tracker (W3C Member only):

ISSUE-840

Opened: 2014-01-20

Last Updated: 2014-01-21 04:52

State: closed

Description:

Your reasoning is completely valid and understood. My only concern is
the semantic about onexit/onentry.
Even if it is well defined in the current version, I can't deny that it
is a bit unnatural to call a second onexit block
My suggestions to combine functionality and modularity would be as follows:
<onentry>
   <action> Code of the first onentry block </action>
   <action> ... 2nd entry block </action>
</onentry>

Variation:
Define actions in LLCA (or separate file for re-usage):
<actions>
   <action id="a1"> Codeblock </action>
   <action id="a2"> Codeblock </action>
</actions>

We just reference to the actions:
<onentry>
   <action id="a1" />
   <action id="a2" />
</onentry>

From here we have a couple of advantages:
- Code block may be reused in the same file
- We may define all code blocks for onentry/onexit in separate file and
share this between different statecharts.
- The semantic is a bit cleaner (Maybe that is a personal view)

I am very aware of my inexperience when it comes to xml/statecharts and
I am fine with what ever solution you come up with.

Notes:

Related e-mails:

ISSUE-841 - What is the state configuration during onentry/exit is executed?

Tracker (W3C Member only):

ISSUE-841

Opened: 2014-02-24

Last Updated: 2014-02-24

State: closed

Description:

Hello,

When we have S1 -> S2, we execute: onexit S1, T, onentry S2. My
question is, are we already in S2 during execution of the entry
handlers and are we still in S1 during onexit is running?

Notes:

Related e-mails:

ISSUE-842 - Invoking on stable configuration but sending on entry

Tracker (W3C Member only):

ISSUE-842

Opened: 2014-02-25

Last Updated: 2014-02-25

State: closed

Description:

Hi again,

as the invoke semantics turn out to be a major source of confusion for SCXML authors, we are scratching our heads as to why the group decided for this particular semantics. Can we read up on the rationale somewhere?

Best regards
Stefan

Notes:

Related e-mails: