Re: Another try at subclass

Michael Kifer wrote:

> These two proposals are orthogonal. The classification stuff is not the
> only impasse. My proposal solves 3 of them and opens a general way of
> getting rid of others, which we might encounter in the future.

Good point.

I have two concerns regarding your proposal:

First, as you know, I have some reservations wrt defining basic dialects 
as profiles of another dialect, rather than directly. That is because 
basic dialects, like Core and BLD, are meant to be extended, and 
extending a profile adds some difficulty because of the indirection.

So, here is a subtle modification of your proposal that does not require 
to decide between profile and extension at this stage (that's the 
proposal I wrote in IRC at the very end of Tuesday's meeting): we can 
keep the BLD document complete with all that is already specified, but 
use the conformance section to specify, not just one, but several 
dialects: Core, BLD, BLD++ (or whatever their names) etc. It would help, 
of course, to rearrange the current spec to make sure that all the 
features that we put in Core are defined first, then the additional 
features that we put in BLD, then the additional features that we put in 
BLD++, etc; but that is true also if we define Core and BLD as profiles 
of BLD++, anyway.

My second concern has more to do with the bundling of features in RIF 
dialects (and/or profiles): we have a requirement that RIF has only a 
limited number of dialect ("RIF must have a standard core and a limited 
number of standard dialects based upon that core"). Whatever limited 
means, the point is that we do not have only to decide whether each 
specific feature makes sense by itself to be included in a RIF dialect, 
but what bundle of features make sense as standard dialects/profiles.

So, suppose that we have a Core that is more or less Datalog, possibly 
with procedural attachments and, since they are only syntactic sugar, 
frames, the question is: what is the next bundle of features that make 
sense on top of that, for logic rule languages and from a rule 
interchange point of view (that is, in terms of coverage)? For instance, 
do we really need a standard logic dialect on top of Core that has no 
negation (remember that we are currently talking about adding two 
dialects on top of Core before adding one that would include negation)?

Cheers,

Christian

Received on Friday, 14 December 2007 14:05:33 UTC