Community
Participate
Working Groups
In order to support transformation development, the EVM should allow the creation of conflict sets that only include the activations of selected rules. Such conflict sets are used for adding As-long-as-possible and similar execution primitives.
This is now supported similarly to the global conflict set of the agenda: - the user provides a conflict resolver and a set of rule specification-filter pairs in a multimap (RuleEngine.createConflictingActivationSet) - the rule engine creates a conflict set and a wrapper class that stores the conflict set, the multimap and the listener that is used for updating the contents of the confict set (the listener is registered with the rule instances) - the user can access the activations through the wrapper (ConflictingActivationSet.getNextActivation) - the wrapper can be disposed which will remove the listeners from the rule instances Note: the naming of the participating classes and methods are not final, suggestions are welcome.
The implementation seems nice, but I don't like the naming. As the goal of this is to fire a subset of the rules similar to firing all enabled rules, I would suggest the naming should also reflect this, instead of the conflict-handling nature of the code. What about RuleEngine.orderRuleSpecifications for the method name and using OrderedActivationSet as the implementation class name, and IOrderedActivationSet for the interface? Additional question: is the conflict resolver strictly required for EVM? I think, it would make sense to re-use the default resolver (or just keep it unspecified) for this reason, and a shorthand method would be nice.
I think the rule systems terminology is "conflict set", not "conflicting activation set" - it's also much shorter. > OrderedActivationSet I don't like this, ordering is just one possible way of conflict resolution > orderRuleSpecifications I like this even less; the rule specifications do not have to be ordered, even when their activations are. > Additional question: is the conflict resolver strictly required for EVM? I think, it would make sense to re-use the default resolver (or just keep it unspecified) for this reason, and a shorthand method would be nice. I'm not sure I get the question - do you mean that EVM by default should not have a global conflict set (only store activation states), and that all conflict sets (even if they are not scoped for a limited set of rules) should be created on-demand instead?
- Conflict resolution related classes moved to their own package - ConflictSet provides methods like nextActivation and getConflictResolver - ChangeableConflictSet provides the methods add/removeActivation towards the Agenda - ScopedConflictSet is a conflictSet for a given list of rule specifications and filters. - ScopedConflictSet is created with RuleEngine.createScopedConflictSet methods (currently only one shorthand for one rule, one filter is given, which uses the resolver of the agenda)
Pushing to 0.8,assigning to Abel.
Moving simpler issues to 0.8-M3. please discuss if feasible, or needs to be pushed to future.
This feature is already completed.
