“Redundancies”….There’s got to be a great quote from Office Space that should go here, but 30 seconds on Google didn’t turn it up, so sorry, no snappy quip to start the morning.

Because “Not Ain’t Always Not” in SCORM 2004 sequencing and navigation, people tend to overly explicitly define sequencing rule conditions which leads to redundant rules.

For instance, the following rule set is redundant:
<p style='background:#F0F0F0' style='font-size:10.0pt;
font-family:”Courier New”;color:#000091′><imsss:ruleConditions conditionCombination=”all”>
    <imsss:ruleCondition condition=”objectiveStatusKnown”/”>
    <imsss:ruleCondition operator=”not” condition=”satisfied”/”>
</imsss:ruleConditions”>

If the activity has achieved a status of “not satisfied” then, by definition, its objective status must be known, thus the first rule condition is redundant.

There are essentially three sequencing states relating to satisfaction: unknown, not satisfied (failed) and satisfied (passed). They are represented like this in sequencing rule conditions:

Unknown
<p style='background:#F0F0F0' style='font-size:10.0pt;
font-family:”Courier New”;color:#000091′><imsss:ruleConditions>
    <imsss:ruleCondition operator=”not” condition=”objectiveStatusKnown”/>
</imsss:ruleConditions>

Not Satisfied
<p style='background:#F0F0F0' style='font-size:10.0pt;
font-family:”Courier New”;color:#000091′><imsss:ruleConditions>
    <imsss:ruleCondition operator=”not” condition=”satisfied”/>
</imsss:ruleConditions>

Satisfied
<p style='background:#F0F0F0' style='font-size:10.0pt;
font-family:”Courier New”;color:#000091′><imsss:ruleConditions>
    <imsss:ruleCondition condition=”satisfied”/>
</imsss:ruleConditions>

Often when writing a sequencing rule, you want to say “if [one condition] do this, else do something else”. Since the “else” condition can’t be achieved with a simple NOT operator, you have to specify a condition and it’s opposite. Those pairs look like this:

Unknown vs Known
<p style='background:#F0F0F0' style='font-size:10.0pt;
font-family:”Courier New”;color:#000091′>
<imsss:ruleConditions>
    <imsss:ruleCondition operator=”not” condition=”objectiveStatusKnown”/>
</imsss:ruleConditions>
vs.
<imsss:ruleConditions>
    <imsss:ruleCondition condition=”objectiveStatusKnown”/>
</imsss:ruleConditions>

Not Satisfied vs (Unknown or Satisfied)
<p style='background:#F0F0F0' style='font-size:10.0pt;
font-family:”Courier New”;color:#000091′>
<imsss:ruleConditions>
    <imsss:ruleCondition operator=”not” condition=”satisfied”/>
</imsss:ruleConditions>
vs.
<imsss:ruleConditions conditionCombination=”any”>
    <imsss:ruleCondition operator=”not” condition=”objectiveStatusKnown”/>
    <imsss:ruleCondition condition=”satisfied”/>
</imsss:ruleConditions>

Satisfied vs (Unknown or Not Satisfied)
<p style='background:#F0F0F0' style='font-size:10.0pt;
font-family:”Courier New”;color:#000091′>
<imsss:ruleConditions>
    <imsss:ruleCondition condition=”satisfied”/>
</imsss:ruleConditions>
vs.
<imsss:ruleConditions conditionCombination=”any”>
    <imsss:ruleCondition operator=”not” condition=”objectiveStatusKnown”/>
    <imsss:ruleCondition operator=”not” condition=”satisfied”/>
</imsss:ruleConditions>

Given that multiple conditions often need to be specified to include the unknown state, does listing redundant rules as described above make things clearer or more confusing? What do you think?

Mike is the CEO of Watershed, though he is the Founder and was President of Rustici Software until 2016. He helped guide the first draft of the Tin Can API (xAPI) and believes ice cream is the "elixir of life."