> [ re: shipment rating, carriers, tariffs, etc ]
Gosh, you're in logistics too? May I ask for whom? I felt like I was
reading mail that I'd sent myself...
> > It started as an independant project, but now it's looking like
> > (hopefully) my Day Job will buy into it also.
>
> That sounds like very good news. Then you can work on it full time. If
> you accept my help I would probably be able to put in 20-25 hrs a week.
I'm definitely of the 'bazaar' and not the 'cathedral' mentality, when
it comes to projects I "run". Basically, anyone who shares The Vision
is welcome to directly commit to CVS, as far as I'm concerned.
> I realize that utilizing a pre-existing code base can get your to your
> goals in a shorter period of time if your goals match what the code base is
> trying to accomplish. What I mean by that is, is this. Generating rules as
> code is one way to approach a rule engine, but requires a coder to do the
> generation of the rules. Another method is by building a rule engine that
> is based upon a pseudo-human readable language, and imho a XML based rule
> definition file would be the way to go. Along the lines of RulesML (Rules
> mark up language). This would allow for a UI layer that could output the
> XML files so that a business analyst to generate the rules. This would
> allow the code to spend there time doing what they do best, coding, and the
> BA to what they do best, identifying and defining business rules with a tool
> that would map that knowledge to a rule language.
Here's my platform:
Compiled Rules --> Bad. Extensibility at runtime is *required*.
Psuedo-Human Language --> Good, but probably a phase II kind of thing
RulesML --> Downright evil, unless I don't personally have to ever look at it.
I think it's for machine production/consumption only.
XML --> Good for meta-data, bad for any sort of programming. See previous
threads on this list regarding example of bad XML.
> This goes back to what I discussed earlier on the approach. I see some
> difficulties in you take the approach that the JEOPS engine takes, producing
> java files and interpreting them, but this is still a surmountable problem.
> C# has many of the same abilities as Java with a CodeDOM package that is,
> from what all of my associates who work in Java tell me, quite a bit more
> robust in scenerios such as this. It has packages that allow you to
> dynamically emit IL code.
I may have mis-expressed myself. I think compile rules are The Wrong Way.
I'm not thinking of generating .java files, or even emitted byte-codes/IL
straight from a rule.
Java has the java.lang.reflect.* package, which allows *run-time* evaluation
of expressions, if you do enough magic.
Given an object, you can lookup its class, and methods within that class,
and then invoke the methods. Methods/Classes in Java are first-class objects,
and I plan to take advantage of that.
Currently, I'm looking at using BeanShell or DynamicJava libraries to
initially bridge into interpreted rules. Followed shortly there-after
with a custom parser to give us more information as to the expression
being used. Both BeanShell and DJava provide an eval(String statement)
method. But, optimally, I want access to the actual parse-tree of
that expression. That's phase II material also.
> > I have no clue about .Net really, but I have a feeling
> > that the changes in (b) would make life difficult.
>
> See b above. Also if you generalize the interpratation engine, you
> could make it so that you could plug in different interpreters.
Yah, but in the end, it has to all come down to a common semantic.
I need valuable bits of information from things like:
person.getName().equals( person.getParent().getName() )
or
Person's Name is the same as Person's Parent's Name.
I need to know that we're dealing with 2 Person objects, and
a few facts about them (their parents and their names).
If we treat the expression as a black-box to be evaluated by
pluggable interpreters, then I can't build an effective RETE
tree, and it becomes a linear check-all-predicates sub-optimal
engine.
*One* possibility would be have to our own expression tree
structures, and have each interpreter build the tree, regardless
of specification language.
That's something that's appealing to me. Have an intermediate
form for all expressions. Then, using an introspection engine,
wall that syntax tree to produce the results we need.
But regardless, it'll have to be drools itself that evaluates
the expressions, and caches results hither'n'tither, so as
to do a good rete.
_______________________________________________
drools-interest mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/drools-interest
