Re: extensibility (Agenda for RIF telecon 26 June)

Dave Reynolds <der@hplb.hpl.hp.com> writes:
> Sandro Hawke wrote:
> >> 4 . Technical Design (70 mn)
> >>    * Extensibility [3]
> > 
> >> [3] http://www.w3.org/2005/rules/wg/wiki/Arch/Extensibility2


> I've been trying to get my head straight on this in preparation for the 
> meeting.  

Thank you.  :-)

> 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.

Absolutely.  We should do some brainstorming on the extensions people
will some day want.   Is there a list I've missed somewhere, perhaps
from the earlier requirements gathering?

> 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.

Right.  I see three basic levels of fallback functionality we could do:

   0 -- the fallback procedure is that you just omit the unrecognized
        element, pruning the parse tree as high as you need to, to get
        something syntactically valid.  In many cases, that means the
        rule which uses the thing will be omitted.  In other cases,
        though, like when it's an argument to a function, you'd get even
        more screwy results.

   1 -- the fallback procedure is a single pattern match replacement,
        with wildcards but no variables.

   2 -- the fallback procedure is a RIF Core rule set, acting over RIF
        as data, as you say.

I was aiming for level 1 at this point, but level 2 has the huge
advantage of supporting syntactic sugar extensions, as you say. 

In a perfect world, we'd have implementations of each of them to try
out.  If level 2 turns out to easy enough to implement, then it's
probably the way to go.  (It's conceivable I'll have time to try to
implement this over the next two months, but I can't commit to it right
now.)

> 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.

My thinking was that a given component could have multiple fallbacks,
each with different impact.  So, typically, I'd expect a minor-impact
fallback to a nearby dialect to be defined, along with a major-impact
fallback to Core.

> 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?

The approach that comes to my mind is to have a different kind of rule.
Core has HornRule, and you're talking about a CRCRule, I think.

> 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.

I understand.  My suspicion is that identifying components instead of
dialects will end up being much more comfortable in the long run.  In
the most obvious case, you might implement D1 (C1,C2,C3) and recieve a
document which uses only C1 and C2, but which would be labeled as being
written in D2 (C1,C2,C3,C4).  The sender might not even know that D1
exists, and so could not label it D1.   (But maybe the D2 author needs
to know about D1 to ensure compatibility; maybe the content could be
labeled as {D1, D2}.)

> 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.

I agree.  My intent was that the developer could do the dereferencing
and hardcode the results into the system -- and that would be a
conformant implementation.   But I didn't say that; I'll try to figure
out a rephrasing.

> 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.

Yeah -- I found I needed it in some mental exercises I was doing, but
when we have some example cases, we can look at it together.

    -- Sandro

Received on Monday, 25 June 2007 21:49:24 UTC