Michael,
My position is that an otherwise for a single column is likely to
cause trouble by misunderstandings. Especially the operators >, >=, <,
<= are likely to be used to separate intervals, as in
r1: age > 14, age <= 28
r2: age > 28, age <= 42
If you apply the proposed definition, the otherwise results in
rx: age <= 14, age > 42
which is obviously never true.
You can construct similar blackouts with two different fields, e.g.
r1: age > 60, income > 100000
r2: age > 40, income > 80000
You will have to do an in-depth analysis of the AST resulting from the
condition definition resulting from rule table lines $n+2 and $n+3 in
order to get it right.
My opinion is: Don't do it unless you can do it right.
Cheers
Wolfgang
PS: I could provide a definition for otherwise with matches and
soundslike, but I'd rather not.
On 31 March 2011 21:25, Michael Anstis <michael.anstis(a)gmail.com> wrote:
Hi,
I'm adding support for "otherwise" to (for the time being) the guided
decision table in Guvnor.
The idea being if you set a cell to represent "otherwise" the generated rule
is the opposite of the accumulation of the other cells; perhaps best
explained with an example:-
Person( name == )
Mark
Kris
Geoffrey
<otherwise>
This would generate:-
Person(name not in ("Mark", "Kris", "Geoffrey")
Equals is the simple example, this is my thoughts for the other operators we
might like to support:-
!= becomes "in (<list of the other cells' values)"
< becomes ">= the maximum value of the other cells' values
For example:-
Person ( age < )
10
20
30
<otherwise>
Person ( age >= 30 )
<= becomes "> the maximum value of the other cells' values
> becomes "<= the minimum value of the other cells' values
>= becomes "< the minimum value of the other cells' values
"in" becomes "not in (<a list of all values contained in all the other
cells' lists of values>)"
For example:-
Person ( name in )
Jim, Jack
Lisa, Jane, Paul
<otherwise>
Person ( name not in ("Jim", "Jack", "Lisa",
"Jane", "Paul" ) )
I'm not sure there is a simple solution for "matches" and
"soundslike" but
welcome advice, although a possibility might be to create a compound field
constraint:-
Person ( name soundslike )
Fred
Phil
not Person ( name soundslike "Fred" || soundslike "Phil" )
Would this be considered the most suitable approach?
Inputs and thoughts welcome.
Thanks,
Mike
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev