Re: [rules-dev] rules-dev Digest, Vol 56, Issue 24
Mats,
Thx for looking into this! I wonder if it wouldn't make more sense to have an
automated way of marshaling the object model rather than have a dedicated compiler.
Couldn't we find a nice and clean way to use a library like XStream on
org.drools.rule.Rule and its like for instance?
Also, in Guvnor it's possible to export in XML so it might be relevant to see how
it's done there (I still need to have a look at that myself).
All the best,
Pierre
On 8/25/2011 10:02 AM, rules-dev-request(a)lists.jboss.org wrote:
Date: Wed, 24 Aug 2011 18:50:55 +0200
From: Mats Erik Andersson<mats.andersson(a)gisladisker.se>
Subject: [rules-dev] drools-compiler: Inconsistent test rules in DRL
and in XML.
To:rules-dev@lists.jboss.org
Message-ID:<20110824165055.GB3443@mea.homelinux.org>
Content-Type: text/plain; charset=us-ascii
Dear all,
I am working on the XML Schema (which needs repairing)
and the XML formulated rules. In doing so I have stumbled
across a discrepancy between the two rule formulations
drools-compiler/src/test/resources/org/drools/compiler/xml/\
rules/test_ParseRule.{drl,xml}
which I dare claim to be in error, unless they are ment to
express different rules!
The left-hand side in "test_ParseRule.drl" expresses the logic
foo2 : Bar( ... )
# implicit AND
not( ... )
# implicit AND
foo3 : Bar( ... )
or
foo4 : Bar( ... )
or
foo5 : Bar( ... )
or
foo6 : Bar( ... )
or
Baz()
Observe that foo3 up to foo6 and Baz are connected using OR connectives
of constant precedence. Still, observing this, the expected counterpart
test_ParseRule.xml of XML form expresses
<pattern identifier="foo2" ...> ...</pattern>
<!-- implicit AND -->
<not> ...</not>
<!-- implicit AND -->
<or-conditional-element>
<pattern identifier="foo3" ...> ...</pattern>
<pattern identifier="foo4" ...> ...</pattern>
</or-conditional.element>
<!-- implicit AND -->
<pattern identifier="foo5" ...> ...</pattern>
<!-- implicit AND -->
<pattern identifier="foo6" ...> ...</pattern>
<!-- implicit AND -->
<pattern identifier="foo7" ...> ...</pattern>
<!-- implicit AND -->
<pattern object-type="Baz" />
Hence foo5, foo6, foo6 and Baz have been ejected from the
OR-clause stipulated in the DRL file, instead being part
of the outer AND-clause.
My expectation is that either DRL or XML file be generated
after parsing from the other one, but the logical models
being different, I conclude one of the files to be in error.
Depending on hard-coded precedence model between AND and OR,
the "or-conditional-element" should encompass only foo3,
or the (the generally expected) all of "foo#". To single
out only foo3 and foo4 contradicts the mathematical logic
behind the contructs.
Best regards,
Mats Andersson