RE: History transition executable content - when is it executed?

I have looked at this and think it's a nasty bug in the spec.  As far as I can see, the algorithm never executes the executable content inside a history state's transition child.  (Somebody please tell me if I'm wrong - it will save us a lot of time.)  Furthermore the text of the specification does not specify when such executable content is to be executed.  

If the bug is as serious as I think, the fix will involve changes to the normative language of the specification and we will have to go back to Last Call again.  Furthermore, I don't see a clean way to fix the algorithm because all trace of the fact that we're entering a history state is gone by the point in enterStates where executable content is executed.  I see several possible solutions, and am open to others:

1.  Forbid executable content in the <transition> inside history.  I know that there's good reason to allow it there, but I mention this because it is the smallest possible change to the specification that restores correctness.  However it weakens the language and leaves us with a transition element that has no motivation.

2.  Get rid of the transition and add an 'defaultInitial' attribute to the history state.  This is basically the same idea as 1, but it fixes the syntax.  There would be only one trivial change to the algorithm - we would take the default history configuration from the history state's  defaultInitial attribute rather than from the target of its child transition.  But it still weakens the expressiveness of the language.  

3.  Try to fix the algorithm so that it executes the content in the transition.  To avoid breaking anything else, this change should be as small and as isolated as possible.  What I've come up with so far is to kluge a 'extraContent' attribute onto a state.  Then in addDescendantStatesToEnter we would modify the clause that handles the default transition so that it also appends the transition's executable content to the parent state's extraContent attribute (that is, to the parent state of the history state).  Then in enterStates right after we execute a state's onentry content, we would execute its extraContent and then set it to null. This is aesthetically unsatisfying, to say the least, but seems safer than trying to rejuggle a bunch of definitions to handle things cleanly.

Please send me your thoughts on this. All options are ugly, but I think that we have to do something.

- Jim

-----Original Message-----
From: Ate Douma [mailto:ate@douma.nu] 
Sent: Monday, March 24, 2014 4:20 PM
To: www-voice@w3.org
Subject: History transition executable content - when is it executed?

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.

Kind regards,
Ate

Received on Monday, 24 March 2014 20:41:15 UTC