RE: On <scxml> not being a <state>

Gavin,
We have discussed making <scxml> a state several times, and always decided against it, partly because it is useful to have a wrapper element holding meta-information, and partly because of questions of what it would mean to exit and reenter it (would you re-initialize the datamodel?).  In the specific case you are addressing, I don't see how adding <history> to <scxml> would help you.  It would record the configuration just before you exited the <scxml> element.  For <scxml> that would always be one of the <final> children (no matter whether history was deep or shallow).  If you wanted to record a deep history of a running (i.e., non-final) configuration, you would still need the top-level wrapper state, as you have now.

Going a bit further, it seems to me that you might want to restore a complex configuration complete with state of the datamodel .  We had functionality like that in earlier drafts of the spec, but dropped it because none of the participants in the group had implemented it.  If you're interested in that, dig back into earlier drafts until you find one that contains <anchor>.  This kind of functionality is also of interest to people who do speech-based natural-language dialog systems (for when you realize that the speech recognition system has gotten hopelessly confused, so you want to back up and start over.)  I think that something like this is a very good candidate for a future version of the spec.

Just thinking out loud now, some of the other things that you mention could be done without making <scxml> a state.  (By that I mean without giving <scxml> an id attribute and allowing it as the target of a transition.)  It could certainly hold <invoke>, <onentry>, and <onexit>.  I'd have to think about <transition>.  It would seem to work for internal or targetless transitions, but allowing external transitions might get ugly.

These are things that you could try as extensions.  We could also look at them in a future version, too.  If we did that, we would like to  maintain backward compatibility, meaning that 1.0 apps would run in a 2.0 interpreter without any change in behavior.  If 2.0 allowed <invoke> <onentry> and <onexit> as children of <scxml>, there wouldn't be any problem that I can see - the 1.0 apps would just happen not to have them.  But changing the definition of LCCA to allow external transitions in <scxml> might cause a train wreck.


-          Jim

From: Gavin Kistner [mailto:phrogz@me.com]
Sent: Tuesday, February 19, 2013 12:38 PM
To: www-voice@w3.org; www-voice@w3.org
Subject: On <scxml> not being a <state>

I am increasingly forced to move all states in my machine under a single <state id="wrap">...except for the <final> states.

In this case I want my app to be able to have a <history type="deep"> element that allows me to boot/restore the machine into a particular complex state (restoring an application after the interpreter was torn down). But <history> is not allowed on <scxml>.

Previously I had to move them all into a wrapper just so that I could add this debug transition:
<transition event="error"><log expr="_event.name..'->'.._event.data" label="An error occurred!"/></transition>

The fact that the root <scxml> element is not just another compound state seems to make many areas inelegant and special-cased. Why can't <scxml> have <onentry>, <onexit>, <transition>, <history> and <invoke>?

I don't want to delay any ratification of the standard, but for the next version I hope that we might be able to make a more self-consistent system that's also easier to use.