Re: RIF vs Rule Language

On 8 Dec 2005, at 12:21, Jeremy Carroll wrote:

>
>
> On the topic of the difference between a Rule Interchange Format  
> (RIF) and a Rule Language (RL), I consulted:
>
> Variability in Specifications
> http://www.w3.org/TR/spec-variability/
>
> It seems that clarity about what 'class of product' we are talking  
> about helps:
>   - in terms of a producer or a consumer of a rule interchange  
> format and/or a rule language behaviour is identical. A producer  
> produces syntactically legal rules, a consumer accepts them.
>  - in terms of a rule processor, we may distinguish between a RIF  
> and a RL in that a rule processor would have to act on a RL in a  
> completely specified way, whereas with a RIF, different rule  
> processors may do different things.
>

what do you mean with "different things"? I see (at least) 2 readings:

1) one rule engine might ignore certain aspects of an input, and  
another engine might ignore others -- so they do different things  
with the input. Clearly, it would be great if they would make  
explicit which bits of the input are treated, and which are ignored.

2) two rule engines might draw different consequences from the same  
input -- for which they both claim to be handling all aspects of the  
input...

I think that 1) is clearly ok for a RIF, whereas 2) will pose severe  
problems.


Cheers, Uli

> It may be possible to permit that variability while somehow having  
> a fixed semantics for the rules being interchanged (I'm not sure  
> how though).
>
> At this stage my expectation would be that in phase 1, there is no  
> difference: the core language being interchanged has a well-defined  
> semantics and rule processors have little or no flexibility in its  
> interpretation.
>
> In phase 2, however, we are expecting variability in the behaviour  
> of rule processors: and this variability is what makes it an  
> interchange format rather than a rule language. There are open  
> questions about how we achieve that through extensibility while  
> maintaining some sense of interoperability: one way might be that  
> different extensions enable different semantics.
>
> Jeremy
>
>
>

Received on Thursday, 8 December 2005 22:07:59 UTC