W3C home > Mailing lists > Public > public-rif-wg@w3.org > August 2008

ISSUE-75 (Disjunction in Core): Should Core allow disjunction in rule bodies [Core]

From: Rule Interchange Format Working Group Issue Tracker <sysbot+tracker@w3.org>
Date: Wed, 27 Aug 2008 11:29:58 +0000 (GMT)
To: public-rif-wg@w3.org
Message-Id: <20080827112959.03E216B62A@kent.w3.org>


ISSUE-75 (Disjunction in Core): Should Core allow disjunction in rule bodies [Core]

http://www.w3.org/2005/rules/wg/track/issues/75

Raised by: Dave Reynolds
On product: Core

We are currently proposing that Core be a proper subset of the intersection of BLD and PRD; omitting features which are not commonly supported or which complicate the implementation or description unnecessarily.

At recent telecon discussions (e.g. 19Aug08) disjunction was listed as one of the features to omit on the grounds that it complicates implementation and that (at least in a BLD setting) a rule with disjunctions can be replaced with multiple rules via Lloyd-Topor. 

However, in a production rule setting it is common to have rules which test whether a variable is bound to one of a number of alternative (typically ground) values and that disjunction is a natural way to represent this. In the absence of disjunction or some alternate-match notation or builtin then a rule of this sort can require very large numbers of transformed rules to implement without disjunction (Gary suggested conceivable instances where 10,000 rules would be required instead of one).

Options include:

(1) Do not include disjunction in Core. RIF Producers which support disjunction in the rule bodies would need to translate rules with disjunction to multiple rules. Possible cost that some rulesets could not be effectively exchanged via Core due to blow in the translated ruleset size.

(2) Do not include disjunction in Core but include some alternative restricted mechanism such as a "oneOf" builtin (c.f. SQL's "x IN(a,b,c)" syntax) to mitigate the troublesome cases. Possible cost is that such a limited mechanism may not be adequate to handle enough of the troublesome cases and complicates implementation of Producers.

(3) Include disjunction in Core. RIF Consumers whose languages do not support disjunction would have to perform an L-T transformation first, possibly resulting in blow up and adding to the complexity of implementing Consumers.

(4) Include disjunction in Core but apply some syntactic limitation to simplify its effective implementation via translation to special case tricks like oneOf.
Received on Wednesday, 27 August 2008 11:30:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:53 GMT