Re: [PRD] Issues to resolve before publication (et proposed resolutions)

Christian de Sainte Marie wrote:
>
> Gary Hallmark wrote:
>>>
>>> #8. Section 2.3.1.2 (Forall): Gary does not want the CMP example to 
>>> be presented with binding patterns. On the other hand, they are 
>>> included in this version of RIF-PRD because all the mainstream PR 
>>> languages use them, and there is an editr's note asking for feedback 
>>> about them and the nested forall: so, providing an example makes sense.
>>
>> I want binding patterns to go away.  They are trivially converted to 
>> the BLD format and though they may have their place in legacy PR 
>> languages, they have no place in RIF.  I don't want any new material 
>> added to the spec that mentions these.  I want them all gone 
>> eventually, even if I can't have that for FPWD.
>
> Weird... As I understand it, it is exactly because they have their 
> place in existing PR languages (actually, they are widely used),  that 
> they have their place in RIF.
I'm still trying to understand this argument, and think maybe each side 
might be confused. Are we agueing absolutes, binding is the only way and 
no binding is  the only way? As a PR system needs to work with both, 
binding is optional. As my previous email said, we definitely need to be 
able to define patterns without pattern or field bindings, but the 
optional use of these is definitely needed. The use of field patterns is 
debatable, you could argue that they where needed as early systems had 
poor syntax for specifying fields on a pattern, so I wouldn't argument 
if field bindings where lost - we support finding bindings and direct 
accessors, so users can work the way they feel best.
traditional way:
Person( $fieldBinding : name )
Item( owner == $fieldBinding )

But can actually just do
$patternBinding : Person()
Item( owner == $patternBinding.name )

The later would require some processing to map down to Clips, but still 
doeable. The above two shows examples of a pattern with no bindings at 
all, "Item", and both field and pattern bindings on "Person".
>
> I do not quite understand what is RIF, if it is not an interchange 
> format that is usable and useful for what you call "legacy" production 
> rule languages; that is, if it does not cover the syntactic features 
> that are widely used. RIF would have to cover such features even if we 
> all agreed that they are ugly and that they should not be used; which 
> is not the case, of course :-)
>
> Why "legacy", btw? I can imagine plenty of interesting feature in 
> future PR languages that would require binding patterns...
I don't konw what legacy is referring too, can we clarify. Clips is 20 
years old and thus the king of legacy and still the gold standard we 
should be working on. Actually what is needed is for someone to list the 
PR features and what is/isn't support by vendor engines, so we can 
clarify who we are targetting. This might solve this argument. I've done 
an initial spreadsheet to start this off, for Clips, Jess, Drools, 
JRules and OPSJ. I've not included backward chaining Jess and OPSJ are 
the only ones to support this and both do it differently. If I get more 
time i'll do some clarify notes on what all those things mean. I expect 
I've missed several things out and I ofcourse apologise if I've got some 
things wrong.
>
> Or are you suggesting that RIF should be designed as a "better" PR 
> language (rather than as a common xml serialisation for many, existing 
> and futrue, production rule languages)?
>
> Designing a better production rule language is certainly a worthy 
> endeavour. But it is not the objective for PRD, not the first attempt 
> to a standard common xml serialisation for production rule languages.
>
>>> I propose that we include a small example with patterns, and that 
>>> the XML rendering of the complete CMP rule be moved to an appendix, 
>>> where it can be serialized without patterns nor nested Forall, as 
>>> Gary prefers, with a comment to the  effect that the serialization 
>>> of a rule is not unique, and that that specific serialization 
>>> correspond to the PS rendering as stated in 1.3 and 2.5.
>>
>> No.
>
> I will not take that 'no' as meaning "no" until we have come to an 
> agreement on the previous topic, if you agree :-)
>
> 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)