SCORM 2004 Sequencing Tidbits #1: Post Condition Rules are a bit counter-intuitive on aggregations
Sequencing post condition rules are only evaluated when an activity is “exited”….well, duh, right? Wrong. “Exited” is a particular term in SCORM 2004 sequencing and navigation. When the current activity ends, it is exited. Its parents are not exited unless you explicitly state that they should be in the manifest.
Take this situation:
-Aggregation A (post condition rule, “always retry”)
—SCO 1
—SCO 2
-Aggregation B
—SCO 3
—SCO 4
If SCO 2 is currently active and the learner makes a choice request for SCO 3, the post condition rule on Aggregation A does not fire. Only SCO 2 is “exited” in the S&N world, even though the attempt on Aggregation A ends.
There are two ways to tell Aggregation A to exit:
1. Put a post condition on the children of Aggregation A that results in an exitParent action when they are exited.
2. Include an exit condition rule on the aggregation with an action of exit (as all exit condition rules have).
Both of these actions will cause the parent to be “exited” when a child is “exited”.
The second solution brings up another oddity. An exit condition rule on an aggregation doesn’t fire when the aggregation is “exited”, it fires when a child is “exited”. Thus the entire purpose of exit condition rules is essentially to overcome the oddity of post condition rules only firing when the S&N notion of “exiting” occurs.
