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

Gavin,
I now see what you're trying to do to rehydrate a stored session.  If we wanted to address this in a future version of the spec,  my guess is that we would add the following prose:  "The Platform _must_ provide a way for the environment to specify the initial state configuration and state of the datamodel.   Such a specification _must_ take precedence over the value of <scxml>'s initial attribute"  We already allow the environment to provide the initial values of the datamodel, so I don't think it would be odd to extend this to states.   We would then change the algorithm to take an optional external specification of the initial configuration.

For the time being, though, since you need a specified location to re-write, why not use <scxml>'s 'intial' attribute?  It can take multiple values, so it should work just as well as history.  Neither 'initial' nor <history> will restore the previous values of the datamodel, though.  That's why I thought something like <anchor>, which snapshots the datamodel, might be of interest.


-          Jim

From: Gavin Kistner [mailto:phrogz@me.com]
Sent: Tuesday, February 19, 2013 5:41 PM
To: Jim Barnett
Cc: www-voice@w3.org
Subject: Re: On <scxml> not being a <state>

On Feb 19, 2013, at 11:22 AM, Jim Barnett <Jim.Barnett@genesyslab.com<mailto:Jim.Barnett@genesyslab.com>> wrote:
We have discussed making <scxml> a state several times, and always decided against it

I do apologize. I tried to search the archives for this topic (assuming it must have come up) but failed to find the relevant threads. Consider this a low priority thread for me, but I'm going to pursue it slightly nonetheless.



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?).

When would you exit and re-enter it? Only for an external transition on the <scxml> itself? If so, isn't that what you'd expect?

I can't see why the datamodel initialization comes into play. Either the binding is "early", in which case you initialize the <datamodel> elements through for every state right up front, or it is late, in which case you initialize the <datamodel> for each state the first time you enter the state. You never re-initialize the datamodel for any state when you exit and re-enter, so there's no reason (in my mind) that <scxml> would be special.



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.

Consider the case where I want to boot-and-restore a state machine into a specific configuration after a particular system.initialized event occurs. This configuration is not a static enumeration, but rather the recorded set of atomic IDs last seen when the interpreter was running. As such I cannot hard-code the configuration into the transition of the static SCXML file.

I have (at least) four choices:
1. Dynamically generate the SCXML text content before feeding it to the parser and interpreter, setting the target="..." on the transition appropriately. This happens not to be an option for me in my current situation.
2. Parse a static SCXML machine and then modify the internal representation to manipulate the target="..." on the transition to target the correct states. (This is what I'm going to do now.)
3. If <history> were allowed at the root of <scxml>, dynamically modify the target="..." of its transition as with #2 above.

The <history> in this case is not being used for its powers of recollection--you never leave <scxml>, so the recorded configuration never changes. Instead it is used as a targetable collection of state targets. By targeting the history node I target the saved configuration. The benefit of this over modifying transition targets is that the history allows the set of targets to exists in a single place. It provides a layer of abstraction that may be used as the target for multiple transitions.

If I run into the situation where I later wish to reboot into this same startup state, I must modify the target="..." list for every transition that is supposed to target the configuration.



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.

Thanks, I will check out anchor. (I do think I remember reading about it several years ago, the last time I was into SCXML. :)



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.

I agree. Please do not allow this discussion to hold up 1.0 in any way. (For business reasons, the sooner it can become a recommendation, the better. Of course, that can't be allowed to happen until the algorithm is solid, and I appreciate the progress being made there.)



But changing the definition of LCCA to allow external transitions in <scxml> might cause a train wreck.

Perhaps. Hopefully not. The empty set is just as valid (in set theory) as any other, so I (hands-waving) imagine that passing through this undesirable state during a microstep would involve only very minor changes to the algorithm. But we'll leave that for a future date. :)



From: Gavin Kistner [mailto:phrogz@me.com]
Sent: Tuesday, February 19, 2013 12:38 PM
To: www-voice@w3.org<mailto:www-voice@w3.org>; www-voice@w3.org<mailto: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.