The drools-expert documentation would be a good starting point; otherwise Wikipedia has a good overview of the RETE algorithm (all be it Drools has its own extensions).<br><br>Regarding your specifics; you could look into using a DSL for the domain experts rather than pure DRL. Also, the no-loop attribute could\should help with your looping fear (have a look in the documentation).<br>
<br>A rather disturbing example you choose to show in your email; I think I prefer the &quot;Cheese&quot; centric types in the documentation :)<br><br>Cheers,<br><br>Mike<br><br><div class="gmail_quote">On 6 December 2010 09:15, Gabor Szokoli <span dir="ltr">&lt;<a href="mailto:szocske@gmail.com">szocske@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi there,<br>
<br>
We are evaluating Drools for an industry project. Trouble is, I&#39;m not<br>
good at ignoring men behind curtains, and need to know how things<br>
actually work.<br>
Links to papers explaining the theory and principles of Drools Expert<br>
are highly appreciated.<br>
<br>
Some specifics:<br>
<br>
We have a network of domain objects, with basic attributes (numbers,<br>
strings, enums) and two-way mapped associations.<br>
Rules modify the basic attributes only. Associations (references and<br>
reference sets) are static.<br>
&quot;where&quot; conditions refer to both static information and modifiable attributes.<br>
I was wondering how I can express this distinction in my domain<br>
objects without sacrificing readability of the actual rules?<br>
(Domain experts should be able to edit the rules themselves.)<br>
<br>
Here&#39;s the current pattern of my rules:<br>
<br>
<br>
rule &quot;child molester&quot;<br>
where<br>
        $parent : Parent( ... )<br>
        $child: Child(parent==$parent ... attribute!=&quot;value&quot;)<br>
then<br>
        modify ($child) { setAttribute(&quot;value&quot;) }<br>
end<br>
<br>
I&#39;m not happy my users need to know about the setter methods instead<br>
of using the same reflection-backed notation as in the condition.<br>
I also worry they&#39;ll make infinite loops by omitting the<br>
&quot;attribute!=value&quot; clause.<br>
<br>
So I guess I should elevate the attributes to first class status in my<br>
model to make them the atomic unit of triggering, but how do I do that<br>
elegantly?<br>
<br>
rule &quot;attribute molester&quot;<br>
where<br>
        $parent : Parent( ... )<br>
        $attribute : StringHolder(get()!=&quot;value&quot;)<br>
        $child: Child(parent==$parent ... attribute=$attribute)<br>
then<br>
        modify ($attribute) { set(&quot;value&quot;) }<br>
end<br>
<br>
<br>
That looks worse than before! Please share your thoughts.<br>
<br>
<br>
Thanks in advance:<br>
<font color="#888888"><br>
Gabor Szokoli<br>
_______________________________________________<br>
rules-users mailing list<br>
<a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
</font></blockquote></div><br>