W3C home > Mailing lists > Public > public-rif-wg@w3.org > July 2008

Re: RIF Core, and how much is PRD allowed to diverge from BLD [Was: Re: [PRD] Issues to resolve before publication]

From: Mark Proctor <mproctor@redhat.com>
Date: Tue, 01 Jul 2008 13:30:58 +0100
Message-ID: <486A2382.6060104@redhat.com>
To: Gary Hallmark <gary.hallmark@oracle.com>
CC: Christian de Sainte Marie <csma@ilog.fr>, RIF WG <public-rif-wg@w3.org>

Gary Hallmark wrote:
>
> To maximize rule interchange between production rule engines and logic 
> rule engines, clearly Core should be "as big as possible".  We can, 
> should, and must decide that now.  I don't even know why I have to 
> keep arguing this point.  The bias to keep BLD and PRD aligned with a 
> large common core should be so high that the burden of proof is on you 
> to show why NAU  should not be in Core.  You have provided no such proof.
>
> I am much more interested in making PRD useful for exchange with a 
> variety of rule engines than I am in tailoring PRD to any one or two 
> vendors products.
Are you talking about interchange of PR systems, or general rule(prolog) 
systems? I have interest in the former, I don't think anyone in the PR 
industry has interest in the later and I don't think most users are 
interested in the later either. Interchange between prolog and PR is a 
waste of time, no one is asking for this.
>
> Christian de Sainte Marie wrote:
>>
>> Gary Hallmark wrote:
>>>>
>>>> #4. Sections 2.1.1.3 (External) and 2.1.2.1 (Atom): Named Arguments
>>>> Uniterm (NAU). [...]
>>>
>>> We should be consistent with BLD on this point.  Simply support 
>>> them, and no editor's note!
>>> I think having a case-by-case ad hoc voting strategy for a spec is 
>>> not a good idea.  I think we need to
>>> establish an architectural principle that PRD should not deviate 
>>> from BLD without very strong technical arguments.
>>> What would those arguments be in this case?
>>
>> I do not think that can work: even if we agreed on what are the 
>> acceptable arguments (or on the definition of a technical argument: 
>> are arguments of the type "this is what mainstream production rule 
>> languages do" technical?), that principle should have been set and 
>> agreed upon before we made decisions on BLD.
>>
>> My point is that we cannot decide post facto that decisions that were 
>> made for BLD are basically binding for other dialects as well: some 
>> decisions might (and would probably) have been different if the 
>> understanding had been that they would apply to other dialects as well.
>>
>> The decision wrt NAU was very clearly one of those, at least as I 
>> understood it at the time.
>>
>> Ad the question of how much PRD and BLD are allowed to diverge, in 
>> general: my understanding is that the very reason why we have a 
>> common core and two different dialects, BLD and PRD, is exactly to 
>> allow BLD and PRD to diverge as much as needed to make them useful 
>> dialects.
>>
>> We separated BLD from Core last year for exactly that reason: to 
>> allow us to make, for BLD, decisions that were not binding to other 
>> dialects (and foremost to PRD), as any decisions re Core would have 
>> been; and, thus, to allow us to progress on the basic logical dialect 
>> without having to care about production rules.
>>
>> This is why that new notion that PRD must not stray away from BLD 
>> seems kind of counter-productive, to me.
>>
>> When a feature from BLD is discussed for PRD, the question to answer 
>> should be: is this feature in Core? If it is, then it goes in PRD; if 
>> it is not, PRD is free to decide to have it or not, independently of 
>> BLD.
>>
>> Cheers,
>>
>> Christian
>>
>>
>


-- 
JBoss, a Division of Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, 
SI4 1TE, United Kingdom. 
Registered in UK and Wales under Company Registration No. 3798903 
Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland)
Received on Tuesday, 1 July 2008 12:33:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:50 GMT