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.ans...@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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
