Re: Grandparent <state> for <final>

Stefan,

  Are we talking past each other?  The done event for the parallel state 
is generated only if _all_ of its children are in final (child) states.  
Isn't this the semantics you want for "joined" transitions?

- Jim


On 6/30/2017 4:05 AM, Stefan Radomski wrote:
>
>> On Jun 29, 2017, at 15:25, Jim Barnett <1jhbarnett@gmail.com 
>> <mailto:1jhbarnett@gmail.com>> wrote:
>>
>> Stefan,
>>
>>   What you are proposing is simply a different definition of being in 
>> a final state than the one the group used.  Your definition is a 
>> reasonable alternative, and if there ever is another version of SCXML 
>> we will consider it.  However this is not an erratum.  Specifically:
>>
>> 1) The current definition is the one the group explicitly chose/voted 
>> for.
>>
>> 2) The current definition does not cause any inconsistencies in the 
>> spec.
>>
>> When the group was still working, we kept an issues list for 
>> proposals to be considered in a future version of the spec.  That's 
>> where your definition would go.  Now that the Voice Browser Group is 
>> closed, I don't know if there will ever be another version, but it is 
>> too late to make changes to SCXML 1.0.
>>
> That's ok, it just seems strangely specific that a grandchildren final 
> state of a parallel should have a different semantic with regard to 
> "done.state.p" than any other descendant final state. I mean, what if 
> the other compound children are not yet in a finished state? Allowing 
> one compound to cause the parent parallel to trigger "done.state.p" 
> seems premature with regard to the intuition of the parallel "being 
> done".
>
> Our users employ the extended semantic to transition into a "joined" 
> state when all compounds in a parallel are finished. How would I 
> express a corresponding semantic then? I could go for a bunch of 
> "In()" predicate calls but that would require awareness of all other 
> compound children of the parallel state.
>
> <scxml>
> <parallel id="p0">
>         <transition event="done.state.p0" target="p0_all_joined" />
> <state id="p0_s0">
> <state id="p0_s0_s0"><final id="p0_s0_s0_f0"/></state>
> </state>
> <state id="p0_s1">
> <state id="p0_s1_s0"><final id="p0_s1_s0_f0"/></state>
> </state>
> </parallel>
>     <state id="p0_all_joined">
>         <onentry><log expr="'all compound childs of p0 are 
> finished'"/></onentry>
>     </state>
> </scxml>
>
>
> But I agree that it is obviously too late to complain.
>   Stefan
>>
>> - Jim
>>
>>
>> On 6/29/2017 3:29 AM, Stefan Radomski wrote:
>>>
>>>> On Jun 29, 2017, at 01:05, Jim Barnett <1jhbarnett@gmail.com 
>>>> <mailto:1jhbarnett@gmail.com>> wrote:
>>>>
>>>> Interesting case.  I'm pretty sure that:
>>>>
>>>> 1) The current language was what the group wanted (i.e., it's not 
>>>> an error)
>>>>
>>>> 2) We never discussed this case.
>>>>
>>>> However, to expand a bit further: suppose we add a <final> child to 
>>>> state p0_s0 (i.e. a sibling state to p0_s0_s0).  In that case we 
>>>> wouldn't want entering p0_s0_s0_f0 to put the parent p0_s0 in a 
>>>> final state - only entering its direct <final> child should do that.
>>>>
>>> Is that so? I'd say if every active atomic state in the children of 
>>> a parallel is final, then the parallel is done. Regardless of where 
>>> those final states are in the hierarchy.
>>>>
>>>> The current language forces authors to be explicit about final 
>>>> states, and is easy to understand, but in examples like yours it 
>>>> can lead to somewhat counter-intuitive results.
>>>>
>>> In my opinion, it breaks encapsulation as you need to be aware of 
>>> structures higher up the ancestry chain.
>>>>
>>>> If we try to get 'final-hood' to be inherited upward, but for the 
>>>> inheritance to be blocked by the presence explicit higher-level 
>>>> <final> states, the definition gets very complicated.
>>>>
>>> "After an interpreter enters a final state s, it checks whether any 
>>> ancestor parallel state p of s has only final states left in the 
>>> intersection between its atomic children and the active states. It 
>>> raises `done.state.[p@id]` if that is the case." I don't see why a 
>>> higher level <final> state should block the semantic at all - could 
>>> you elaborate on that?
>>>
>>> Stefan
>>>>
>>>> - Jim
>>>>
>>>>
>>>> On 6/28/2017 6:10 PM, Gavin Kistner wrote:
>>>>> A couple years ago I wrote a Lua interpreter for SCXML[1]. Stefan 
>>>>> R. just filed a bug with it[2]. At the core of the issue is 
>>>>> whether the following SCXML parallel should be 'in a final/done 
>>>>> state' after being entered:
>>>>>
>>>>> <parallel id="p0">
>>>>> <state id="p0_s0">
>>>>> <state id="p0_s0_s0"><final id="p0_s0_s0_f0"/></state>
>>>>> </state>
>>>>> <state id="p0_s1">
>>>>> <state id="p0_s1_s0"><final id="p0_s1_s0_f0"/></state>
>>>>> </state>
>>>>> </parallel>
>>>>>
>>>>> My interpreter fires "done.state.p0_s0_s0" and 
>>>>> "done.state.p0_s1_s0". However, it does not cause "p0_s0" or 
>>>>> "p0_s1" to be considered in a final state, and therefore does not 
>>>>> consider the parallel to be in a final state.
>>>>>
>>>>> On the one hand, this clearly looks like a bug in my interpreter 
>>>>> against how I would *expect* the specifications to handle this 
>>>>> situation. On the other hand, the specifications+errata only 
>>>>> appear to cover situations where a <parallel> is exactly a 
>>>>> *grandparent* of the <final>, not any further ancestor.
>>>>>
>>>>> Section 3.7 of the spec says:
>>>>>
>>>>> "When the state machine enters the <final> child of a <state> 
>>>>> element […] generate the event done.state.id [...] where id is the 
>>>>> id of the parent state. Immediately thereafter, if the parent 
>>>>> <state> is a child of a <parallel> element, and all […] other 
>>>>> children are also in final states […] generate the event 
>>>>> done.state.id where id is the id of the <parallel> element."
>>>>>
>>>>> This only covers exactly the parent of the <final>, not any 
>>>>> grandparent <state> or great-grandparent <parallel>.
>>>>>
>>>>> Further, the pseudo-code for Appendix D explicitly only handles 
>>>>> one level at the end of enterStates(), and also only handles one 
>>>>> level for the definition of isInFinalState().
>>>>>
>>>>>
>>>>> If Stefan (and my) belief about how this should behave is correct, 
>>>>> then (a) the prose in 3.7 needs to be modified via errata, and (b) 
>>>>> the isInFinalState() pseudo-code should be modified to recurse, 
>>>>> and (c) we need to discuss whether grandparent <state> also fire 
>>>>> "done.state.xxx" events when their child state becomes in a final 
>>>>> state, and if so, modify the pseudo-code in enterStates() to do so.
>>>>>
>>>>> If we're wrong—if grandparent states do not get this event fired, 
>>>>> are not considered in a final state, and if the parallel in the 
>>>>> example above should also not be in a final state—I'd be very 
>>>>> interested to hear some arguments for this.
>>>>>
>>>>> [1] https://github.com/Phrogz/LXSC
>>>>> [2] https://github.com/Phrogz/LXSC/issues/1
>>>>>
>>>>> --
>>>>> (-, /\ \/ / /\/
>>>>
>>>
>>
>