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

RE: ISSUE-826: comments from Gavin Kistner [SCXML-LC-Comments]

From: Jim Barnett <Jim.Barnett@genesyslab.com>
Date: Sun, 27 Jan 2013 01:31:03 +0000
To: Gavin Kistner <phrogz@me.com>
CC: Voice Browser Working Group <w3c-voice-wg@w3.org>, "www-voice@w3.org" <www-voice@w3.org>
Message-ID: <57A15FAF9E58F841B2B1651FFE16D28101B98C@GENSJZMBX03.msg.int.genesyslab.com>
 You're right, getChildStates should include <final> states.  It should return all non-pseudo  states.  I'd forgotten about the final case.  I'll look at example G.1 as well.

We haven't settled the issue of an empty <scxml> element yet, but my current thinking is that we should disallow it.  The reasoning is that the basic concept of a state machine is: what state(s) you're in.  The <scxml> element is a wrapper element, not a state.  In terms of formal language theory, it doesn't make sense to have a state machine that is not in any state.  You can make sense of the idea in terms of initializing a piece of _software_, but it doesn't  make sense to have a state machine that is not in any state. If we made <scxml> a first-class state, then it would make sense to allow it to be empty, but as we have defined it, it's just a wrapper element.  

As far as I can tell, the practical difference is that if <scxml> is a wrapper element, it is not legal to have it without a <state>, <parallel> or <final> child.  If we say it is a state, then it is legal to have an empty element, and the state machine sits in it forever.  I can't see any practical benefit in choosing the latter.  

- Jim

-----Original Message-----
From: Gavin Kistner [mailto:phrogz@me.com] 
Sent: Saturday, January 26, 2013 5:13 PM
To: Jim Barnett
Cc: Voice Browser Working Group; www-voice@w3.org
Subject: Re: ISSUE-826: comments from Gavin Kistner [SCXML-LC-Comments]

On Jan 25, 2013, at 8:02 AM, Jim Barnett <Jim.Barnett@genesyslab.com> wrote:
>> 8. The function getChildStates() is used throughout the algorithm without definition. I cannot tell if this function is intended to return only "proper" states or also pseudo-state children. Please clarify both in email and the spec.
> It should retun only <state> and <parallel> children.  I will add a clarification to the spec.  

Are you sure that it should not also include <final> children? I see that it is almost exclusively used to get children of parallel states (which cannot have <final> children. However, consider the first usage in isInFinalState(s):

    function isInFinalState(s):
      if isCompoundState(s):
        return getChildStates(s).some(lambda s: isFinalState(s) and configuration.member(s))
      elif isParallelState(s):
        return getChildStates(s).every(isInFinalState)
        return false

It would seem that it must include <final> if the lambda is to be useful.

>> 13. I find the Type1/Type2/Type3 confusing for transitions. First, <transition> elements already have a "type" attribute that is unrelated; a better term (Category?) should be used. Secondly, the prose descriptions for both Type 2 and Type 3 do not seem rigorous. What is a "transition within a single child of <parallel>"? A transition that is in a state that is the sole child of a parallel? A single transition that is a direct child of a <parallel> node? Please revisit the preemptsTransition description and pseudo-code to make this subtle area for bugs robust and clear.
> Yes, other people have commented that the definition of preemption is quite murky.  I'll have to work on clarifying it. "Category' is a better term than 'type' for the reason you mention. In the case of ""transition within a single child of <parallel>", it is a transition whose source and target are contained within a single <state> child of <parallel> and which can be taken without exiting that <state>.  
> Another way of stating the issue is that two transition conflict if their exit sets (the set of states that they exit) have a non-null intersection.  In case of conflict, we execute the first transition (in document order) and preempt the second.  

Thank you for the clarification. That's quite helpful.

(I'm a little surprised, as I'd generally have assumed that later document order would be important for the case of conflicting transitions in a parent and in its child. However, I can imagine that elsewhere the algorithm would never select both these transitions and never have to use this tie-breaker. This is random musing out loud, however, and may be ignored. :)

>> 14. Section C.2.1 shows invalid SCXML in the example; not only is the <scxml> element missing the xmlns, but the "CEO" element has incorrectly escaped the XML attribute values.
> I'll look at this.  

One other example problem discovered: Example G.1 contains an XInclude directive for merging in a few sub-states:

    <state id="Test2" xmlns:xi="http://www.w3.org/2001/XInclude">
      <!-- This time we reference a state defined in an external file.   -->
      <xi:include href="SCXMLExamples/Test2Sub1.xml" parse="text"/>

a) Why would this use parse="text"? I feel semi-certain that this ought to be parse="xml".
b) The included file has no namespace on the root element. As best as I can tell[1] this results in a `<state>` element that is not in the SCXML namespace:
    Example: Test2Sub1.xml
      <state id="Test2Sub1">

[1] http://stackoverflow.com/questions/14542030/namespace-for-xinclude-included-elements

>> 16. I could not discern what should occur for a machine whose content is a single <scxml> element with no state children. While so trivial as to be almost useless (except for unit tests that are testing the datamodel), this appears to be a legal state machine. However, given that this <scxml> element lacks an initial attribute or element (it s an atomic state, after all), the pseudo-code for interpret: "executeTransitionContent([doc.initial.transition] enterStates([doc.initial.transition])" is in error (there is no doc.initial). Guarding against this prevents the <scxml> state from ever being entered into the configuration, leaving the state machine in a null state.
> Good question.  Very good question.  We'll have to think about this.  We could ban this by requiring that <scxml> have at least one <state> or <transition> child, but there may be reasons to allow it and define the behavior more carefully.  

If you do choose to (continue to) allow this as a legal configuration, one thought (untested) is that the algorithm could be changed to create a transition that targets the <scxml> root and use that during the interpret() procedure instead.

>> 17. In general, I strongly echo the request for a set of SCXML examples, example event input and the configurations and log output that should come from each. These would ideally range from the simple to (eventually) tests that exercise all aspects of the interpretation algorithm. But do not let the "perfect" be the enemy of the "good": any examples (and their expected behavior in the presence of a series of events) would be a boon.
> We will provide a set of tests as part of the Candidate Recommendation version of  the spec.

That will be much appreciated. No offense intended, but I'm personally surprised that the group could create an algorithm for interpretation *without* a set of rigorous tests that would prove or disprove that the algorithm is valid. Thus far I've come up with a few simple tests on my own whose intended behavior is easy to predict (there is no preemption conflict, for example ;) and yet which have indicated that my current implementation is fundamentally flawed. (Likely due in part to my misimplementation of item #8 above.) I don't know where I'd be without unit tests during development.

> The current situation is a large set of interconnected rules described over (and cross-linked throughout) 20+ pages coupled with normative pseudo-code that can't actually be run and that has bugs that would prevent it from compiling/parsing if it were real code. Making the pseudo-code robust would be a nice step. Providing a normative reference implementation that can actually run (in ECMAScript, perhaps?) would be even better.
>>> There is no official reference implementation.  However the implementer of PySCXML ( http://pyscxml.spyderbrain.com/ ) is a member of the SCXML working group and keeps his implementation as up-to-date as he can.  

Super helpful information, thank you. I've already gotten some excellent information from perusing the tests and implementation points of that library.
Received on Sunday, 27 January 2013 01:31:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 27 January 2013 01:31:37 GMT