SCXML Monitoring / Debugging from the Workshop

Hey there,

working my way through the action points raised during the recent SCXML workshop on EICS, I’d like to post what we came up with towards standardizing monitoring / debugging SCXML in an eventual successor of the soon to come SCXML recommendation.

At [1] is the state flow diagram that we developed jointly during the open-panel phase of the workshop. Mapping the breakpoints from our debugger paper [2] we propose the following callbacks for monitoring / debugging SCXML documents a compliant interpreter ought to provide:

== Executable Content Callbacks:

void beforeExecutingContent(Interpreter interpreter, DOMElement element)
void afterExecutingContent(Interpreter interpreter, DOMElement element)

These are called for every XML element that is interpreted as executable content, that is, all children of <onentry>, <onexit>, <transition> and <finalize>. In the attached diagram below, these are potentially called during “Enter States”, “Taking Transitions”, “Exit States / Cancel Invokers” and “External Events?”.

== Transitioning Callbacks:

void beforeEnteringState(Interpreter interpreter, DOMElement state, bool moreComing)
void afterEnteringState(Interpreter interpreter, DOMElement state, bool moreComing)
void beforeExitingState(Interpreter interpreter, DOMElement state, bool moreComing)
void afterExitingState(Interpreter interpreter, DOMElement state, bool moreComing)
void beforeTakingTransition(Interpreter interpreter, DOMElement transition, bool moreComing)
void afterTakingTransition(Interpreter interpreter, DOMElement transition, bool moreComing)

It’s pretty obvious as to when these are called. The moreComing argument allows monitors to gather all transitions / states and only act when the last one for a given microstep was received.

== Invoker Callbacks:

beforeUninvoking(Interpreter interpreter, DOMElement invokeElem, string invokeid)
afterUninvoking(Interpreter interpreter, DOMElement  invokeElem, string invokeid)
void beforeInvoking(Interpreter interpreter, DOMElement invokeElem, string invokeid)
void afterInvoking(Interpreter interpreter, const DOMElement invokeElem, string invokeid)

We did not yet need a “moreComing” argument, but it might be useful.

== General Callbacks:

void beforeProcessingEvent(Interpreter interpreter, SCXMLEvent Event)
void beforeMicroStep(Interpreter interpreter)
void afterMicroStep(Interpreter interpreter)
void onStableConfiguration(Interpreter interpreter)
void beforeCompletion(Interpreter interpreter)
void afterCompletion(Interpreter interpreter)


There are some issues we might need to iron out if this ever becomes anything more than a post to the ML:
- Is onStableConfiguration called before invoking / uninvoking
- Is this set of callbacks sufficient, what else is useful
- Are some of those callbacks redundant, useless
- Precise timing of the callbacks in relation to the informal SCXML algorithm from the specification

I don’t necessarily expect anyone to act on this, but I’d hate for it to become wasted work.

Best regards
 Stefan

[1] http://scxmlworkshop.de/eics2014/SCXML%20StateFlow.pdf
[2] http://scxmlworkshop.de/eics2014/submissions/A%20Debugger%20for%20SCXML%20Documents.pdf