yeah that makes sense - but I think you may be underestimating the work on
the tooling side.
working off XML is easier for tools - as extra meta data is needed for the
GUI that would not be there in the DRL (so working directly off a DRL would
be like swing GUIs on java - they need lots of comments/meta data added) -
so working of an official/canonical XML format (if based on RuleML) would be
ideal.
However, I don't think a timeline to this would mesh up with what was being
proposed !
On Wed, Aug 11, 2010 at 11:54 PM, Mark Proctor <mproctor(a)codehaus.org>wrote:
In reality I'd like to see the BRL killed. We already have two
poorly
maintained xml formats, neither keep up to date with DRL.
BRL was initially designed as a simple xml, as we believed tooling wouldn't
want full DRL. As it turns out most people do actually just want a GUI
builder that supports full DRL.
As a result I'd like to see an investment in a new XML format that future
proofs, for our designs for drools 6:
http://community.jboss.org/wiki/DroolsLanguageEnhancements
I've been reluctant to start my own XML here, as i'd like to see us work
with the RuleML group in adopting their xml (probably with feedback on
needed changes) as our defualt XML for Drools. Although for the immediate
need for improving the guided editor we have no choice but to continue to
extend BRL, but those doing so should probably have it in mind that it's a
temporary solution.
Mark
On 11/08/2010 03:34, Amit Kumar wrote:
Hello folks,
Sorry for barging in by subscribing to this developers alias
We are a Intellectual capital Management team in Cisco Systems. We have
been using our own engines to do specific jobs for past 10 years, as part of
future growth we have decided to do away with our own custom engines and use
the drools engine to do Inference & event management rules. Good choice ..
:)
We have evaluated the capabilities of rule authoring UIs in drools and have
faced some resistance from our Subject Matter Experts to build our own UIs
.. basically some templates which they can fill out instead of understanding
the complexities of Guvnor. Also we felt that some layer of abstraction
could be provided above guvnor UI since it does not yet provide support for
IC (Fusion based)
Approach:
We are trying to put in some extensions to BRL to support the fusion
usecases and any other which we need. The reason we are doing it to BRL is
the same as yours .. that UI editors work with XML kind of structure instead
of a DRL file.
So eventually we would also enhance the BRL->DRL converters and provide
support in BRL to ObjectContainment (Facts containing collection of facts)
and provide testing capabilities for inference and event IC.
Concern:
If we make any enhancements to BRL then we would want to integrate back to
community code so we can utilize any extensions to the BRL, DRL and
converters which are done by community and do not paint ourselves in a
corner.
We can share our work to provide ideas back to community and may be we can
provide some other enhancements for the community.
Can you kindly guide us on how to make these enhancements and how do we
contribute to the code. and any standards and guidelines pages.
Regards,
Amit
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev