PRD (Prod Rule Dialect) breakout scribe notes from F2F8 6 Nov 07

PRD BREAKOUT F2F8 Boston - 6Nov07

=================================

 

CSMA: Do we want PRD as simple as possible but missing major features
like negation?

 

Gary: Most rules' NOT are simple terms and constants rather than frames.

 

CSMA: Another type of common negation is NOT(pattern). 

 

CSMA: Should design for negation. 

 

Gary: No model theory for PR. 

 

CSMA: Model theory for the operational semantics may be possible. 

 

Adrian: Select language based on conditions in BLD.

 

CSMA: PRD needs to re-use as much of BLD as possible.

 

Gary: PRD should reference BLD doc. Rather than repeat it. 1st draft can
concentrate on actions rather than extending conditions.

 

Gary: EG PRD Core with BLD Condition Language + Actions.

 

CSMA: Concern: better not to repeat text, but people won't read 2 docs
instead of 1. Could do a doc refactoring exercise so BLD and PRD can
share elements.

 

Gary: BLD doc is not easy to understand. Its a theoretician point of
view rather than end-user or implementor. So comments applies to BLD
too.

 

Bob: Model-theory semantics will always be a challenge to read.

 

CSMA: ACTION: to discuss BLD restructure to allow easier re-use /
sharing by PRD etc with RIF WG

 

 

 

 

CSMA: Human readable syntax / presentation syntax: not restructured in
draft as this is not useful

 

Gary: Presentation syntax = very useful. EG test cases as examples for
implementors.

 

Bob: Fundamental is the XML syntax. Reading XML docs is not best for
examples. Can manage with informal presentation language with no formal
/ explained syntax, 

provided we include the XML doc

 

Gary: But we already have the presentation syntax in BLD so this is
done. No motivation to drop it. 

 

CSMA: Do not like a Working Draft defined by reference. 

 

Gary: Do not like not repeat-by-copy vs repeat-by-reference.

 

 

 

 

Gary: Can we repeat semantics in operational terms, or do a hybrid
approach (model-theory conditions, operational rules and actions)?

 

CSMA: Need operational semantics for conditions as conditions are
executed per the instantiated rules. 

Instantiating rules is an operational semantics in terms of patter
matching.

 

CSMA: Should limit amount of work moving conditions to PRD. But work is
already done (conditions in operational semantics).

 

Gary: Issue of differences in behavior: JESS re-fires a rule if a fact
in condition changes

 

Bob: In FIC the change must be in the state of the condition, not the
state of the fact / data.

 

CSMA: If JESS does not conform, then the doc needs to change. 

 

CSMA: How should PRD handle such "tricks".

 

Bob: Real business rule systems rarely have ambiguity or chaining. 

 

Gary: Still find need for conflict resolution.

 

CSMA: Problems like configuration still require solutions like inference
and chaining.

 

CSMA: In ILOG the resolution strategy is overridable to some extent. So
if the interpretation of RIF strategy is an engine command this makes
RIF default easier.

 

Gary: JESS / CLIPS: multiple rulesets / stack. Only rulesets in top of
stack can fire. Actions can load the stack. Within a ruleset can have
priorities. 

Can select first or last recent rule in same priority.

 

CSMA: ACTION: All vendors to provide their rule selection strategy and
options, in a table set up by Christian on the Wiki.

 

 

 

 

 

 

 

 

Paul Vincent

TIBCO | ETG/Business Rules 

 

Received on Tuesday, 6 November 2007 18:40:49 UTC