Paul Vincent wrote:
>
> 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
>
Jess has two modes. standard and slot-specific. Standard will allow
propagations of a fact, as long as that pattern is true, regardless of
whether that pattern filters against changed fields. Slot-specific means
that for the fact to propagate not only must all the conditions be true,
but that it must also have a constraint for a changed field.
Clips works like Jess standard mode for templates and Jess slot-specific
for its COOL OO extensions.
>
>
>
> 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".
>
I see use cases for both modes, sometimes you want to know of changes
regardless of the constraints, and other times only if the constraints
are for a changed field.
>
>
>
> 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.
>
Jess, Clips and Drools all default to a "depth" strategy and behaviour
is the same (although all also allow custom strategies to be provided),
this is a very simple form of resolution strategy with a preference to
Jess/Clips "modules" or Drools"agenda-groups" for rule execution
orchestration; ilog has something similar called "packets". Basically
these place the rules in a group and only when that group has the focus
can those rules fire - the mentioned terms use a push/pop stack to
manage which group has the focus. In reality no reason why these groups
should be on a push/pop stack, when their linear relationships can be
described via process defintion - i.e. Drools ruleflow - however I
expect this is beyond scope for now, but something to bear in mind.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Paul Vincent
>
> TIBCO | ETG/Business Rules
>
>
>
--
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire,
SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)