Hi, I was looking around trying to find a solution for reasoning over any XML in drools, without having to convert the XML into java objects, but couldn't find any example where this had been done. I have opted to DOM parse the XML, then recursively wrap every Element node in a convenience class (XmlElement) and insert as facts. That is every element is inserted individually as a fact. My conditionals look like: $xml : XmlElement(name == 'someName', value == 'someValue') $xml : XmlElement(path== '/some/xpathlike/path', value == 'someValue') $xml : XmlElement(attribute['someAttr'] == 'someValue') or using a DSL: An XML element exists - named someName with a value of - at path /some/xpathlike/path with a value in "someVal","someOtherVal" Is this a pattern that other drools users have encountered? Or tried to solve. It seems to work quite well, at least in my scenario - but clearly it has limitations based on the DOM parse (ie not great for massive XML files). Was wondering if anyone else had tried to solve how to use XML as facts? -- View this message in context: http://drools.46999.n3.nabble.com/Solution-for-reasoning-over-XML-tp40214... Sent from the Drools: User forum mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

Is this paper freely available? I would be interested in seeing a copy of it since I have recently been using with Drools to detect all sorts of data conditions in XML documents. Chris On 11/01/2013 07:03, Wolfgang Laun wrote: > There was my talk at IntelliFest 2012: "Reasoning with XML Data". > Although it assumes that XML elements are unmarshalled into regular > Pojos, it may still contain some useful ideas and code snippets. > > I'll send you the paper off-list, and I'd be interested to learn about > your reason for not converting to Pojos (using JAXB or similar). > > Best > Wolfgang > > > On 11/01/2013, craigparra <craigparra(a)gmail.com&gt; wrote: >> Hi, >> >> I was looking around trying to find a solution for reasoning over any >> XML >> in >> drools, without having to convert the XML into java objects, but >> couldn't >> find any example where this had been done. >> >> I have opted to DOM parse the XML, then recursively wrap every Element >> node >> in a convenience class (XmlElement) and insert as facts. That is every >> element is inserted individually as a fact. >> >> My conditionals look like: >> >> $xml : XmlElement(name == 'someName', value == 'someValue') >> $xml : XmlElement(path== '/some/xpathlike/path', value == 'someValue') >> $xml : XmlElement(attribute['someAttr'] == 'someValue') >> >> or using a DSL: >> >> An XML element exists >> - named someName with a value of >> - at path /some/xpathlike/path with a value in "someVal","someOtherVal" >> >> Is this a pattern that other drools users have encountered? Or tried to >> solve. >> >> It seems to work quite well, at least in my scenario - but clearly it >> has >> limitations based on the DOM parse (ie not great for massive XML files). >> >> Was wondering if anyone else had tried to solve how to use XML as facts? >> >> >> >> -- >> View this message in context: >> http://drools.46999.n3.nabble.com/Solution-for-reasoning-over-XML-tp40214... >> Sent from the Drools: User forum mailing list archive at Nabble.com. >> _______________________________________________ >> rules-users mailing list >> rules-users(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

With Wolfgang's approach, your patterns looking like: XmlElement(name="SomeClass",value="foo",attribute["myAttr"] == bar) Would turn into: SomeClass(value == "foo", myAttr == "bar")

Without having any numbers, we can still safely say that the performance improvement that you should get from using the pojo's, especially with "big" files, should be somewhere in between "quite considerable" and "huge".

Out of curiosity: A) Do you also call Modify or Update in your THEN clause? B) What does this DSL phrase resolve to? An XML element exists - named someName with a value of - at path /some/xpathlike/path with a value in "someVal","someOtherVal" Regards, Frank -- View this message in context: http://drools.46999.n3.nabble.com/Solution-for-reasoning-over-XML-tp40214... Sent from the Drools: User forum mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

