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 <[email protected]>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 > [email protected]https://lists.jboss.org/mailman/listinfo/rules-dev > > > > _______________________________________________ > rules-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-dev > > -- Michael D Neale home: www.michaelneale.net blog: michaelneale.blogspot.com
_______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
