This section is for advanced users only, and will probably not be needed by most users of the Commons SCXML library.
The Commons SCXML state machine engine is really a tuple, the SCXMLExecutor (an API that new users can code to, and is almost always sufficient) accompanied by a SCXMLSemantics implementation (an API that advanced users can code to, to change the engine behavior to suit their needs).
The basic modus operandi for an engine is simple - when an event is triggered, figure out which (if any) transition(s) to follow, and transit to the new set of states executing any specified actions along the way. The default semantics available in the Commons SCXML distribution, which is based upon the SCXML specification rules for the Algorithm for SCXML processing, can be replaced with custom semantics provided by the user using the SCXMLExecutor constructor that takes the SCXMLSemantics parameter i.e. the engine semantics are "pluggable".
Consider dispute resolution for example -- when more than one outbound transitions from a single state hold true. The default SCXMLSemantics implementation available in the distribution does none, it will follow all filtered transitions, possibly leading to a ModelException immediately or down the road. However, a user may want:
Even after one of above dispute resolution algorithms is applied, if there are more than one candidate transitions, the user may want:
To implement any of the above choices, the user may extend the default SCXMLSemantics implementation, override one or more of the existing implemention methods, or even write a new implementation from scratch, and plug in the new semantics while instantiating the SCXMLExecutor. The pluggability allows differing semantics to be developed for the Commons SCXML engine, independent of the Commons SCXML codebase.