Re: Requesting guidance on scxml-irp test236.txml

The final state in question is a child of <scxml>, and section 3.7.2 
says "When the state machine reaches the <final> child of an <scxml> 
element, it /MUST/ terminate."  That holds whether the session has been 
invoked or not.  Now it's bit sloppy that the prose doesn't state that 
this involves executing the <onexit> handler of the <final> state, but 
in the pseudo-code the  procedure exitInterpreter shows this happening:

procedure exitInterpreter():
     statesToExit = configuration.toList().sort(exitOrder)
     for s in statesToExit:
         for content in s.onexit.sort(documentOrder):
             executeContent(content)
         for inv in s.invoke:
             cancelInvoke(inv)
         configuration.delete(s)
         if isFinalState(s) and isScxmlElement(s.parent):
             returnDoneEvent(s.donedata)

Does this answer your question?

  - Jim


On 7/5/2017 10:49 AM, Jacob Beard wrote:
> Hello,
>
> In the SCXML IRP test236.txml, there is a final state that contains an 
> <onexit> action:
>
> <final id="subFinal">
>   <onexit>
>     <send target="#_parent" event="childToParent"/>
>   </onexit>
> </final>
>
> https://www.w3.org/Voice/2013/scxml-irp/236/test236.txml
>
>
>
> In test236, it appears that the invoked session is not cancelled, as 
> state s0 is not exited before the invoking session receives the 
> done.invoke.id event. My question is, how can the onexit handler in 
> state subFinal fire under this scenario?
>
> My main assumption is that the only method to trigger the exit handler 
> of a final state is to cancel the invoked session. This is described 
> in the spec:
>
> /... if the invoking state machine exits the state containing the 
> invocation before it receives the done.invoke.id event, it cancels the 
> invoked session. The method for doing this is platform-specific. 
> However, when it is cancelled, the invoked session must exit at the 
> end of the next microstep. The Processor must execute the <onexit> 
> handlers for all active states in the invoked session, but it must not 
> generate the done.invoke.id event. Once it cancels the invoked 
> session, the Processor must ignore any events it receives from that 
> session. In particular it must not not insert them into the external 
> event queue of the invoking session./
> /
> /
>
> To cancel the invoked session, the invoking session must take a 
> transition out of the state containing the <invoke> before the 
> invoking session receives the done.invoke.id event, as described in 
> the spec:
> /
> /
> /If the invoking session takes a transition out of the state 
> containing the <invoke> before it receives the 'done.invoke.id' event, 
> the SCXML Processor must automatically cancel the invoked component 
> and stop its processing. The cancel operation must act as if it were 
> the final <onexit> handler in the invoking state./
> /
> /
> /
> /
> /
> /
> In test236, it appears that the invoked session is not cancelled, as 
> state s0 is not exited before the invoking session receives the 
> done.invoke.id event, therefore the onexit handler of state subFinal 
> should not fire. Is there a way for the onexit handler of a final 
> state to fire, other than by canceling the invoked session?
>
> I would appreciate your guidance on the expected behavior of this test 
> case. Thank you for looking into this,
>
> Jacob Beard