Re: extensibility (Agenda for RIF telecon 26 June)

Sandro Hawke wrote:
>> 4 . Technical Design (70 mn)
>>    * Extensibility [3]
> 
>> [3] http://www.w3.org/2005/rules/wg/wiki/Arch/Extensibility2
> 
> Just to emphasize this point: I reworked this text earlier today, mostly
> just to make it clearer.  One technical change was to say that components
> (the smallest unit of extensibility) can include multiple syntactic
> elements, instead of being just a single syntactic element.
> 
> I'll probably spend some more time clarifying or updating the text
> Sunday night, if there are some comments.  Please do take the time
> (maybe 30 minutes?)  to read the text before the meeting.

I've been trying to get my head straight on this in preparation for the 
meeting.  I like the overall approach but it seems there are going to be 
extensions that can't be usefully handled this way. That makes it quite 
hard to decide how to fill in the blanks on things like the Fallback 
description.

One thing I would find valuable would be a set of test cases which 
illustrate some of the types of extension we would like the mechanism to 
cover. Then we could work through those to check out the details.

For example. Consider an LP extension that adds "conjunction in rule 
conclusions" intending that earlier LP translators use Lloyd-Topor to 
transform that away (by duplicating rules). I'll call this component CRC 
for short.

First, the Fallback in that case is a whole ruleset transformation not 
simply a replacement of a local syntactic element. So do we need an 
entire ruleset transformation language to describe Fallbacks? The 
earlier draft was perhaps going down that route with the 
MacroSubstitutions but other options would be an XSLT script or a 
RIFCore rule set acting over RIF-as-data. But that would be a lot of 
machinery to support and I'm not sure whether such syntactic 
transformations are going to give useful fallbacks in enough cases to be 
worth it.

Second, even if such a transformation fallback is useful it will only be 
applicable in certain dialects. Suppose some production rule dialect 
picks up CRC and incorporates it. In that case the fallback 
transformation would likely be invalid if the dialect includes negation 
and conflict set resolution. Though if there is no non-monotonic 
negation used in the rules then presumably it would be safe. Thus 
fallback safety depends on the presence of other components.

Third, it's not clear to me in what way CRC is a separable component in 
the first place. Certainly one could have a new conjunction operator 
intended for use only in rule conclusions but if we were putting that in 
the Core just now we'd just modify the Rule syntax and reuse the same 
Conjunction element as used in the condition language. Does this sort of 
extension (generalizing where certain constructs can be used) fall in 
the scope of the mechanism?

So test cases would, I think, be a helpful way to clarify the scope of 
what the mechanism should and should not cover.


A couple of more minor comments:

o I have been assuming that a RIF ruleset will include metadata which 
identifies the intended dialect (including version information). The 
discussion under "Dialect Identification and Overlap" doesn't seem to 
reflect that. The extension mechanism is only needed when a processor 
doesn't recognize the dialect/dialect-version in order to determine 
whether, despite that, it could still proceed.

o For well known (e.g. W3C published) dialects and components I think a 
processor should be free to use builtin knowledge of those and only use 
web derefencing for components unknown to it. So for me the current 
SHOULDs in "Locating Component Declarations" are being applied a little 
too broadly.

o I'm not sure about the need for a 3 level severity indicator but I 
guess I can see some value it and don't object to it.

Dave
-- 
Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Monday, 25 June 2007 11:18:17 UTC