[rules-users] Rule one-by-one comparison

miguel machado mls.machado at gmail.com
Fri Aug 26 12:12:45 EDT 2011


Thank you guys, you rock.

_ miguel, PT





2011/8/26 Swindells, Thomas <TSwindells at nds.com>

> xPath is also a pretty powerful solution, have one xPath that fines the
> rule node, then against that node run a pair of xpath expression which
> extract the agenda-group value and the literal restriction value(s).****
>
> ** **
>
> Thomas****
>
> ** **
>
> *From:* rules-users-bounces at lists.jboss.org [mailto:
> rules-users-bounces at lists.jboss.org] *On Behalf Of *Wolfgang Laun
> *Sent:* 26 August 2011 16:58
>
> *To:* Rules Users List
> *Subject:* Re: [rules-users] Rule one-by-one comparison****
>
> ** **
>
> Perhaps you consider using JAXB for creating Java classes from the XML
> schema, which lets you unmarshall the XML file into an object tree which is
> easy to traverse and provides you with all the data as objects and lists; no
> string parsing at all.
>
> -W
>
> ****
>
> 2011/8/26 miguel machado <mls.machado at gmail.com>****
>
> Hi there,****
>
> ** **
>
> I'm considering analyzing the pre-compiled xml document as a "last resort":
> I actually find it easier to deal with objects/collections/arrays than with
> Strings and XML, etc. This is a personal stance with no much foundation
> regarding this specific drools scenario, really. ****
>
> ** **
>
> What I need to do (before the actual comparison) is to group the rules
> according to the agenda-group plus a variable value within a condition
> within every <rule>, such as this:****
>
> ** **
>
> <rule>****
>
>   ...****
>
>   <rule-attribute name="agenda-group" value="0da90b15" />****
>
>   ...****
>
>   <field-constraint field-name="object">****
>
>     <literal-restriction evaluator="==" value="d:" /> <!--
> LiteralConstraint java object -->****
>
>   </field-constraint>****
>
>   ...****
>
> </rule>****
>
> ** **
>
> (in this case I'd like to index this rule to a 2-key hashmap => [0da90b15,
> "d:"])****
>
> ** **
>
> XML manipulation would mean parsing hundreds of rules, extracting the
> agenda-group and the "object" condition manually. Further down the road, I
> will also need to extract the whole LHS to perform the comparison. I'm
> afraid this would take too long, but I might be wrong.****
>
> ** **
>
> Thanks again,****
>
> _ miguel, PT****
>
> ** **
>
> ** **
>
> ** **
>
> 2011/8/26 Swindells, Thomas <TSwindells at nds.com>****
>
> Wouldn’t it be easier to analyze the pre-converted xml document rather than
> trying to do it on the compiled knowledge base (presumably you keep the old
> xml file around) – this way it is just string and xml manipulation, though
> it depends on how exactly the matches must be.****
>
>  ****
>
> Thomas****
>
>  ****
>
> *From:* rules-users-bounces at lists.jboss.org [mailto:
> rules-users-bounces at lists.jboss.org] *On Behalf Of *miguel machado
> *Sent:* 26 August 2011 15:55****
>
>
> *To:* Rules Users List
> *Subject:* Re: [rules-users] Rule one-by-one comparison****
>
>  ****
>
> Hi there,****
>
>  ****
>
> Thanks for replying. I will try to explain my current challenge a bit
> further:****
>
>  ****
>
> I have a ruleset which is sent by an external application in XML format. I
> load it to a new knowledge package and then into a knowlegde base. It is
> made of smaller subsets of 3 rules each (a "set" rule, a "reset" rule and a
> "clear" rule) that control my application's internal logic, which must be
> stateful and kept on disk (basically, there are 2 important hashmaps).****
>
>  ****
>
> Whenever the rules change, a new XML ruleset is sent and my application
> restarts and loads the new file the exact same way. However, I need to
> resume the application state (as it was before the restart). I also have to
> do this selectively, because I only care about the application state on a
> per-rule basis:****
>
>  ****
>
> - If a rule keeps the same LHS, I need to resume the application state
> before restart regarding that rule;****
>
> - If a rule has been modified, I may discard the state regarding that rule
> (do not need to load it);****
>
>  ****
>
> I don't think I can refactor this problem into smaller ones, the
> application internal logic is indeed complex I'm afraid. The rules are
> analyzed in a stateless way BUT they control a set of critical information
> which must be stateful (beyond restarts). There is a (not-so-direct)
> correspondence between each (fire, reset, clear) rule subset and the
> information that keeps track of the internal state, so that's why I need to
> verify rule-by-rule what has changed between restarts.****
>
>  ****
>
> I hope this helps to describe the problem.****
>
> Thanks again for reading. Any help is greatly appreciated.****
>
>  ****
>
> _ miguel, PT****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
> 2011/8/26 Swindells, Thomas <TSwindells at nds.com>****
>
> Can you share what you actual requirement is and why you need to do it?***
> *
>
> Can you perhaps change the problem into one that is simpler to solve?****
>
> Ie rather than comparing knowledge bases can you get the input to these
> knowledgebases?****
>
> Can you control what that input is, if it is a DSL or a spreadsheet then
> your comparision job will probably become a lot simpler.****
>
>  ****
>
> Thomas****
>
>  ****
>
> *From:* rules-users-bounces at lists.jboss.org [mailto:
> rules-users-bounces at lists.jboss.org] *On Behalf Of *miguel machado
> *Sent:* 26 August 2011 13:01
> *To:* Rules Users List
> *Subject:* Re: [rules-users] Rule one-by-one comparison****
>
>  ****
>
> Esteban,****
>
>  ****
>
> Thank you very much for that. I will look into it.****
>
> Any other ideas, anyone?****
>
>  ****
>
> _ miguel****
>
>  ****
>
>  ****
>
>  ****
>
> 2011/8/26 Esteban Aliverti <esteban.aliverti at gmail.com>****
>
> You can try to use drools-verifier. This project basically lets you define
> rules about your rules. ****
>
> You can have a look at its tests to see how it works.****
>
> You can get more info about drools-verifier here:
> http://community.jboss.org/wiki/DroolsVerifier****
>
>  ****
>
> And here you can see how are we using drools-verifier inside Guvnor:
> http://ilesteban.wordpress.com/2010/04/05/guvnors-field-constraints/ ****
>
>  ****
>
> Best Regards,****
>
>
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>
> Esteban Aliverti
> - Developer @ http://www.plugtree.com
> - Blog @ http://ilesteban.wordpress.com****
>
> 2011/8/26 miguel machado <mls.machado at gmail.com>****
>
> Hi there everybody,
> ****
>
>  ****
>
> I need to perform rule comparison on a project I'm working on using drools
> expert 5.0. For a specific feature implementation, I have two different
> knowledge bases with several rules which I need to compare, one by one. By
> comparing, I mean "inspect" certain conditions within the LHS.****
>
>  ****
>
> Currently, I'm able to obtain several attributes from rules
> (org.drools.rule.Rule), such as the agenda-group and the rule name and a few
> others, but I haven't been able to do it all. Going deeper, there is
> LiteralConstraint (for simple conditions) which I can parse and obtain data.
> However, I don't know how to do it for OR-conditions, which I guess
> represents a MultiRestrictionFieldConstraint. Perhaps there is another way?
> ****
>
>  ****
>
> I know this may seem like a very unorthodox thing to do, but I don't think
> there is a better way of comparing knowledge packages (except for full text
> comparison). Is there?****
>
>  ****
>
> Thanks in advance,****
>
> _ miguel, PT****
>
>  ****
>
>  ****
>
> -- ****
>
> "To understand what is recursion you must first understand recursion"****
>
>  ****
>
>  ****
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users****
>
>  ****
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users****
>
>
>
> ****
>
>  ****
>
> -- ****
>
> "To understand what is recursion you must first understand recursion"****
>
>  ****
>
>  ****
> ------------------------------
>
>
>
> **************************************************************************************
> This message is confidential and intended only for the addressee. If you
> have received this message in error, please immediately notify the
> postmaster at nds.com and delete it from your system as well as any copies.
> The content of e-mails as well as traffic data may be monitored by NDS for
> employment and security purposes. To protect the environment please do not
> print this e-mail unless necessary.
>
> NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18
> 4EX, United Kingdom. A company registered in England and Wales. Registered
> no. 3080780. VAT no. GB 603 8808 40-00
>
> **************************************************************************************
> ****
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users****
>
>
>
> ****
>
>  ****
>
> -- ****
>
> "To understand what is recursion you must first understand recursion"****
>
>  ****
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users****
>
>
>
> ****
>
> ** **
>
> -- ****
>
> "To understand what is recursion you must first understand recursion"****
>
> ** **
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users****
>
> ** **
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>


-- 
"To understand what is recursion you must first understand recursion"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20110826/6f68d16a/attachment.html 


More information about the rules-users mailing list