Re: [UCR] Design constraints: early example goal/csf hierarchy --> PR / PRR

Bijan Parsia wrote:

> 
> On Apr 23, 2006, at 2:25 PM, Vincent, Paul D wrote:
> 
>> Gerd - I don't think comparing the state of standardization in current 
>> PR systems with HTML is very useful.
> 
> I disagree.

I mostly agree with Paul (esp. given later clarifications), but I also 
think that HTML is an interesting reference for RIF (not particularly 
wrt production rules, though).

> And companies added tags left right and center from the start. It also 
> had a very liberal (vauge even) semantics. Browsers added tags to be 
> competitive and distinguish themselves.

Indeed. And most existing rule engines add features to the basics of the 
kind of technology they implement.

Browsers added tags after HTML was specified to compete and rule engines 
added features to their languages to compete before RIF was specified, 
but the analogy still works: (i) users who want to be vendor (in the 
broader sense of technology provider) neutral must be able to do what 
they need to do using only standard RIF; (ii) but vendors/usage 
communities/whoever must be able to add their own proprietary features 
(e.g. if vendors switch to RIF to persist rulesets in XML, they will 
have to define their own dialect on top of RIF to accomodate the legacy 
rulesets of their customers). But (iii) retrieving a non-standard RIF 
document must not cause a a consumer application to fail, not anymore 
than retrieving a standard RIF document containing features that it 
cannot process (which is bound to happen if RIF is rich enough to make 
(i) possible).

(i) means that RIF standard must cover enough features to be useful;
(ii) means that RIF must provide a standard way to extend it easily, and 
a way that do not prejudge of the kind of extensions;
(iii) means that RIF must provide either a standard behaviour for the 
case when a consumer finds, in a RIF document, a feature that its 
application cannot process, or a standard way to describe the expected 
behaviour, or both.

I proposed a requirement to that effect [1] (actually, (ii) extends that 
requirement). I also outlined a possible solution, but I made the 
mistake of sending out a whole, however sketchy, XML schema (attached to 
[2]: here below is the fragment of interested to that discussion.

[1] 
http://www.w3.org/2005/rules/wg/wiki/RIF_must_define_for_all_RIF_elements_a_default_behaviour_for_compliant_applications_that_do_not_know_how_to_process_it
[2] http://lists.w3.org/Archives/Public/public-rif-wg/2006Apr/0035.html

Christian

An simple solution would be for elements in a RIF document to have one 
or several attributes related to the expected behaviour in the case the 
consumer application does not know the said element, possibly with a 
default behaviour. E.g.

<xsd:element name="DontUnderstandBehaviour">
   <xsd:simpleType>
     <xsd:restriction base="xs:string">
       <xsd:enumeration value="IGNORE RULESET"/>
       <xsd:enumeration value="IGNORE RULE"/>
       <xsd:enumeration value="IGNORE ELEMENT"/>
       <xsd:enumeration value="whatever (e.g. replace with default 
value, etc)"/>
     </xsd:restriction>
   </xsd:simpleType>
</xsd:element>

The default "DontUnderstandBehaviour" associated to the "Function" 
element could be to ignore the rule, whereas the default behaviour 
associated to a certainty value or a priority could be to ignore the 
element only. There should probably be a way to over-rule the defautlt 
behaviour for an element or a group of element at the rule, ruleset and 
RIF document level, as well.

Received on Tuesday, 25 April 2006 14:11:28 UTC