On 11/01/2012 07:10, Justin Holmes wrote: > Mark and Edson, > > Thank you both for prompt responses. I certainly understand your position on > the Drools XML language, and I also agree that using an open standard would > have its benefits going forward. Now that we know DrlDumper is only intended > to be a debugging tool, and that it does not work in future versions, we will > need to rethink our solutions. Edson, I'll email your redhat.com account and > hopefully we can chat sometime on Wednesday. > > Additionally, I have a request regarding documentation. Send in a github pull request for your doc updates, and we'll apply straight away. > If it has been decided that Drools XML is dead and that no one should be > allowed to revive it, It's not a case of "shouldn't". What we don't want is some partial attempt that ends up cuasing a lot of work for the core developers. If someone comes along with a strong plan and commits to it and delivers, then of course we'll consider it. > Red Hat documentation must reflect that decision. Currently, the Drools > 5.4.Beta Expert User Manual (section 5.11) and the BRMS 5.2 reference guide > (section 4.11) say, "All the features are available with XML that are > available to DRL." Both docs also prescribe the use of XmlDumper, DrlDumper, > DrlParser, and XmlPackageReader for round-trip translations between XML and > DRL. It is clear from post on the user-list that others have been mislead by > the docs as well, so we should see to it that they are fixed. If there is a > better avenue to request that all 5.x docs be updated, please let me know. > > Once again, thanks for your help. I'm sure we will be in touch in the coming > days. > > Regards, > --- > Justin Holmes > Red Hat Consulting > 410.599.8432 : mobile > http://www.redhat.com/consulting/ > ________________________________________ > From: rules-dev-boun...@lists.jboss.org [rules-dev-boun...@lists.jboss.org] > On Behalf Of Edson Tirelli [ed.tire...@gmail.com] > Sent: Tuesday, January 10, 2012 7:30 PM > To: Rules Dev List > Subject: Re: [rules-dev] Drools XML Language and Tools Development > > 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
