History transition executable content - when is it executed?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

History transition executable content - when is it executed?

Ate Douma
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

Reply | Threaded
Open this post in threaded view
|

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

Jim Barnett-2
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:[hidden email]]
Sent: Monday, March 24, 2014 4:20 PM
To: [hidden email]
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



Reply | Threaded
Open this post in threaded view
|

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

David Junger
Since they're restricted much like those in <initial>, I had a look at that, but it appears <initial> transitions "may" have executable content too. I don't see a clear statement about when that should be executed either, and I don't see it in the pseudocode (tell me if I'm wrong, but I'm going to proceed under the assumption that I didn't miss it).

Your proposal makes the <history> transition executable content run during the entry phase (between the parent state's onentry blocks and its children's, if I understand correctly). I think that makes sense for those transitions, especially for <initial> and it's OK for <history>. Since you can't trigger both <initial> and <history> for the same parent at the same time, they could safely share the same mechanism for running their executable content.

                        David
Reply | Threaded
Open this post in threaded view
|

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

Ate Douma
In reply to this post by Jim Barnett-2
On 24-03-14 21:40, Jim Barnett wrote:

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

I agree this should be properly fixed in the algorithm, but I dislike kludging
some extra attribute on a state object for the duration and scope of one micro
step only. If possible I'd keep the SCXML element model definitions independent
of current execution state and context.

A maybe cleaner way to do is to introduce and use a temporary
table<State.id,Transition> data structure and use that to keep track and look up
the History transition to be executed when entering a state.
This table then only is needed and used in the scope of the enterState() procedure:

   procedure enterStates(enabledTransitions):
       statesToEnter = new OrderedSet()
       statesForDefaultEntry = new OrderedSet()
       // initialize the temporary table for targeted History transitions
       defaultHistoryTransitionOnEntry = new HashTable()
       // pass on this table to computeEntrySet
       computeEntrySet(enabledTransitions, statesToEnter, statesForDefaultEntry,
defaultHistoryTransitionOnEntry)
       for s in statesToEnter.toList().sort(entryOrder):
           configuration.add(s)
           statesToInvoke.add(s)
           if binding == "late" and s.isFirstEntry:
               initializeDataModel(datamodel.s,doc.s)
               s.isFirstEntry = false
           for content in s.onentry:
               executeContent(content)
           if statesForDefaultEntry.isMember(s):
               executeContent(s.initial.transition)
           // if this State is a parent of a targeted History, now execute the
