The more time I spend doing this, the more questions pop out. Right now I'm not that convinced that the rule base can be checked for redundancy in every situation. The most puzzling cases are the eval keyword, functions, accumulate feature and the RHS of the rule. All these give the rule base engineer a change to write his own code in to the rule. Simplifying the different kind of rules and comparing them is not easy, and code made by user makes it even harder. Right now code sections can even include a database query, this query can have restrictions that are impossible to map.
I have mentioned in my blog before that currently only MVEL code analysing is going to be implemented. At the moment also Java is used in rules, and Java is probably a lot more common in the old rule bases as the MVEL dialect was just introduced. In the future there might be other dialects, this is why the mapping of the code parts needs to be flexible enough so that it can some day implement all of the dialects.
After I finished making the data model, I continued to write the redundancy and subsumption rules for Drools. All the restrictions, patterns and different combinations of patterns and rules need to be checked. At this point the restriction rules are almost done, after that I can use data from those rules to check for redundancy in pattern. The following is a simple example:
Pattern( x == 1 && x == 1 )
The field x is checked for literal 1 twice in the same pattern. This doesn't prevent this rule from firing but it does make the rule base a bit slower. After this I'll do the pattern redundancy checks and finally the rule redundancy.
