[SCXML] history state in parallel state

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

[SCXML] history state in parallel state

Erik Verbruggen
Hello,

I have a question about history states inside parallel states. Consider
this state machine:

<scxml>
<parallel id="p">
     <history id="h">
         <transition target="a2"/>
     </history>
     <state id="a">
         <state id="a1"/>
         <state id="a2"/>
     </state>
</parallel>
</scxml>

The question is: what is the (initial) configuration of the state
machine? If I read the standard correctly, it should be (p, a, a2). Is
that correct? If not, what did I miss?

I'm asking because when addDescendantStatesToEnter is called for the
parallel state p, it will do:

        if isParallelState(state):
                 for child in getChildStates(state):

and getChildStates will not return any <history> child/state. So, it
looks like the default history configuration will not be used, and the
state machine would end up in the configuration (p, a, a1).

Kind regards,
Erik.


Reply | Threaded
Open this post in threaded view
|

Re: [SCXML] history state in parallel state

David Junger
Le 14 juil. 2015 à 12:13, Erik Verbruggen <[hidden email]> a écrit :

>
> I have a question about history states inside parallel states. Consider this state machine:
>
> <scxml>
> <parallel id="p">
>    <history id="h">
>        <transition target="a2"/>
>    </history>
>    <state id="a">
>        <state id="a1"/>
>        <state id="a2"/>
>    </state>
> </parallel>
> </scxml>
>
> The question is: what is the (initial) configuration of the state machine? If I read the standard correctly, it should be (p, a, a2). Is that correct? If not, what did I miss?

No, the initial configuration would be (p -> a -> a1). The history pseudo-states can only be "entered" when targetted explicitly, as you have noticed in the algorithm, and they are not added to any configuration.

                        David
Reply | Threaded
Open this post in threaded view
|

Re: [SCXML] history state in parallel state

Erik Verbruggen
On 15-7-2015 7:59, David Junger wrote:

> Le 14 juil. 2015 à 12:13, Erik Verbruggen <[hidden email]> a écrit :
>>
>> I have a question about history states inside parallel states. Consider this state machine:
>>
>> <scxml>
>> <parallel id="p">
>>     <history id="h">
>>         <transition target="a2"/>
>>     </history>
>>     <state id="a">
>>         <state id="a1"/>
>>         <state id="a2"/>
>>     </state>
>> </parallel>
>> </scxml>
>>
>> The question is: what is the (initial) configuration of the state machine? If I read the standard correctly, it should be (p, a, a2). Is that correct? If not, what did I miss?
>
> No, the initial configuration would be (p -> a -> a1). The history pseudo-states can only be "entered" when targetted explicitly, as you have noticed in the algorithm, and they are not added to any configuration.

Ah, thanks! So, in the example above, targeting it explicitly would mean
setting the initial state of the scxml to the history state?

-- Erik

Reply | Threaded
Open this post in threaded view
|

Re: [SCXML] history state in parallel state

David Junger
>> <scxml>
>> <parallel id="p">
>>     <history id="h">
>>         <transition target="a2"/>
>>     </history>
>>     <state id="a">
>>         <state id="a1"/>
>>         <state id="a2"/>
>>     </state>
>> </parallel>
>> </scxml>
>>

> Ah, thanks! So, in the example above, targeting it explicitly would mean
> setting the initial state of the scxml to the history state?

I'm not sure what you mean. The initial *configuration* of the document would resolve histories to real states. Remember, there can be no pseudo-states in a configuration. If you did this:

<scxml initial="h">

and added a type="deep" attribute to your <history> (otherwise it can only target immediate siblings)

then the initial configuration would be resolved to (p -> a -> a2) because the history's parent has never been exited, so it has no historical record, so the history's default transition is used instead.

I'm not sure what the behavior should be if you don't specify type="deep". Invalid document? resolve to state 'a' because that's the sibling ancestor of 'a2'?

Note that transitions inside <history> and <initial> are not triggered like normal transitions. Following them does not constitute a microstep. Instead, they resolve (reccursively) to their real targets as if the targets had been the original targets all along.

David

Reply | Threaded
Open this post in threaded view
|

Re: [SCXML] history state in parallel state

Erik Verbruggen
On 15-7-2015 10:51, David Junger wrote:

>>> <scxml>
>>> <parallel id="p">
>>>      <history id="h">
>>>          <transition target="a2"/>
>>>      </history>
>>>      <state id="a">
>>>          <state id="a1"/>
>>>          <state id="a2"/>
>>>      </state>
>>> </parallel>
>>> </scxml>
>>>
>
>> Ah, thanks! So, in the example above, targeting it explicitly would mean
>> setting the initial state of the scxml to the history state?
>
> I'm not sure what you mean. The initial *configuration* of the document would resolve histories to real states. Remember, there can be no pseudo-states in a configuration. If you did this:
>
> <scxml initial="h">
>
> and added a type="deep" attribute to your <history> (otherwise it can only target immediate siblings)
>
> then the initial configuration would be resolved to (p -> a -> a2) because the history's parent has never been exited, so it has no historical record, so the history's default transition is used instead.
>
> I'm not sure what the behavior should be if you don't specify type="deep". Invalid document? resolve to state 'a' because that's the sibling ancestor of 'a2'?
>
> Note that transitions inside <history> and <initial> are not triggered like normal transitions. Following them does not constitute a microstep. Instead, they resolve (reccursively) to their real targets as if the targets had been the original targets all along.

Sorry, I should have added type="deep". I know that transitions in
<history> and <initial> get resolved. The question was how to trigger
the transition in a <history> state, which you answered. Thanks!

So, now for my understanding: why do history states need to be targeted
explicitly? Why not always target them implicitly?

-- Erik.