skip to main content
Corticon Studio: Rule Modeling Guide : Filters and preconditions : Using collection operators in a filter : Location matters
 

Try Corticon Now
Location matters
Unfortunately, order independence does not apply to conditional expressions that include collection operations. In the following Rulesheets, notice that one of the conditional expressions uses the collection operator ->size, and therefore must use an alias to represent the collection Person.
Figure 183. Collection Operator in Condition row
Figure 184. Collection Operator in Filter row
The Rulesheets appear identical with the exception of the location of the two conditional statements. But do they produce identical results? Let's test the Rulesheets to see, testing Collection Operator in Condition row first:
Figure 185. Ruletest with 3 Skydivers
What happened here? Because Filters are always applied first, our Rulesheet initially screened or filtered out the elements of collection person whose skydiver value was false. Think of the Filter as allowing only skydivers to pass through to the rest of the Rulesheet. The Conditional rule then checks to see if the number of elements in collection person is more than 3. If it is, then ALL person elements in the collection that pass through the filter (in other words, all skydivers) receive a riskRating value of 'high'. Because our first Ruletest included only 3 skydivers, the collection fails the Conditional rule, and no value is assigned to riskRating for any of the elements, skydiver or not.
Let's modify the Ruletest and rerun the rules:
Figure 186. Ruletest with 4 Skydivers
It's clear from this run that our rules fired correctly, and assigned a riskRating of ‘high' to all skydivers for a collection containing more than 3 skydivers.
Now let's test the Rulesheet in Collection Operator in Filter row, where the rule containing the collection operation is in the Filters section.
Figure 187. Ruletest with 3 Skydivers
What happened this time? Because Filters apply first, the ->size operator counted the number of elements in our person collection, regardless of who skydives and who does not. Here, the Filter allows any collection – and the whole collection – of more than 3 persons to pass through to the Conditions section of the Rulesheet. Then, the Conditional rule checks to see if any of the elements in collection person skydive. Each person who skydives receives a riskRating value of high. Even though our Ruletest included only 3 skydivers, the collection contains 4 persons and therefore passes the Preconditional filter. Any skydiver in the collection then has its riskRating assigned a value of high.
It's important to point out that the Rulesheets in Collection Operator in Condition row and Collection Operator in Filter row really implement two different business rules. When we built our Rulesheets, we neglected to write the plain-language business rule statements (violating our methodology!). The rule statements for these two Rulesheets would look like this:
The difference here is subtle but important. In the first rule statement, we are testing for skydivers within groups that contain more than 3 skydivers. In the second, we are testing for skydivers within groups of more than 3 people.