Great! - I'm trying to stay positive ;-) The change to implement "otherwise" can be dropped from the spreadsheet version: It is only possible in Guvnor because the editor has limited function.
Negate rule: can also be dropped from the spreadsheet version. Negate pattern: I didn't realise it was already there :) FYI, I've been speaking with Mark about the prospect of replacing (or complimenting) Guvnor's guided decision table editor with what I term "tabular templating" i.e. DRL fragments as column definitions (with a single place-holder for values) and a table beneath containing the data to interpolate in the DRL fragments - much like the existing spreadsheet dtable. Sort of a hybrid between Guvnor's "Templated rules" and it's "Decision Table". Furthermore, TBH, I raised the parallel JIRAs to keep Guvnor and the spreadsheet versions operation consistent and can just as easily reject them. Happy(ier) now? Cheers, Mike On 4 April 2011 18:09, Wolfgang Laun <wolfgang.l...@gmail.com> wrote: > Sigh. > > On 4 April 2011 15:41, Michael Anstis <michael.ans...@gmail.com> wrote: > >> There is a JIRA to add this to the spreadsheet form of decision tables >> too; but I am yet to work on it. >> >> There's a few I need to get round to at some time: >> >> - https://issues.jboss.org/browse/GUVNOR-1278 (otherwise) >> >> From the xls/csv-parser's point of view: this has to be restricted to the > very simple form of the code snippet in the 2nd cell below CONDITION being > just the field name. Otherwise, it's easy to write snippet/value > combinations that can't be handled by an "otherwise" constructed from "not > in (...)". > > >> >> - https://issues.jboss.org/browse/GUVNOR-1237 (negate rule) >> >> I don't see any useful use cases for this except for a rule table > containing just two rule rows, one with the positive pattern, and one with > the negated form. Is this the reason this should be added? > > >> >> - https://issues.jboss.org/browse/GUVNOR-1284 (negate pattern) >> >> Simple preceding any single (!) pattern with not is possible right now - > you just write "not" in front of the type. > > Cheers > Wolfgang > > >> >> I will be updating the Guvnor documentation around decision tables for the >> next release. >> >> With kind regards, >> >> Mike >> >> >> >> On 4 April 2011 13:44, Wolfgang Laun <wolfgang.l...@gmail.com> wrote: >> >>> Fair enough. >>> >>> Presumably this will only be documented with Guvnor - if at all ;-) >>> >>> This way it will not confuse users writing their spreadsheets manually, >>> which was my primordial fear. >>> >>> Thanks for you patience, Michael! >>> Wolfgang >>> >>> >>> >>> On 4 April 2011 13:35, Michael Anstis <michael.ans...@gmail.com> wrote: >>> >>>> I've spoken to Mark about his direction on this can of works I fell into >>>> ;-) >>>> >>>> What has been added to Guvnor's guided decision table is the simple >>>> ability to add "else\otherwise" values to single field constraints that use >>>> literal values and either the equality or inequality operator. There are >>>> hooks in the code to add future support for other operators at the single >>>> field constraint level - not composite field constraint (I'm taking the >>>> implicit "and" between single field constraints to imply compound field >>>> constraints on a single pattern too). It is not pretending to be the much >>>> more generalised and further reaching "else\otherwise" at the whole rule >>>> level. For this I will wait until the underlying rule engine provides it >>>> "out of the box" - if ever. >>>> >>>> With kind regards, >>>> >>>> Mike >>>> >>>> >>>> On 1 April 2011 11:54, Wolfgang Laun <wolfgang.l...@gmail.com> wrote: >>>> >>>>> Hello Michael, >>>>> >>>>> On 1 April 2011 09:01, Michael Anstis <michael.ans...@gmail.com>wrote: >>>>> >>>>>> hehe, so I walked into this one with my eyes wide shut :) >>>>>> >>>>>> Given it is only possible to define implicit logical AND's between >>>>>> field constraints within a decision table and given it is not possible to >>>>>> introduce complexity with parenthesis, is the immediate problem domain >>>>>> smaller than the more generalised discussion surrounding "otherwise" or >>>>>> "else"? >>>>>> >>>>>> The first limitation can be overcome by converting multiple single >>>>>> field constraints on the same field to a single compound field >>>>>> constraint on >>>>>> the same field; thus:- >>>>>> >>>>>> r1: age > 14, age <= 28 (i.e. age > 14 && <= 28) becomes >>>>>> rx: age <= 14 || > 28 >>>>>> >>>>>> I wonder whether this problem cannot simply be resolved with >>>>>> application of DeMorgan's Theorems (something I know a little about from >>>>>> studying electronics as a student years ago). >>>>>> >>>>> >>>>> Attaboy! >>>>> >>>>> >>>>>> >>>>>> Unlike some commentators I am not an expert in first order logic, and >>>>>> therefore would appreciate guidance if people are willing to help. >>>>>> >>>>> >>>>> Well, the point is that you can come up with pretty nasty constraints >>>>> even without parentheses: >>>>> >>>>> a > $1 && != $2 && < $3 # implicit assumption: $1 < $2 < $3 >>>>> >>>>> Of course, de Morgan will help you here, too, but you'll have to >>>>> develop some hefty symbolic expression handling. >>>>> >>>>> If expressions E1, E2, are the combined logical expressions for some >>>>> field from rules r1, r2,..., the "otherwise" condition is >>>>> >>>>> ¬ ( E1 || E2 || ... ) = >>>>> ¬ E1 && ¬ E2 && ... >>>>> >>>>> and you continue to apply de Morgan's laws to all Ei. >>>>> >>>>> But what about the very natural constraint combination of two or more >>>>> fields as in my age/income example? >>>>> >>>>> Perhaps an entirely different approach should be considered, too. I'm >>>>> thinking of a generic mechanism, which would have to gain control before >>>>> any >>>>> rule from a certain rule table is executed for another fact or set of >>>>> facts. >>>>> Then you could inspect all pending activations, and whenever you have one >>>>> for a rule without an "otherwise" in a column it should discard any >>>>> activations for the same fact set for rules with an "otherwise" in that >>>>> column. I think this could be done from an agenda listener. >>>>> >>>>> -W >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Mike >>>>>> >>>>>> On 1 April 2011 07:02, Wolfgang Laun <wolfgang.l...@gmail.com> wrote: >>>>>> >>>>>>> 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 >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> >> _______________________________________________ >> 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 > >
_______________________________________________ rules-dev mailing list rules-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev
