This wiki has been archived and is now read-only.

PRD F2F Wednesday 11 February

From RIF
Jump to: navigation, search

PRD meeting 11 February 2009

Place: ILOG, Gentilly

Attendees: Changhai Ke (ILOG), Carole-Ann Matignon (FIC), Carlos Serrano-Morales (FIC), Paul Vincent (Tibco), csma (ILOG)

Discussion along the presentation of the PRD tutorial. Explanation of how's and why's, etc.

Issues raised, questions left open (the points are listed in the order the first occured in the discussion; there is no sense of priority in that list):

  • representation of Null/unknown/...
  • Table, indexable?
  • Need for an object-like construct, allowing tests on attributes values, chaining attributes, etc without requiring intermediate variables; naybe method (or is that phase 2?)
  • Access to data model (at least XML-S)
    • Would a list data type be enough for phase 1?
  • Need for a Rule construct
    • to attach priorities and other rule-level, behaviour-controlling annotations (e.g. active date etc));
    • bad design that the Group construct bears information that is ruleset-levl (e.g. the conflict resolution strategy) as well as infomation that is rule-level (e.g. priority);
    • could be a split of Group; could use the Implyes for the purpose (that would require that an unconditional Do is not a RULE anymore);
  • Global (shared) patterns?
  • Ordering rules in a ruleset (other than by priority)?
    • <Group rif:order="yes">?
  • PROPOSED: remove the subclass atom from PRD (as it was removed from Core)
    • No use case for it in rule conditions, and it is not assertable anyway
  • The open tie-breaker in the default conflict resolution strategy will really control the execution in many cases: shall we add one (or a choice of) more discriminating selection rule to the current ones (to wit: refraction+priority+recency)?
    • ordering of the rules in the ruleset could be a candidate (because it makes intuitive sense for the rules author)
  • Fair Isaac prefers a more compact (XML) syntax, higher level, less logic-looking syntax
    • usability in a business rule context much higher priority than over Core compatibility