1:25 a.m.
Davide has suggested a good idea.
Now that rules support annotations, and annotations with values. We
should add a before/after keyword to each rule. before/after would then
take a list of annotations. The idea is to use this to generate salience
under the covers.
rule resetBalance before( @cashflow ) when then end
rule debit @cashflow when then end
rule credit @cashflow when then end
rule printBalance after(@cashflow ) when then end.
Salience gives one rule priority over another, thus it's declaring an
implicit relationship between rules. Yet it's a magic number that
doesn't easily show this relation, and as the rulebase grows it can be
very hard to determine those relationships as specified by salience from
reading the rules. before/after allows you to specify declarative the
relationships betwen rules in a more maintainable and readable way, even
if under the covers it's just generating:
rule resetBalance salience 100 when then end
rule debit salience 0 when then end
rule credit salience 0 when then end
rule printBalance saliance -100 when then end.
Yes there are agenda-groups and ruleflow-groups, but they can be a bit
cumbersome compared to the simplicity of using salience. This way we get
the simplicity of using salience, without the downfalls of it being a
magic number.
What do people think? Any ideas on how we can improve this? At build
time it would have to report impossible to resolve relationships and barf.
Mark
7:08 a.m.
I think it would be a great idea as long as it's not just generating the salience code
below under the covers. (Taking your example literally.) But I assume you're just
creating a conflict resolution relation based on the annotations. This solves the main
problem with salience which is it's global reach. (i.e. all rules marked with salience
are related whether you want them to be or not.)
Maybe more specifically worded annotations would be good: @firesBefore() and
@firesAfter()
And you don't have it in the examples below, but I'm assuming you could have
multiple before and after annotations per rule.
Also, you mentioned agenda-groups: could this be extended to those as well? i.e. instead
of groups activating in LIFO order, be explicitly ordered by annotation?
--- On Mon, 2/13/12, Mark Proctor <mproctor(a)codehaus.org> wrote:
From: Mark Proctor <mproctor(a)codehaus.org>
Subject: [rules-dev] salience alternative with before/after
To: rules-dev(a)lists.jboss.org
Date: Monday, February 13, 2012, 6:25 PM
Davide has suggested a good idea.
Now that rules support annotations, and annotations with
values. We
should add a before/after keyword to each rule.
before/after would then
take a list of annotations. The idea is to use this to
generate salience
under the covers.
rule resetBalance before( @cashflow ) when then end
rule debit @cashflow when then end
rule credit @cashflow when then end
rule printBalance after(@cashflow ) when then end.
Salience gives one rule priority over another, thus it's
declaring an
implicit relationship between rules. Yet it's a magic
number that
doesn't easily show this relation, and as the rulebase
grows it can be
very hard to determine those relationships as specified by
salience from
reading the rules. before/after allows you to specify
declarative the
relationships betwen rules in a more maintainable and
readable way, even
if under the covers it's just generating:
rule resetBalance salience 100 when then end
rule debit salience 0 when then end
rule credit salience 0 when then end
rule printBalance saliance -100 when then end.
Yes there are agenda-groups and ruleflow-groups, but they
can be a bit
cumbersome compared to the simplicity of using salience.
This way we get
the simplicity of using salience, without the downfalls of
it being a
magic number.
What do people think? Any ideas on how we can improve this?
At build
time it would have to report impossible to resolve
relationships and barf.
Mark
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
7:28 a.m.
First of all, let me share the "responsibility" (credit or blame, up to you
:)) with my colleague and friend Stefano Bragaglia.
This said, the idea is indeed to generate salience statically at compile
time, for a few reasons:
- conflict resolution by priority is a basic and familiar strategy
- comparison of numbers is easy
- it will not add overhead, nor alter the current engine structure.
- it would be compatible with "legacy" rules tagged with salience (PROVIDED
we move from integers to floating point values)
However:
- we will adapt the salience as needed, e.g. when a new package is added.
Salience indeed determines a global, absolute total ordering within all the
rules. The proposed annotations just define a relative, partial ordering. We
would eventually generate one of the possible total orderings compatible
with the more relaxed constraints.
Notice that sometimes it won't be possible to create the ordering due to
loops - but I guess that it would be yet another bug-detecting enhancement
As for grups, we are considering to deprecate them in favor of a more
general concept (Mark will tell you more). Initially I guess that this new
feature will be local to an agenda group, agenda groups having higher
priority in determining what can fire and what can't.
However, the before/after attributes should already be flexible enough to
mimic some group-like behaviour. Mark's example is limited: an attribute, in
fact, can have nested "fields", such as:
@cashflow( color=red )
so now we can write specific precedences: before( @cashflow( red ; ) )
or more group-like precedences : before( @cashflow() )
exploiting an unification-like mechanism to decide which rule is actually
comparable to which.
In this case, you could tag all the rules in your group with @cashflow and
just one of them with the additional attribute...
Best
Davide
ps. As for the attribute names, the poll is open :)
--
View this message in context:
http://drools.46999.n3.nabble.com/salience-alternative-with-before-after-...
Sent from the Drools: Developer (committer) mailing list mailing list archive at
Nabble.com.
7:28 a.m.
First of all, let me share the "responsibility" (credit or blame, up to you
:)) with my colleague and friend Stefano Bragaglia.
This said, the idea is indeed to generate salience statically at compile
time, for a few reasons:
- conflict resolution by priority is a basic and familiar strategy
- comparison of numbers is easy
- it will not add overhead, nor alter the current engine structure.
- it would be compatible with "legacy" rules tagged with salience (PROVIDED
we move from integers to floating point values)
However:
- we will adapt the salience as needed, e.g. when a new package is added.
Salience indeed determines a global, absolute total ordering within all the
rules. The proposed annotations just define a relative, partial ordering. We
would eventually generate one of the possible total orderings compatible
with the more relaxed constraints.
Notice that sometimes it won't be possible to create the ordering due to
loops - but I guess that it would be yet another bug-detecting enhancement
As for grups, we are considering to deprecate them in favor of a more
general concept (Mark will tell you more). Initially I guess that this new
feature will be local to an agenda group, agenda groups having higher
priority in determining what can fire and what can't.
However, the before/after attributes should already be flexible enough to
mimic some group-like behaviour. Mark's example is limited: an attribute, in
fact, can have nested "fields", such as:
@cashflow( color=red )
so now we can write specific precedences: before( @cashflow( red ; ) )
or more group-like precedences : before( @cashflow() )
exploiting an unification-like mechanism to decide which rule is actually
comparable to which.
In this case, you could tag all the rules in your group with @cashflow and
just one of them with the additional attribute...
Best
Davide
ps. As for the attribute names, the poll is open :)
--
View this message in context:
http://drools.46999.n3.nabble.com/salience-alternative-with-before-after-...
Sent from the Drools: Developer (committer) mailing list mailing list archive at
Nabble.com.
8:54 a.m.
This is an excellent idea.
It should be reasonable to assume that "salience" and the use of
before/after are mutually exclusive.
Also, salience (irrespective of the way it is defined) should not be
confused with agenda groups. I tell my students that "focus" is
suitable for rule flow "in the large" and salience can be used for
fine-grained prioritizing (with the caveat that more levels than you
have fingers on your hand are evil).
The question is whether before and after should be rule annotations.
If you create a new package element you could define rule precedence
in one central place, exclusively referring to annotations, e.g.:
fire @reset before @cashflow before @print;
fire @yawn before @stretch before @scratch,
@dinner after @hightea after @lunch after @breakfast;
Here you see it at a glance, and it opens fewer possibilities for
creating loops.
-W
On 14/02/2012, Mark Proctor <mproctor(a)codehaus.org> wrote:
Davide has suggested a good idea.
Now that rules support annotations, and annotations with values. We
should add a before/after keyword to each rule. before/after would then
take a list of annotations. The idea is to use this to generate salience
under the covers.
rule resetBalance before( @cashflow ) when then end
rule debit @cashflow when then end
rule credit @cashflow when then end
rule printBalance after(@cashflow ) when then end.
Salience gives one rule priority over another, thus it's declaring an
implicit relationship between rules. Yet it's a magic number that
doesn't easily show this relation, and as the rulebase grows it can be
very hard to determine those relationships as specified by salience from
reading the rules. before/after allows you to specify declarative the
relationships betwen rules in a more maintainable and readable way, even
if under the covers it's just generating:
rule resetBalance salience 100 when then end
rule debit salience 0 when then end
rule credit salience 0 when then end
rule printBalance saliance -100 when then end.
Yes there are agenda-groups and ruleflow-groups, but they can be a bit
cumbersome compared to the simplicity of using salience. This way we get
the simplicity of using salience, without the downfalls of it being a
magic number.
What do people think? Any ideas on how we can improve this? At build
time it would have to report impossible to resolve relationships and barf.
Mark
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
5:25 p.m.
The overall idea of using labels instead of numbers is a good thing, but
I share some of the concerns Greg seems to have. It does not matter if the
underlying conflict resolution is based on numbers or not, but mixing this
concept with the concept of salience might be confusing and bring runtime
conflicts.
One situation that comes to mind is that as of today, all conflicts and
error messages are resolved by Drools at compile time. Once the knowledge
package is built, adding it to a kbase will not generate errors or make the
kbase inconsistent... so Drools has no framework to prevent such addition
or report back to the application if such operation can't be completed
because of a conflict and then safely rolled back. A feature such as this
requires runtime validation as the dependencies can be defined in different
knowledge packages where the addition of one to a kbase does not cause any
problems, but the addition of the other can cause a circular dependency.
Another related issue is that if the labels are just synonyms to
certain salience numbers, what happens when someone mixes salience numbers
with labels. How do you decide the order? Wolfgang suggests mutual
exclusivity (which also requires runtime checking), but I feel that it
would be too limiting. For some cases I prefer to simply assign a number to
one rule than having to annotate multiple rules in order to say: this
should fire before/after those rules.
In any case, Mark mentioned that he thinks that this is different from
ruleflows (and much lighter). This, in my mind, is an implementation
detail. If I am a user, at the moment, I don't see a difference between
ordering rules based on ruleflow groups and based on this before/after
other than that using ruleflow-groups, I can define my order graphically in
the flow editor, while in this thing I will have to manage priority
annotating every single rule, and if I ever need to change the order of
some of these priorities, I have to fix it in multiple places instead of a
single diagram.
My point is that while the idea of a lightweight, labeled-priority
conflict resolution is good and desirable, I think we need to mature the
idea and maybe make that change in a transparent way for the user. Maybe
this whole concept can be unified with Mark's uber-group idea instead of
creating a separate feature that will be hard to manage and use...
My .02c
Edson
On Tue, Feb 14, 2012 at 2:54 AM, Wolfgang Laun <wolfgang.laun(a)gmail.com>wrote:
This is an excellent idea.
It should be reasonable to assume that "salience" and the use of
before/after are mutually exclusive.
Also, salience (irrespective of the way it is defined) should not be
confused with agenda groups. I tell my students that "focus" is
suitable for rule flow "in the large" and salience can be used for
fine-grained prioritizing (with the caveat that more levels than you
have fingers on your hand are evil).
The question is whether before and after should be rule annotations.
If you create a new package element you could define rule precedence
in one central place, exclusively referring to annotations, e.g.:
fire @reset before @cashflow before @print;
fire @yawn before @stretch before @scratch,
@dinner after @hightea after @lunch after @breakfast;
Here you see it at a glance, and it opens fewer possibilities for
creating loops.
-W
On 14/02/2012, Mark Proctor <mproctor(a)codehaus.org> wrote:
> Davide has suggested a good idea.
>
> Now that rules support annotations, and annotations with values. We
> should add a before/after keyword to each rule. before/after would then
> take a list of annotations. The idea is to use this to generate salience
> under the covers.
>
> rule resetBalance before( @cashflow ) when then end
>
> rule debit @cashflow when then end
>
> rule credit @cashflow when then end
>
> rule printBalance after(@cashflow ) when then end.
>
> Salience gives one rule priority over another, thus it's declaring an
> implicit relationship between rules. Yet it's a magic number that
> doesn't easily show this relation, and as the rulebase grows it can be
> very hard to determine those relationships as specified by salience from
> reading the rules. before/after allows you to specify declarative the
> relationships betwen rules in a more maintainable and readable way, even
> if under the covers it's just generating:
>
> rule resetBalance salience 100 when then end
>
> rule debit salience 0 when then end
>
> rule credit salience 0 when then end
>
> rule printBalance saliance -100 when then end.
>
> Yes there are agenda-groups and ruleflow-groups, but they can be a bit
> cumbersome compared to the simplicity of using salience. This way we get
> the simplicity of using salience, without the downfalls of it being a
> magic number.
>
> What do people think? Any ideas on how we can improve this? At build
> time it would have to report impossible to resolve relationships and
barf.
>
> Mark
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
5:42 p.m.
Other's have answered most your Qs, so I'll just answer one part inline.
On 14/02/2012 06:08, Greg Barton wrote:
I think it would be a great idea as long as it's not just
generating the salience code below under the covers. (Taking your example literally.) But
I assume you're just creating a conflict resolution relation based on the annotations.
This solves the main problem with salience which is it's global reach. (i.e. all
rules marked with salience are related whether you want them to be or not.)
Maybe more specifically worded annotations would be good: @firesBefore() and
@firesAfter()
And you don't have it in the examples below, but I'm assuming you could have
multiple before and after annotations per rule.
Also, you mentioned agenda-groups: could this be extended to those as well? i.e. instead
of groups activating in LIFO order, be explicitly ordered by annotation?
Yes I think
annotations make the keyword's ruleflow-group and
agenda-group redundant. The labels automatically place rules into
groups, so we can add method calls that dictate how to execute that
group, i.e. linearly (ruleflow-group) or stack (agenda-groups). The idea
needs some more thought and fleshing out, but I'll update my
DroolsModules page to mention "before"/"after" as well as using labels
as alternative grouping mechanisms to agenda-group and ruleflow-group:
http://community.jboss.org/wiki/DroolsModule
Mark
--- On Mon, 2/13/12, Mark Proctor<mproctor(a)codehaus.org> wrote:
> From: Mark Proctor<mproctor(a)codehaus.org>
> Subject: [rules-dev] salience alternative with before/after
> To: rules-dev(a)lists.jboss.org
> Date: Monday, February 13, 2012, 6:25 PM
> Davide has suggested a good idea.
>
> Now that rules support annotations, and annotations with
> values. We
> should add a before/after keyword to each rule.
> before/after would then
> take a list of annotations. The idea is to use this to
> generate salience
> under the covers.
>
> rule resetBalance before( @cashflow ) when then end
>
> rule debit @cashflow when then end
>
> rule credit @cashflow when then end
>
> rule printBalance after(@cashflow ) when then end.
>
> Salience gives one rule priority over another, thus it's
> declaring an
> implicit relationship between rules. Yet it's a magic
> number that
> doesn't easily show this relation, and as the rulebase
> grows it can be
> very hard to determine those relationships as specified by
> salience from
> reading the rules. before/after allows you to specify
> declarative the
> relationships betwen rules in a more maintainable and
> readable way, even
> if under the covers it's just generating:
>
> rule resetBalance salience 100 when then end
>
> rule debit salience 0 when then end
>
> rule credit salience 0 when then end
>
> rule printBalance saliance -100 when then end.
>
> Yes there are agenda-groups and ruleflow-groups, but they
> can be a bit
> cumbersome compared to the simplicity of using salience.
> This way we get
> the simplicity of using salience, without the downfalls of
> it being a
> magic number.
>
> What do people think? Any ideas on how we can improve this?
> At build
> time it would have to report impossible to resolve
> relationships and barf.
>
> Mark
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
5:53 p.m.
On 14/02/2012 16:25, Edson Tirelli wrote:
The overall idea of using labels instead of numbers is a good
thing, but I share some of the concerns Greg seems to have. It does
not matter if the underlying conflict resolution is based on numbers
or not, but mixing this concept with the concept of salience might be
confusing and bring runtime conflicts.
One situation that comes to mind is that as of today, all
conflicts and error messages are resolved by Drools at compile time.
Once the knowledge package is built, adding it to a kbase will not
generate errors or make the kbase inconsistent... so Drools has no
framework to prevent such addition or report back to the application
if such operation can't be completed because of a conflict and then
safely rolled back. A feature such as this requires runtime validation
as the dependencies can be defined in different knowledge packages
where the addition of one to a kbase does not cause any problems, but
the addition of the other can cause a circular dependency.
agreed.
For this to work we must be able to detect if a kbase change is invalid
and roll back. We need this feature anyway, not just for label based
conflict resolution, but also for other typs of problems. Such as trying
to remove type declaration for a type used in rules that are still present.
Another related issue is that if the labels are just synonyms to
certain salience numbers, what happens when someone mixes salience
numbers with labels. How do you decide the order? Wolfgang suggests
mutual exclusivity (which also requires runtime checking), but I feel
that it would be too limiting. For some cases I prefer to simply
assign a number to one rule than having to annotate multiple rules in
order to say: this should fire before/after those rules.
In any case, Mark mentioned that he thinks that this is different
from ruleflows (and much lighter). This, in my mind, is an
implementation detail. If I am a user, at the moment, I don't see a
difference between ordering rules based on ruleflow groups and based
on this before/after other than that using ruleflow-groups, I can
define my order graphically in the flow editor, while in this thing I
will have to manage priority annotating every single rule, and if I
ever need to change the order of some of these priorities, I have to
fix it in multiple places instead of a single diagram.
The main different is
salience is "inline" you don't need external
declarations/invokcations to control orderling like you do with
ruleflow-groups and agenda-groups. So ignoring the implementation it's
use is "lighter" for users.
But both "inlining" before and after and also externalising the control
are compliementary things, actually the externalising aspect ties in
with our idea for "classifical planning",
http://en.wikipedia.org/wiki/STRIPS. ruleflow-groups and agend-agroups
have it all wrong. ruleflow-groups are processes and thus brittle for
change, agenda-groups have no over all archicture. Hiearathical Task
Networks can be visualised a as a graph, yet are much more robust and
fully rule based. So while before/after might handle "inline" we'll
probably take a HTN approach for externalisation.
My point is that while the idea of a lightweight, labeled-priority
conflict resolution is good and desirable, I think we need to mature
the idea and maybe make that change in a transparent way for the user.
Maybe this whole concept can be unified with Mark's uber-group idea
instead of creating a separate feature that will be hard to manage and
use...
damn, and I was about to commit a working implementation ;)
My .02c
Edson
On Tue, Feb 14, 2012 at 2:54 AM, Wolfgang Laun
<wolfgang.laun(a)gmail.com <mailto:wolfgang.laun@gmail.com>> wrote:
This is an excellent idea.
It should be reasonable to assume that "salience" and the use of
before/after are mutually exclusive.
Also, salience (irrespective of the way it is defined) should not be
confused with agenda groups. I tell my students that "focus" is
suitable for rule flow "in the large" and salience can be used for
fine-grained prioritizing (with the caveat that more levels than you
have fingers on your hand are evil).
The question is whether before and after should be rule annotations.
If you create a new package element you could define rule precedence
in one central place, exclusively referring to annotations, e.g.:
fire @reset before @cashflow before @print;
fire @yawn before @stretch before @scratch,
@dinner after @hightea after @lunch after @breakfast;
Here you see it at a glance, and it opens fewer possibilities for
creating loops.
-W
On 14/02/2012, Mark Proctor <mproctor(a)codehaus.org
<mailto:mproctor@codehaus.org>> wrote:
> Davide has suggested a good idea.
>
> Now that rules support annotations, and annotations with values. We
> should add a before/after keyword to each rule. before/after
would then
> take a list of annotations. The idea is to use this to generate
salience
> under the covers.
>
> rule resetBalance before( @cashflow ) when then end
>
> rule debit @cashflow when then end
>
> rule credit @cashflow when then end
>
> rule printBalance after(@cashflow ) when then end.
>
> Salience gives one rule priority over another, thus it's
declaring an
> implicit relationship between rules. Yet it's a magic number that
> doesn't easily show this relation, and as the rulebase grows it
can be
> very hard to determine those relationships as specified by
salience from
> reading the rules. before/after allows you to specify
declarative the
> relationships betwen rules in a more maintainable and readable
way, even
> if under the covers it's just generating:
>
> rule resetBalance salience 100 when then end
>
> rule debit salience 0 when then end
>
> rule credit salience 0 when then end
>
> rule printBalance saliance -100 when then end.
>
> Yes there are agenda-groups and ruleflow-groups, but they can be
a bit
> cumbersome compared to the simplicity of using salience. This
way we get
> the simplicity of using salience, without the downfalls of it
being a
> magic number.
>
> What do people think? Any ideas on how we can improve this? At build
> time it would have to report impossible to resolve relationships
and barf.
>
> Mark
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com <http://www.jboss.com>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
6:29 a.m.
I think that salience and priorities could be mixed, provided that we shift
to real numbers in place of integers - to accomodate for anything "in
between" two already assigned values.
In addition, we could have "salience > x" rather than just "salience
x"
I also like Wolfgang's idea of supporting both rule-scoped and centralized
constraints
--
View this message in context:
http://drools.46999.n3.nabble.com/salience-alternative-with-before-after-...
Sent from the Drools: Developer (committer) mailing list mailing list archive at
Nabble.com.
4447
days inactive
4448
days old
8 comments
5 participants
participants (5)
-
Davide Sottara -
Edson Tirelli -
Greg Barton -
Mark Proctor -
Wolfgang Laun