>Interestingly, once pre-compiled I have found Drools is actually faster than
pre-compiled Groovy in the few >examples I have tested. This kind of
suprised me - a lot actually. The pre-compilation of Drools is much >more
expensive than Groovy, but the execution is quicker.
On closer inspection
I did initially consider just inserting the DOM objects, but the java DOM api
is quite obstruse, and difficult to navigate with MVEL expressions. What I
have done is wrap the DOM api with some syntax sugar, that makes asserting
conditionals a lot neater.
My worry was that this would come at a per
I should have had it put up on the conference web site a long time ago.
Still needs final proofreading, and this list is not the place for it, but
you'll receive it via direct email.
-W
On 13/01/2013, Chris Selwyn wrote:
> Is this paper freely available?
> I would be interested in seeing a copy o
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".
>
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( thi
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
Frank,
there's absolutely no need for an apology. What I did present in my
paper *is* based on JAXB (or similar) unmarshalling into Pojos. Not
knowing OP's reasons for staying with XML elements I could only
recommend using a *similar* approach.
-W
On 11/01/2013, FrankVhh wrote:
> Sorry, I apol
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
On 11/01/2013, FrankVhh 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
hier
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 usi
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 converti
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 clas
12 matches
Mail list logo
