SCXML: Last Call Disposition of Comments
- This version
- 24 March 2015
- Editor
- Jim Barnett, Genesys
This document reflects all issues raised since the publication of the Second Last Call Working Draft on August 1, 2013. No issues prior to that point are included 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. Comments were provided by Voice Browser Working Group members, other W3C Working Groups, and the public via the www-voice.org( archive) mailing list.
This document of the W3C's Voice Browser Working Group describes the disposition of comments as of 24 March 2015 on the 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.
| 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-843 | Definition of entry set | 2014-03-07 | 2014-03-07 | CLARIFICATION | EXPLICIT | NONE |
| ISSUE-844 | History transition executable content - when is it executed? | 2014-03-24 | 2014-05-22 | ACCEPTED | IMPLICIT | NONE |
| ISSUE-845 | Child states exited, not re-entered after targetless transition in parent state | 2014-03-25 | 2014-05-22 | ACCEPTED | IMPLICIT | NONE |
| ISSUE-846 | How many transition tags are allowed under initial? | 2014-04-27 | 2014-05-22 | CLARIFICATION | IMPLICIT | NONE |
| ISSUE-850 | SCXML Algorithm minor markup tweaks | 2014-06-28 | 2014-08-01 | ACCEPTED | IMPLICIT | NONE |
| ISSUE-851 | Interpretation Algorithm calls some() on an OrderedSet | 2014-06-24 | 2014-08-01 | ACCEPTED | IMPLICIT | NONE |
| ISSUE-852 | Algorithm bug in addDescendantStatesToEnter? | 2014-10-11 | 2014-10-14 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-853 | Paste-o in spec?? | 2014-10-18 | 2014-10-20 | ACCEPTED | IMPLICIT | NONE |
| ISSUE-854 | Discrepancy in normative XPath references (XPath 1 and 2)? | 2014-10-18 | 2014-10-20 | CLARIFICATION | EXLICIT | NONE |
| ISSUE-855 | Question regarding the meaning and purpose of type 'location expression in namelist and param location attributes | 2014-10-28 | 2014-10-31 | CLARIFICATION | EXLICIT | NONE |
(15 minor editorial comments, plus some comments on the IR tests.)
DISPOSITION=ACCEPTED
ACCEPTANCE=IMPLICIT
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
DISPOSITION=ACCEPTED
ACCEPTANCE=IMPLICIT
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/>
DISPOSITION=CLARIFICATION
ACCEPTANCE=IMPLICIT
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?
DISPOSITION=DEFERRED
ACCEPTANCE=EXPLICIT
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
DISPOSITION=REJECTED
ACCEPTANCE=IMPLICIT
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.
DISPOSITION=CLARIFICATION
ACCEPTANCE=EXPLICIT
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?
DISPOSITION=CLARIFICATION
ACCEPTANCE=IMPLICIT
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
DISPOSITION=CLARIFICATION
ACCEPTANCE=EXPLICIT
Hi there, After reading the current SCXML spec, I find the definition of "entry set" confusing, possible incorrect. In section 3.11, for [Definition: The entry set ...] the following is stated: [...] Otherwise, it consists of all members of the transition's complete target set that are not currently active. [..] Maybe I'm missing something obvious here, but it seem to me this can't be correct. Why are only 'not currently active' states considered? A currently active state can be both exited and (re)entered as result of a single transition, so should (and IMO is to) be included in the entry set as well. The "computeEntrySet" procedure in appendix A also doesn't reflect this AFAICT, only determining the entry set based on the transition targets only, not the (at that time already exited) current active states Thanks, Ate (working on Apache Commons SCXML 2.0 towards spec compliance)
DISPOSITION=CLARIFICATION
ACCEPTANCE=EXPLICIT
While implementing the SCXML Algorithm, I noticed the handling/processing of executable content of a History transition isn't taken care of yet. Neither in the Algorithm nor in wording (when) in the specification. The addDescendantStatesToEnter procedure dereferences History states, so these History states correctly don't end up in the statesToEnter, but then neither will their possible transition executable content be processed. And as important: when should History transition executable content be processed? It seems like an obvious choice that it should happen after the History parent state onentry and before any History default targets onentry execution. Any opinions? At any rate, I think this needs to be clarified in the specification, and also integrated in the Algorithm.
DISPOSITION=ACCEPTED
ACCEPTANCE=IMPLICIT
Hi, I've noticed a problem with test403b where event2 is never matched in state p0s1. On closer inspection it appears that the interpretation algorithm currently causes p0s1 and p0s2 to exit when p0's inner transition is taken, but they are not re-entered thereafter. Given p0's inner transition is targetless, should p0s1 and p0s2 be exited in the first place?
How many transition tags are allowed under initial?
1) The spec uses “documentOrder” in two places (selectEventlessTransitions and selectTransitions), where it presumably should use “entryOrder”. 2) The spec uses isScxmlState() in exitInterpreter() but isSCXMLElement() in enterStates(); the latter should probably be isScxmlState() for consistency with other is____State() functions. 3) Some of the functions use three spaces for indentation, some use four. Some are mixed (e.g. first line of exitStates versus other lines). It would be nice if this was consistent (but not necessary). 4) There are a few indentation issues that might cause confusion: 4a) In exitStates() the line beginning with "historyValue[h.id]” does not match any other indentation levels. 4b) In computeExitSet() the 3rd line is indented more than the 2nd, but I believe it should not be. 4c) In getEffectiveTargetStates() the header is missing a space after ‘function’ 4d) In getEffectiveTargetStates() the outer if/else is not aligned vertically. 4e) The comment in removeConflictingTransitions() is indented in an odd manner. 5) There are two statements ending in semicolons. I believe that these should not be present. 6) In computeExitSet() the condition for the ‘if' statement is parenthesized. This is the only case where this is used.
Trace of a particular code path in the algorithm causes an OrderedSet() to have some() called on it, but this method is not defined for OrderedSet. enterStates(): statesToEnter = new OrderedSet() … computeEntrySet(…,statesToEnter,…) computeEntrySet(…,statesToEnter,…): … addDescendantStatesToEnter(…,statesToEnter,…) addDescendantStatesToEnter(state,statesToEnter,statesForDefaultEntry): … if not statesToEnter.some(…) Either some() needs to be defined for OrderedSet, or the line above needs to become: if not statesToEnter.toList().some(…) The same problem exists in addAncestorStatesToEnter() (After getting quite far in the tests with LXSC I failed the 3rd preemption test, and decided to rewrite the core interpreter to match the latest spec algorithm in a very direct manner.)
Hi there, I think I detected a bug in the addDescendantStatesToEnter algorithm in the specification concerning *when* to invoke the addAncestorsStatesToEnter. Currently the algorithm defines the following logic for a compound state, after having added it to the statesForDefaultEntry: for s in getEffectiveTargetStates(state.initial.transition): addDescendantStatesToEnter(s,statesToEnter,statesForDefaultEntry, defaultHistoryContent) addAncestorStatesToEnter(s, state, statesToEnter, statesForDefaultEntry, defaultHistoryContent) If not first for all effective target states addDescendantStatesToEnter is executed, the addAncestorStatesToEnter might, when in involves an ancestor parallel with nested compound states of which one also happens to be one of the effective desendant target *but not yet resolved*, end up initializing a different (default) sibling child of such a compound state. End result: an invalid configuration with a compound state having multiple active child states. I detected this issue when testing irp test364, which indeed defines such a SCXML document. If the algorithm is implemented as currently defined in the specification, you'll end up with both s11p121 and s11p122 being on the statesToEnter set (or s11p111 and s11p112, depending on the processing order of the s1 initial targets). In Apache Commons SCXML I've implemented a legal configuration check before executing enterStates, and that fails on this point for irp test364. Maybe important to note is that if I disable the check, the test actually passes, so maybe others might have this same bug but going unnoticed? Solving this bug however should be pretty trivial. To ensure explicit descendant target states are recorded first, I just changed the above logic to: for s in getEffectiveTargetStates(state.initial.transition): addDescendantStatesToEnter(s,statesToEnter,statesForDefaultEntry, defaultHistoryContent) for s in getEffectiveTargetStates(state.initial.transition): addAncestorStatesToEnter(s, state, statesToEnter, statesForDefaultEntry, defaultHistoryContent) And I did the same for the two similar/same for loops in the handling for history states in addDescendantStatesToEnter where likewise both descendant and ancestors states to enter are resolved within a single loop. Note: the description of addDescendantStatesToEnter actually does seem to say it more correctly where it breaks these two separate 'steps' down in two separate sentences: Then if state is a compound state, add state to statesForDefaultEntry and recursively call addStatesToEnter on its default initial state(s). Then, since the default initial states may not be children of 'state', add any ancestors between the default initial states and 'state'. The above description at least gives the right direction how this should be implemented, namely as separate consecutive steps, but not 'optimized' into a single loop as currently done. Confusingly and incorrectly though this description names the "addDescendantStatesToEnter" routine "addStatesToEnter". It probably would be good to correct that as well. Kind regards, Ate Douma
Hi, >From "3.11 Legal State Configurations and Specifications": "In a conformant SCXML document, there is an additional requirement on the value of the 'initial' attribute of a <state> and on the 'target' of a <transition> inside an <initial> element: or <history> pseudo-state; all the states must be descendants of the containing <state> or <parallel> element." I'm not a native speaker, but is perhaps the ':' a left-over from a previous version where the "or <history> pseudo-state" was not present? I think it should maybe be removed? Maybe also re-word it as "inside an <initial> or <history> element"? Elvis
Hi folks, I only just heard about SCXML. I got interested and started reading the spec. In "B.3 The XPath Data Model", the section starts out by referencing XPath 1.0: "Implementations that support this data model must support [XPath 1.0]." But then in "B.3.2 Conditional Expressions" goes on to require XPath 2.0: "The SCXML Processor must accept any XPath expression as a conditional expression and must convert it into its effective boolean value as described in section 2.4.3 of the [XPath 2.0] specification." Could someone clarify? Should the first reference be to XPath 2.0 or is the discrepancy intended? Cheers, Elvis Stansvik
Hi, I'm puzzled about the meaning and purpose of the type 'location expression' for the <invoke> and <send> namelist attribute and the <param> location attribute in the SCXML specification. The namelist attribute is described in the specification as "A space-separated list of one or more data model locations to be included as attribute/value pairs with the message." followed with "(The name of the location is the attribute [...])". All the examples given in the specification as well as in the IPR tests only make use of datamodel data id values as 'names'. If that is the (only) intended usage, why then should this be of type 'location expression' and not more transparently typed as "data element IDs"? On the other hand, if this really should be interpreted as dynamic location expressions *yielding* a datamodel value, then "(The name of the location is the attribute [...])" becomes a very complex one, where only the result of the expression is a location for which the 'name' has to be derived dynamically. Currently I presume the first interpretation is intended, but in any case IMO the current type definition and description can use some stronger clarification. And I have a somewhat related question concerning the purpose of and distinction between the <param> expr and location attributes, which are to be used mutually exclusive. The description for the <param> location attribute says: "A location expression [...] that specifies the location in the datamodel to use as the value." Taken literally, this actually means the location *itself* should be passed as value, not the value *at* the location. But I don't think that is the intended purpose, right? AFAICT the purpose of the location attribute is only to yield the value at the specified location, not the location itself. But then: why not just and only use the expr attribute always, which should be giving the exact same result, if it targets a datamodel location? Maybe there is some nuance I'm overlooking here, possibly particular to certain expression languages, but AFAIK the intend for both the expr and location attributes is or should be exactly the same: yield the data value. So I'm missing the point why I ever would need to use (and therefore need to implement) the location attribute. I hope I've described my confusion clearly enough :) Kind regards, Ate