A RuleML and/or RIF parser to Drools would certainly be welcome :)
Mark
On 11/01/2012 00:30, Edson Tirelli wrote:
Just to add to Mark's comments, there are options for you to move
forward.
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.
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.
Regards,
Edson
On Tue, Jan 10, 2012 at 6:39 PM, Mark Proctor <mproc...@codehaus.org
<mailto:mproc...@codehaus.org>> wrote:
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.
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.
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.
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.
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.
Mark
On 10/01/2012 22:08, Justin Holmes wrote:
Hello Devs,
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:
1) Is the XML language truly the best option for our use case?
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?
*Context: *
Client is using Drool 5.1.1 and we are migrating to BRMS 5.2.
There are two independent workflows of interest:
*1) Rule Authoring and DRL generation*: 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:
i) GUI saves LHS rule logic in an XML database using MathML
(http://www.w3.org/Math/), and then saves everything else in a
relational database.
ii) iBATIS pulls down the corresponding database and XML entries
and populates POJOs. There is 1 class definition per content type.
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.
iv) PackageDescr is dumped into a valid DRL string with Drools
DrlDumper
v) Custom content manager does some versioning and then
stores DRL in an XML database
*2) Deployment and Runtime: *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.
*Proposed Solution:*
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.
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.
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.
Thank you,
---
Justin Holmes
Red Hat Consulting
410.599.8432 <tel:410.599.8432> : mobile
http://www.redhat.com/consulting/
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
