I've been getting requests for a testing tool that checks for recursion,
and exits the test if its detected. Any takers fancy having a go at
this? Mostly its just an event model thing, bit like the audit view. But
as recursion is not just about rule recursion, but Activation recursion
too (i.e. rule recursion with the same data), you'll need to create a
stack of rules and tuples, and check against that stack for possible
recursions. Should be fun :)
I'm thinking about an ontology constraint system, based around field
setter validation. However I cannot decide how to handle invalid changes
in a consequence or in external java code. I'll may leverage the JSR 303
- Bean Validation - http://jcp.org/en/jsr/detail?id=303.
Although I have several concerns with the spec, one is that it always
validates objects and passes in the field as an object - with primitive
intensive stuff that can add an overhead, due to auto boxing. I'm more
tempted to pass in the main Object itself and users can then use the
FieldExtractor to read the field as they require, either as an Object or
a primitive with full co-ercion - the FieldExtractor would be injected.
Further to that I can't see how you would make the validator session
aware, and doing it via constructor injection would mean a validator per
session which is not desirable. I spoke to the spec lead and he
mentioned using LocalThread variables. However we can have multiple
sessions in the same thread, just not executing at the same time, which
means the current executing session would need to set itself on that
localthread variable - basically context switching, which I don't like.
We should have a variable that lists the validator errors for the
current working memory action phase, for user interrogation - much like
Hibernate Validator (RI for JSR 303) allows you to list validation
errors on a insert or update on a session.
But in rule engines we have other considerations:
The first fundamental question is do we allow invalid changes or do we
always roll them back? My prefernce, much like a database, is the data
model as seen by the engine is always valid.
Now if we assume the invalid change must be rolled bank or not applied
how do we expose this to the user:
-Throw an exception, up to them if they catch and it will exit the
engine if not caught.
-Do nothing, roll back the change and continue executing the consequence
as normal, they can check the validator variable if they need to.
Allow for "catch" like blocks either after each modify block, or after
the "then" block. Do we have one large catch block, or do we have some
sort of type matching....
Currently my preference is for a "catch" block after the "then" block.
I'm tempted to just have one large catch block and users can do an
iteration of the validator variable doing "if" checks; we can always add
in type matching later. The catch block can either resume or throw an
exception; on resumption it will attempt to validate the bean again, if
it's changed, if it's still invalid the process repeats.
Peter Jackson supports the wiki concept. Knowledge base has 'both rules and various declarations'.
Lets keep it 'rule base'.
----- Original Message ----
From: Massi Gmail <mmquelo(a)gmail.com>
Sent: Thursday, January 3, 2008 5:49:23 AM
Subject: Re: [rules-dev] KnowledgeBase
Reading the wikipedia doc, It seems that a
knowledgebase does not only contain data in a "Rule Format" but
even other kind of information. For instance
information like the "object model".
As far as I understood the rulebase does not
contain anything related to the object\fact model.
So I would say that the rulebase is "part of" the
knowledge base and not the "knowledgebase" itself.
It's just an idea....
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Reading the wikipedia doc, It seems that a knowledgebase does not only contain data in a "Rule Format" but
even other kind of information. For instance information like the "object model".
As far as I understood the rulebase does not contain anything related to the object\fact model.
So I would say that the rulebase is "part of" the knowledge base and not the "knowledgebase" itself.
It's just an idea....