Sorry, I apologize. It was wrong for me to say "With Wolfgangs approach", as I do not know it well enough at all. I was referring to an approach were you would use JAXB to create pojo objects form the xml and reason on them. My brain must have fooled me in equalizing it with your approach. Sorry to deceive you all. Regards, Frank laune wrote > On 11/01/2013, FrankVhh &lt; > frank.vanhoenshoven@ > &gt; wrote: >> With Wolfgang's approach, your patterns looking like: >> >> XmlElement(name="SomeClass",value="foo",attribute["myAttr"] == bar) >> >> Would turn into: >> >> SomeClass(value == "foo", myAttr == "bar") > > Not quite. A DOM tree would be represented by a very small object > hierarchy according to the XML node typology: > node-element-attribute-text, etc. What I proposed in my IntelliFest > 2012 paper is the addition of facts representing the DOM *structure* > to Pojos unmarshalled from the DOM tree. > >> >> Without having any numbers, we can still safely say that the performance >> improvement that you should get from using the pojo's, especially with >> "big" >> files, should be somewhere in between "quite considerable" and "huge". > > It may reduce the number of facts by an order of magnitude, depends on > the XML tree's fan out, with consequences for insert, etc. There may > also be a penalty due to remaining at the level of "all is String" > (depends on the data). > > -W > >> >> Out of curiosity: >> A) Do you also call Modify or Update in your THEN clause? >> B) What does this DSL phrase resolve to? >> >> An XML element exists >> - named someName with a value of >> - at path /some/xpathlike/path with a value in "someVal","someOtherVal" >> >> Regards, >> Frank >> >> >> >> >> >> -- >> View this message in context: >> http://drools.46999.n3.nabble.com/Solution-for-reasoning-over-XML-tp40214... >> Sent from the Drools: User forum mailing list archive at Nabble.com. >> _______________________________________________ >> rules-users mailing list >> > rules-users@.jboss >> https://lists.jboss.org/mailman/listinfo/rules-users >> > _______________________________________________ > rules-users mailing list > rules-users@.jboss > https://lists.jboss.org/mailman/listinfo/rules-users -- View this message in context: http://drools.46999.n3.nabble.com/Solution-for-reasoning-over-XML-tp40214... Sent from the Drools: User forum mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

Thanks guys, In my case, we currently assert a known java object and a small set of structured data (represented in XML) with it. The structured data (XML) isn't known at design-time, because it is user-configurable (the data sources for document templates). This excludes using jaxb or similar to create java model objects, as the incoming schemas aren't known. But we would like the rule logic to be user configurable, using a natural language DSL (hence drools). We currently write and execute the logic in groovy scripts, which are not very business friendly, are expensive for the team to maintain, and will not scale out as our number of customers increases. Drools is a nice fit for that, but the question of how to efficiently reason over XML is a sticking point. Groovy has excellent XML support but drools is a lacking. As with Wolfgang's suggestion, I assert a wrapper object for each DOM Element node; in our case, these number in the 10's per firing, so it's not a massive amount of data. From those elements I can reason over the DOM tree using convenience methods. It's probably expensive if conditionals require traversal of the DOM tree (such as calculating the full path from the root). An alternative approach is to SAX parse the XML and build immutable objects that are not backed by the DOM model. This would process all possible convenience values up front, even though they may not be used in conditions. In our case, the structured data is read-only, so there is no need to call modify or update (though this is technically possible I guess). I haven't implemented it. In my example > An XML element exists > - named someName with a value of > - at path /some/xpathlike/someName with a value in > "someVal","someOtherVal" Resolves to: XmlElement ( name=="someName", path =="/some/xpathlike/someName" value in ("someVal","someOtherVal")) So far the groovy executes about five times as fast as drools, but I think that might be because I'm re-compiling the knowledge every time. Not sure. -- View this message in context: http://drools.46999.n3.nabble.com/Solution-for-reasoning-over-XML-tp40214... Sent from the Drools: User forum mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

Interestingly, once pre-compiled I have found Drools is actually faster than