For the FIRST and RULE_ORDER we already emit a Warning that those tables are by their nature already violating the 1NF and we suggest a more appropriate Hit Policy.
In any case as of today, if there are duplicate rules, we emit an Error of the 1NF violation for the duplicate rows/rules.
This enhancement (
DROOLS-6267) changes the behaviour for Collect hit policy tables only for this to be emitted as a Warning, instead of an Error.
All other scenarios of duplicate rules unchanged (will remain reported as Error).
In this case [2,3] and [4,5] are violating the 1NF.
In this specific case, this is indeed a Methodology issue and this table is better to be normalised (at the growing of symptoms, this table would become hard to manage).
In this specific case, this can be normalised on Hospital (becoming each Hospital its own Decision "can treat yes/no") or alternatively with other ways like collapsing the duplicates and emit a list of hospitals, etc.
Of course the table can be way bigger, but the gist is that duplicate rules like [1,2] would increasingly be reported, related on the number of output fields of the Notification and input Triggers.
We can always argue that all these C tables can be refactored differently, or even be refactored by including some BPMN steps too.
But in all these cases it was a deliberate choice of the User to define it as a Collect table.
All the users acknowledge the 1NF message content is valid, but the fact it is an Error made them think it was a showstopper for the use of the system.
One User after the support clarifications mentioned also by themselves, they would be fine if this was reported as a Warning instead for the Collect table.
For Collect tables only to tune the 1NF duplicate rule message from Error to Warning.
All other cases will remain as Error.