[rules-users] Solution for reasoning over XML?

[Wolfgang Laun]

It it's as simple as that you might just insert the org.w3c.dom.* objects
as you get them from the XML reader. I've never had to deal with XML
at this low level in Java, but here goes, off the cuff:

Element( name=="someName", value in ("someVal","someOtherVal"),
$parent1: parentNode )
Element( this == $parent1, name == "xpathlike", $parent2: parentNode )
Element( this == $parent2, name == "some" ) // assumes that name
"some" is unique at root

Now this doesn't appear to be an improvement, does it? What if you need to
access another child of /some/xpathlike - do you have to do this againg for,
say, name=="otherName"?

rule "/some/xpathlike"
when
  $doc: Document()
  $_some: Element( name=="some", parentNode == $doc ) // now asserted as root
  $_some_xpathlike: Element( name=="xpathlike", parentNode == $_some )
then
end

rule "/some/xpathlike/someName = someVal, someOtherValue"
extends  "/some/xpathlike"
when
  Element(name=="someName", parentNode==$_some_xpathlike, value in
("someVal","someOtherVal"))
then
  ...

-W


On 12 January 2013 06:10, craigparra <craigparra at gmail.com> wrote:
> 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-tp4021454p4021478.html
> Sent from the Drools: User forum mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users