History transition executable content (if any)
           if defaultHistoryTransitionOnEntry[s.id]
               executeContent(defaultHistoryTransitionOnEntry[s.id]
       ...

This table also will have to be passed on from computeEntrySet(),
addAncestorStatesToEnter() and addDescendantStatesToEnter() (recursively), and
the latter then is modified like:

   procedure
addDescendantStatesToEnter(state,statesToEnter,statesForDefaultEntry,
defaultHistoryTransitionOnEntry):
       if isHistoryState(state):
           if historyValue[state.id]:
               // track this targeted History its transition on its parent state
id for processing in enterStates() after entering its parent
               defaultHistoryTransitionOnEntry[state.parent.id] = state.transition
       ....

Alternatively, the defaultHistoryTransitionOnEntry table can be defined global
and initialized in procedure interpret() so as not having to modify the
signatures of any of these procedures, but then you probably also will want to
clear/reset this table in enterState() and assert its empty afterwards as it
only is used within its context. You only need to modify the *body* of the
interpret(), enterStates() and addDescendantsStatesToEnter() procedures then.

I prefer the first solution though as it is more clean and clear, the second
solution only to be considered to minimize the impact of the change.

Note also I put the History transition handling after its parent
initial.transition handling explicitly, as the parent.initial might actually be
the one which targeted the History. Therefore their execution order is significant.

Ate

>
> - Jim
>
> -----Original Message-----
> From: Ate Douma [mailto:[hidden email]]
> Sent: Monday, March 24, 2014 4:20 PM
> To: [hidden email]
> 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
>
>


Reply | Threaded
Open this post in threaded view
|

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

David Junger
Le 25 mar 2014 à 07:42, Ate Douma <[hidden email]> a écrit :

I agree this should be properly fixed in the algorithm, but I dislike kludging some extra attribute on a state object for the duration and scope of one micro step only. If possible I'd keep the SCXML element model definitions independent of current execution state and context.

A maybe cleaner way to do is to introduce and use a temporary table<State.id,Transition> data structure and use that to keep track and look up the History transition to be executed when entering a state.
[…]

Who said the pseudocode was Java? Guys, you know you can implement the spec without transposing the pseudocode word for word, right?
I'm not defending one way to write this or the other, I'm just saying, do whatever is easier to understand and shorter to read.
Most importantly, describe the intended timing precisely in the prose.

Note also I put the History transition handling after its parent initial.transition handling explicitly, as the parent.initial might actually be the one which targeted the History. Therefore their execution order is significant.

initial targetting history… right, I never thought of that. So there is actually a way to have to run both executable contents. I agree with the order of execution, of course.

David
Reply | Threaded
Open this post in threaded view
|

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

Ate Douma
On 25-03-14 08:36, David Junger wrote:

> Le 25 mar 2014 à 07:42, Ate Douma <[hidden email] <mailto:[hidden email]>> a écrit :
>
>> I agree this should be properly fixed in the algorithm, but I dislike kludging
>> some extra attribute on a state object for the duration and scope of one micro
>> step only. If possible I'd keep the SCXML element model definitions
>> independent of current execution state and context.
>>
>> A maybe cleaner way to do is to introduce and use a temporary
>> table<State.id,Transition> data structure and use that to keep track and look
>> up the History transition to be executed when entering a state.
>> […]

Hmm, not sure where I used anything Java specific in my proposed changes to the
Algorithm. I just tried to give an example how the Algorithm night need to be
changed, and AFAIK fully in line with how the Algorithm currently is described.

Sure, I'm using Java for my implementation but AFAIK nothing I described
reflects on any specific implementation language.

The table<State.id,Transition> above was just to explain what kind of data would
be mapped by the table, nothing more. In Java you actually would use a Map for
this, the table data structure is only used in the Algorithm (like elsewhere).

>
> Who said the pseudocode was Java? Guys, you know you can implement the spec
> without transposing the pseudocode word for word, right?
> I'm not defending one way to write this or the other, I'm just saying, do
> whatever is easier to understand and shorter to read.
> Most importantly, describe the intended timing precisely in the prose.
>
Of course, the specification itself should be leading and exact.
I'm just trying to provide an example how the Algorithm *might* be changed to
help determine the needed change in the specification.

For example the realization that an Initial might target a History and thus its
executable content needs to be executed first, became only obvious to me after
following the Algorithm, *not* the prose.

>> Note also I put the History transition handling after its parent
>> initial.transition handling explicitly, as the parent.initial might actually
>> be the one which targeted the History. Therefore their execution order is
>> significant.
>
> initial targetting history… right, I never thought of that. So there is actually
> a way to have to run both executable contents. I agree with the order of
> execution, of course.
>
> David



Reply | Threaded
Open this post in threaded view
|

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

Jim Barnett
In reply to this post by Ate Douma
I agree that a using a table is cleaner than hacking an attribute into state.  It is probably also cleaner to pass it as an extra argument, though we do use a number of globals in the algorithm already.  As long as the extra argument is used in only a  few places and _none_ of the other entry/exit logic changes, it's a safe change. 

For the prose in the spec, I am thinking of adding something like the following in 3.10.2, right after the penultimate sentence (which is "If it has not, the SCXML processor MUST behave as if the transition had taken the default stored state configuration for that history state as its target"):

The Process MUST execute any executable content in the transition after the history pseudo-state's parent state's onentry handlers, and, in the case where the history pseudo-state was the target of an <initial> transition, after any executable content in the <initial> transition. 

Let's wait a couple of days to see if there are any other comments.  Then I will update the editor's draft and send around a link to it so that people can have a look.  There won't be a new public draft until we go through the publication procedure, which will take a couple of weeks. 

- Jim


On 3/25/2014 2:42 AM, Ate Douma wrote:
On 24-03-14 21:40, Jim Barnett wrote:
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.

I agree this should be properly fixed in the algorithm, but I dislike kludging some extra attribute on a state object for the duration and scope of one micro step only. If possible I'd keep the SCXML element model definitions independent of current execution state and context.

A maybe cleaner way to do is to introduce and use a temporary table<State.id,Transition> data structure and use that to keep track and look up the History transition to be executed when entering a state.
This table then only is needed and used in the scope of the enterState() procedure:

  procedure enterStates(enabledTransitions):
      statesToEnter = new OrderedSet()
      statesForDefaultEntry = new OrderedSet()
      // initialize the temporary table for targeted History transitions
      defaultHistoryTransitionOnEntry = new HashTable()
      // pass on this table to computeEntrySet
      computeEntrySet(enabledTransitions, statesToEnter, statesForDefaultEntry, defaultHistoryTransitionOnEntry)
      for s in statesToEnter.toList().sort(entryOrder):
          configuration.add(s)
          statesToInvoke.add(s)
          if binding == "late" and s.isFirstEntry:
              initializeDataModel(datamodel.s,doc.s)
              s.isFirstEntry = false
          for content in s.onentry:
              executeContent(content)
          if statesForDefaultEntry.isMember(s):
              executeContent(s.initial.transition)
          // if this State is a parent of a targeted History, now execute the History transition executable content (if any)
          if defaultHistoryTransitionOnEntry[s.id]
              executeContent(defaultHistoryTransitionOnEntry[s.id]
      ...

This table also will have to be passed on from computeEntrySet(), addAncestorStatesToEnter() and addDescendantStatesToEnter() (recursively), and the latter then is modified like:

  procedure addDescendantStatesToEnter(state,statesToEnter,statesForDefaultEntry, defaultHistoryTransitionOnEntry):
      if isHistoryState(state):
          if historyValue[state.id]:
              // track this targeted History its transition on its parent state id for processing in enterStates() after entering its parent
              defaultHistoryTransitionOnEntry[state.parent.id] = state.transition
      ....

Alternatively, the defaultHistoryTransitionOnEntry table can be defined global and initialized in procedure interpret() so as not having to modify the signatures of any of these procedures, but then you probably also will want to clear/reset this table in enterState() and assert its empty afterwards as it only is used within its context. You only need to modify the *body* of the interpret(), enterStates() and addDescendantsStatesToEnter() procedures then.

I prefer the first solution though as it is more clean and clear, the second solution only to be considered to minimize the impact of the change.

Note also I put the History transition handling after its parent initial.transition handling explicitly, as the parent.initial might actually be the one which targeted the History. Therefore their execution order is significant.

Ate


- Jim

-----Original Message-----
From: Ate Douma [[hidden email]]
Sent: Monday, March 24, 2014 4:20 PM
To: [hidden email]
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





--
Jim Barnett
Genesys
Reply | Threaded
Open this post in threaded view
|

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

Ate Douma
In reply to this post by Ate Douma
For the record, I just saw I made a mistake in the proposal for modifying the
addDescendantStatesToEnter procedure.

I'm sure everyone else already noticed, but just to make sure:

The recording of the History transition in the default
defaultHistoryTransitionOnEntry table of course should only be done when there
is NO history recorded yet, not the opposite :)

So, the pseudo-algorithm for addDescendantStatesToEnter procedure could become
something like:

   procedure
addDescendantStatesToEnter(state,statesToEnter,statesForDefaultEntry,
defaultHistoryTransitionOnEntry):
       if isHistoryState(state):
           if historyValue[state.id]:
               for s in historyValue[state.id]:
                   addDescendantStatesToEnter(s,statesToEnter,statesForDefaultEntry)
                   addAncestorStatesToEnter(s, state.parent, statesToEnter,
statesForDefaultEntry)
           else:
               // track this targeted History its transition on its parent state
id for processing in enterStates() after entering its parent
               defaultHistoryTransitionOnEntry[state.parent.id] = state.transition
       ....

instead of my erroneous earlier example.


Regards,
Ate


Reply | Threaded
Open this post in threaded view
|

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

Ate Douma
In reply to this post by Jim Barnett
On 25-03-14 14:26, Jim Barnett wrote:

> I agree that a using a table is cleaner than hacking an attribute into state.
> It is probably also cleaner to pass it as an extra argument, though we do use a
> number of globals in the algorithm already.  As long as the extra argument is
> used in only a  few places and _none_ of the other entry/exit logic changes,
> it's a safe change.
>
> For the prose in the spec, I am thinking of adding something like the following
> in 3.10.2, right after the penultimate sentence (which is "If it has not, the
> SCXML processor /MUST/ behave as if the transition had taken the default stored
> state configuration for that history state as its target"):
>
> The Process MUST execute any executable content in the transition after the
> history pseudo-state's parent state's onentry handlers, and, in the case where
> the history pseudo-state was the target of an <initial> transition, after any
> executable content in the <initial> transition.

Sound good to me.

Maybe it would be helpful to be a little bit more explicit by saying:

   [...] and, in the case where the history pseudo-state was the target of its
parent <initial> transition, [...]

to make sure this isn't (incorrectly) confused with the case when the history
was the target of an initial of one of its parent ancestor(s).

Your sentence already is correct of course because of the "and, " in front, so
either way, I think its fine syntactically.

Ate

>
> Let's wait a couple of days to see if there are any other comments. Then I will
> update the editor's draft and send around a link to it so that people can have a
> look.  There won't be a new public draft until we go through the publication
> procedure, which will take a couple of weeks.
>
> - Jim
>
>
> On 3/25/2014 2:42 AM, Ate Douma wrote:
>> On 24-03-14 21:40, Jim Barnett wrote:
>>> 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.
>>
>> I agree this should be properly fixed in the algorithm, but I dislike kludging
>> some extra attribute on a state object for the duration and scope of one micro
>> step only. If possible I'd keep the SCXML element model definitions
>> independent of current execution state and context.
>>
>> A maybe cleaner way to do is to introduce and use a temporary
>> table<State.id,Transition> data structure and use that to keep track and look
>> up the History transition to be executed when entering a state.
>> This table then only is needed and used in the scope of the enterState()
>> procedure:
>>
>>   procedure enterStates(enabledTransitions):
>>       statesToEnter = new OrderedSet()
>>       statesForDefaultEntry = new OrderedSet()
>>       // initialize the temporary table for targeted History transitions
>>       defaultHistoryTransitionOnEntry = new HashTable()
>>       // pass on this table to computeEntrySet
>>       computeEntrySet(enabledTransitions, statesToEnter,
>> statesForDefaultEntry, defaultHistoryTransitionOnEntry)
>>       for s in statesToEnter.toList().sort(entryOrder):
>>           configuration.add(s)
>>           statesToInvoke.add(s)
>>           if binding == "late" and s.isFirstEntry:
>>               initializeDataModel(datamodel.s,doc.s)
>>               s.isFirstEntry = false
>>           for content in s.onentry:
>>               executeContent(content)
>>           if statesForDefaultEntry.isMember(s):
>>               executeContent(s.initial.transition)
>>           // if this State is a parent of a targeted History, now execute the
>> History transition executable content (if any)
>>           if defaultHistoryTransitionOnEntry[s.id]
>>               executeContent(defaultHistoryTransitionOnEntry[s.id]
>>       ...
>>
>> This table also will have to be passed on from computeEntrySet(),
>> addAncestorStatesToEnter() and addDescendantStatesToEnter() (recursively), and
>> the latter then is modified like:
>>
>>   procedure
>> addDescendantStatesToEnter(state,statesToEnter,statesForDefaultEntry,
>> defaultHistoryTransitionOnEntry):
>>       if isHistoryState(state):
>>           if historyValue[state.id]:
>>               // track this targeted History its transition on its parent
>> state id for processing in enterStates() after entering its parent
>>               defaultHistoryTransitionOnEntry[state.parent.id] = state.transition
>>       ....
>>
>> Alternatively, the defaultHistoryTransitionOnEntry table can be defined global
>> and initialized in procedure interpret() so as not having to modify the
>> signatures of any of these procedures, but then you probably also will want to
>> clear/reset this table in enterState() and assert its empty afterwards as it
>> only is used within its context. You only need to modify the *body* of the
>> interpret(), enterStates() and addDescendantsStatesToEnter() procedures then.
>>
>> I prefer the first solution though as it is more clean and clear, the second
>> solution only to be considered to minimize the impact of the change.
>>
>> Note also I put the History transition handling after its parent
>> initial.transition handling explicitly, as the parent.initial might actually
>> be the one which targeted the History. Therefore their execution order is
>> significant.
>>
>> Ate
>>
>>>
>>> - Jim
>>>
>>> -----Original Message-----
>>> From: Ate Douma [mailto:[hidden email]]
>>> Sent: Monday, March 24, 2014 4:20 PM
>>> To: [hidden email]
>>> 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
>>>
>>>
>>
>>
>
> --
> Jim Barnett
> Genesys


Reply | Threaded
Open this post in threaded view
|

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

Jim Barnett
In reply to this post by Ate Douma
Yes, I'll use this newer version.

- Jim
On 3/25/2014 5:28 PM, Ate Douma wrote:

> For the record, I just saw I made a mistake in the proposal for
> modifying the addDescendantStatesToEnter procedure.
>
> I'm sure everyone else already noticed, but just to make sure:
>
> The recording of the History transition in the default
> defaultHistoryTransitionOnEntry table of course should only be done
> when there is NO history recorded yet, not the opposite :)
>
> So, the pseudo-algorithm for addDescendantStatesToEnter procedure
> could become something like:
>
>   procedure
> addDescendantStatesToEnter(state,statesToEnter,statesForDefaultEntry,
> defaultHistoryTransitionOnEntry):
>       if isHistoryState(state):
>           if historyValue[state.id]:
>               for s in historyValue[state.id]:
> addDescendantStatesToEnter(s,statesToEnter,statesForDefaultEntry)
>                   addAncestorStatesToEnter(s, state.parent,
> statesToEnter, statesForDefaultEntry)
>           else:
>               // track this targeted History its transition on its
> parent state id for processing in enterStates() after entering its parent
>               defaultHistoryTransitionOnEntry[state.parent.id] =
> state.transition
>       ....
>
> instead of my erroneous earlier example.
>
>
> Regards,
> Ate
>
>

--
Jim Barnett
Genesys