<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
A RuleML and/or RIF parser to Drools would certainly be welcome :)<br>
<br>
Mark<br>
On 11/01/2012 00:30, Edson Tirelli wrote:
<blockquote
cite="mid:CAD7AJnfShvSntnestxD+8ey4+NmBn3ess5S=_vRhFdy3+=dWFA@mail.gmail.com"
type="cite">
<div><br>
</div>
Just to add to Mark's comments, there are options for you to
move forward.
<div><br>
</div>
<div> The main bit that probably got you off track is the
DRLDumper. That class was used mainly for debugging purposes. No
code in Drools makes use of it, and because of that, we didn't
have any extensive tests in place for it... result is it broke
and no one noticed until a couple months ago. I will try to take
some time to fix it for 5.4 (it is wrong in 5.2/5.3) or just
remove it completely, as again, it is not used by drools
itself... it was just a debugging utility class we used some
time ago.</div>
<div><br>
</div>
<div> Regarding the options for this customer, I suggest we move
this discussion to an internal thread. Open a ticket or mail me
directly on the corporate e-mail and we can continue from there.</div>
<div> <br>
</div>
<div> Regards,</div>
<div> Edson<br>
<br>
<div class="gmail_quote">On Tue, Jan 10, 2012 at 6:39 PM, Mark
Proctor <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:mproctor@codehaus.org">mproctor@codehaus.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Rule base systems
typically had simple languages. Data structures where
either list or frames, the number of constructs are very
limited. Complex expressions, such as nested accessors did
not exist - like with Drools 3.0. That made it very easy
to support a 1 to 1 mapping in xml.<br>
<br>
Around Drools 4 out langauge become more expression, we
started to allow complex expresisons inside of patterns.
In Drools 5.3 that is even more so. It quickly became
obvious that xml representation fo drools would also need
a representation for java expressions, this was going to
be a lot of work - especially as we would probably have to
change a lot of the existing xml.<br>
<br>
It seems very few people are using the xml, certainly no
one seemed to care about it. Xml parsers and schemas is
something that every java developer can do, but no one has
come forward maintain this. So we've let it die.<br>
<br>
I'm not sure I'd want to resurrect it, for a one of piece
of work. It's likely the maintainenance of this would
soon fall back on the core developers.<br>
<br>
I think I'd rather see xml efforts around RuleML and/or
RIF. So imho if you want to do anything, do it around
those. The downside is that representing our more powerful
constructs like sliding time windows may not be possible
in those languages, and you would need to define
extensions.<br>
<br>
Mark
<div>
<div class="h5"><br>
On 10/01/2012 22:08, Justin Holmes wrote: </div>
</div>
<blockquote type="cite">
<div>
<div class="h5">
<div
style="direction:ltr;font-size:x-small;font-family:Tahoma">
<div dir="ltr"><font color="#000000" face="Tahoma">Hello
Devs,</font></div>
<div dir="ltr"> </div>
<div dir="ltr"><font color="#000000" face="Tahoma">My
name is Justin Holmes and I'm a Middleware
Consultant for Red Hat. I'm currently staffed
on an engagement that provides a very
interesting use case for Drools. In
particular, our teams currently believes that
the Drools XML Language would be the best
possible solution for one of our problem. We
are aware that the Drools XML language has not
been developed for sometime and is considered
deprecated. Additionally, the application will
need to support Drools CEP functionality in
the near future. Before we begin crafting a
custom solution, we would like to ask: <br>
1) Is the XML language truly the best option
for our use case? <br>
2) If it is the best option, how do we begin
developing the XML language and tools
(XMLPackageReader) to fully support at
least BRMS 5.2?</font></div>
<div dir="ltr"> </div>
<div dir="ltr"><font color="#000000" face="Tahoma"><strong>Context:
</strong> </font></div>
<div dir="ltr"><font color="#000000" face="Tahoma">Client
is using Drool 5.1.1 and we are migrating
to BRMS 5.2. There are two independent
workflows of interest: </font></div>
<div dir="ltr"> </div>
<div dir="ltr"><font color="#000000" face="Tahoma"><strong>1)
Rule Authoring and DRL generation</strong>:
The rule assets and metadata are kept in a
custom format (both relational DB and XML) in
order to decouple it from the runtime. Thus,
the client wrote their own GUI and content
manager instead of using Guvnor. The custom
GUI allows business users to author 3 types of
content, as well as rules for these types of
content, using a guided-rule editor with
domain specific language. The following steps
occur when a user wants to produce a new
version of a rule:</font></div>
<div dir="ltr"><font color="#000000" face="Tahoma"><font
color="#000000" face="Tahoma"><font
color="#000000" face="Tahoma">i</font></font>)
GUI saves LHS rule logic in an XML database
using MathML (<a moz-do-not-send="true"
href="http://www.w3.org/Math/"
target="_blank">http://www.w3.org/Math/</a>),
and then saves everything else in a relational
database.<br>
ii) iBATIS pulls down
the corresponding database and XML entries and
populates POJOs. There is 1 class
definition per content type.<br>
iii) Cumbersome application code
translates POJOs into Drools PackageDescr
(~5000 lines of code, not using fluent API).
This step produces a very strange
and convoluted representation of the LHS of
each RuleDescr. It works with DrlDumper
5.1.1 but does not work properly with the BRMS
5.2 version of DrlDumper (MVEL Template). This
is the source of our problem. <br>
iv) PackageDescr is dumped into a valid DRL
string with Drools DrlDumper<br>
v) Custom content manager does some versioning
and then stores DRL in an XML database</font></div>
<font color="#000000" face="Tahoma">
<div dir="ltr"><br>
<strong>2) Deployment and Runtime: </strong>App
is deployed daily and will have dozens of
runtimes during that 24 span. When deployed,
it pulls all rules from the database and
builds several KnowledgePackages, which are
cached, and then used throughout the day.</div>
<p> </p>
<p> </p>
<p><strong><font face="tahoma">Proposed
Solution:</font></strong></p>
<p><font face="tahoma">Because the app code that
performs step iii) is so convoluted and
will need to be modified in order to support
CEP, we want to pursue a more maintainable
solution to provide the translation
and abandon the mess that is already in the
application. We feel that rewriting this
code with the fluent API is just as
dangerous as the present code. Additionally,
the rules are far too variable to use Rule
templating.</font></p>
<p> </p>
<p><font face="tahoma">So, we propose to
translate the client's custom rule assets
and metadata into the Drools XML Language,
parse the XML and dump out DRLs. We will
likely need to use the
existing intermediate POJOs for this. The
most difficult piece in the puzzle by far is
translating the LHS of rules, and of course
this is the part that is broken currently in
our system. We believe that it should be
MUCH easier to translate the well
formatted MathML representation of the
LHS to the Drools XML schema using XSLT,
than to translate it to PackageDescrs with
Java code. There are also the additional
benefits of validation and portability
presented by XML. The downside here is that
the XML language and tools are out of date,
so we would need to develop these solutions
first. </font> </p>
<p> </p>
<p> </p>
<p>Both consultants on this project have been
interested in contributing to the Drools
project and we feel this could be the perfect
entry point. We realize this is a
complicated question and presenting it over
email is limiting, so please feel free to
contact me by phone.</p>
<p> </p>
<p> </p>
<p><font face="tahoma">Thank you,</font></p>
</font>
<p><font color="#000000" face="Tahoma">---<br>
Justin Holmes<br>
Red Hat Consulting<br>
<a moz-do-not-send="true"
href="tel:410.599.8432" value="+14105998432"
target="_blank">410.599.8432</a> : mobile<br>
<a moz-do-not-send="true"
href="http://www.redhat.com/consulting/"
target="_blank">http://www.redhat.com/consulting/</a></font></p>
<div> </div>
</div>
<br>
<fieldset></fieldset>
<br>
</div>
</div>
<pre>_______________________________________________
rules-dev mailing list
<a moz-do-not-send="true" href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a>
<a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
<br>
</div>
<br>
_______________________________________________<br>
rules-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/rules-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
Edson Tirelli<br>
JBoss Drools Core Development<br>
JBoss by Red Hat @ <a moz-do-not-send="true"
href="http://www.jboss.com">www.jboss.com</a><br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
rules-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
<br>
<br>
</body>
</html>