Re: PRD review, part 1

Christian de Sainte Marie wrote:
>
> </Chair>
> <PRDeditor>
> Gary,
>
> Thanx for your comments. I implemented what need implementation and 
> added some notes in the text to remember the discussion points. See 
> replies/comments/clarification/action taken inlined below.
>
> Gary Hallmark wrote:
>
>> This covers approx. the first half of the spec, up to but not 
>> including 2.2. Hopefully I'll be able to finish tomorrow (and it 
>> won't invalidate the following :-)
>
> So, I'all start to answer your comment, hoping that your further 
> review will not invalidate my answers either :-)
>
>> General comment: in the wiki-tr version, most of the links are 
>> broken, I think because they are relative and thus link to, e.g., 
>> http://burns.w3.org/2005/rules/wg/wiki/CamelCase
>
> Yep. And in most cases, I did not even try to include links, just 
> indicating that there would be one...
>
> I do not plan to include/update the links in the frozen version for 
> the F2F: would that be a problem?
no
>
>> 1.
>>
>> One thing to add to the overview is what kind of semantics PRD will 
>> have.
>
> What do you have in mind? A general, informal description of what kind 
> of rules PRD covers, including wrt their semantics, or just an 
> indication that PRD has an operational semantics?
I think the latter.  And an explanation for why it is different from BLD.
>
> My intention for 1.1 was to have the former and something about the 
> intended process model. Unlikely to be done in time for the F2F, 
> though...
>
>> 1.2.
>>
>> RIF-PRD doesn't strictly extend RIF-BLD condition language (e.g. no 
>> logical functions)
>
> Indeed. My understanding was taht BLD had been separated from Core to 
> free it from the constraint to be extensible to PRD. No decision about 
> what will or will not be in BLD made any reference to extensibility to 
> PRD. So, I did not consider that extending BLD in a strict sense was a 
> constraint we wanted to enforce.
my point is that this section gives the impression that PRD extends BLD 
(first bullet item)
>
> However, my sense of our discussions in Boston was that PRD should not 
> try to improve on BLD, and should stick to BLD or as close as BLD as 
> possible.
yes
>
>> 1.2.2
>>
>> I don't know what compatibility of PRD and BLD means.  Presumably 
>> there is some common core.  I think this core will be small and 
>> simple enough that signatures does not come into play.  The less said 
>> about signatures, the better.
>
> Yes. I should have added a colored warning on 1.2.2 and 1.3.2 that I 
> did not revise them since the first strawman, that the text was 
> probably obsolete, and that the final text would depend on the 
> architecture of Core rather than that of BLD.
>
> However, I am not sure that Core will not have the signature thing: my 
> understanding was that the signatures were not sued in BLD either, and 
> that they were there only because future extensions would need them. 
> Will that be any different for Core? Michael?
>
> Anyway, I added a caveat in the text, for the frozen version.
>
>> The terms "individual" and "constant" sometimes seem to be used 
>> interchangeably, but really "object" is meant for individual..  
>> "Individual" should be defined (or use object, which is probably more 
>> familiar to PR folk)
>
> Yes, maybe. The intention is to make it clear that constants may stand 
> for something more complex that a single, simple value, and I would 
> fear that using "object" might be too specific, e.g. what about 
> records, etc?
>
> or am I just too prudent, here?
>
> I have added a comment in the text, to be sure that we do not forget 
> to discuss that point.
>
> I also added a "Glossary" section (empty for now), which I think would 
> be helpful anyway but I did not have the time to do it...
yes.  the term "individual" has a specific technical meaning that should 
be defined (sounds like a person to me)
>
>> If we do say something about signatures, I think "However, dialects 
>> extending RIF-BLD will be allowed" should be "However, dialects 
>> extending RIF-PRD will be allowed".
>>
>> 1.2.3.
>>
>> BLD has no structure diagrams and XML is derived from the 
>> presentation syntax.  Why diverge here?
>
> Well, BLD WD1 had them, and, until recently, it seemed likely that BLD 
> WD2 would have them as well. So, I included them, with no other 
> purpose than helping make the syntax clear (well, they help *me* think 
> about the structure of PRD).
>
> I added a question mark about them...
some will like them, some will be confused by them, but all will be 
confused if it isn't exactly consistent with xml and presentation syntax 
(which it isn't I think)
>
>> 1.3.1
>>
>> This looks like another "stylistic" divergence from BLD that needs to 
>> be reconciled.
>
> I am not sure: BLD and PRd target different crowds.
so you are sure it is a divergence but not sure it should be reconciled.

I prefer black shoes over brown shoes, but I prefer 2 brown shoes over 1 
black and 1 brown...
>
> For a target of implementation developers, the format used in PRD 
> seems more helpful.
>
> Btw, I am refering, here, to both the style of the presentation of the 
> XML syntax, which I understand you have in mind, and the style used in 
> the syntax parts of the doc, which is basically the one we agreed on 
> in Boston.
>
> If we decide that the style of presentation for the XML syntax must be 
> aligned in BLD and PRD, I will strongly argue that the style used in 
> PRD - and in other W3C specifications - is better becuase it is more 
> precise and less ambiguous and because it does not require a reference 
> to the presentation syntax for disambiguation.
>
> Knowing that the XML syntax will be normative and the presentation 
> syntax will not, understanding the XML syntax must not depend on 
> knowing the presentation syntax.
>
>> [ and ] are used to form groups -- I think you need to escape the [ 
>> and ] because it renders as a hyperlink
>
> Corrected. Thanx.
>
>> 2.
>>
>> [ RIF-Core ] should be a hyperlink, but it isn't.
>
> Yep. That's because I did not care about the links (and, for that 
> specific case, Core does not exist yet, anyway :-)
>
> Is that important for the version to be frozen before the F2F?
its ok for now
>
>> 2.1.
>>
>> In the diagram, some lines that cross at right angles connect, and 
>> some don't.  This is confusing.
>
> Right. I did not find how to do non connecting crossings in MagicDraw :-(
maybe you could put a little circle on the intersection if they connect?
>
>> if PRD and BLD could agree on how to represent the syntax, it would 
>> be easier to verify (refute) the assertion that PRD's condition 
>> language extends BLD's.  It would also avoid repetition.
>
> That assertion is not made (and it would be false, if it was).
my point is that a reader might want to check what the difference in 
syntax is, and right now that's harder than it should be.
>
>> To the extent that PRD conditions are a superset of BLD's, then we 
>> should just describe the extensions (naf, aggregation) and not repeat 
>> the BLD descriptions, just point to BLD.  E.g., BLD recently renamed 
>> ATOMIC to COMPOUND.  Because we have repeated descriptions and 
>> syntax, we have many places to update in PRD.
>
> (PRD conditions are not a superset of BLD's, but even if it was) I 
> believe that the specs must be self standing, that is, PRD 
> implementors must not need read any other spec but PRD (e.g. the fact 
> that PRD implementations can handle Core rulesets should be built in 
> the specification of PRD, not require reading and understanding, let 
> alone implementing, Core).
yeah, I once had a programmer that believed all his code needed to be 
self standing and refused to reuse library components -- he figured his 
hand coded hash table would be faster anyway.  I fired him.
>
> However, this is a larger discussion regarding the architecture of RIF 
> as a family of dialects. To be discussed. Do you want to raise an issue?
>
>> 2.1.1.
>>
>> In preventing logical functions (Uniterm TERMs), have we also 
>> prevented nested frames (Frame TERMS)?  That's not good...
>
> No, not as far as I understand. What makes you think so?
the syntax diagram in 2.1
>
>> 2.1.1.1.
>>
>> exactly the same as BLD, right?
>
> Right.
>
>> 2.1.1.2.
>>
>> I think ..--.. is a valid NMTOKEN, so I'm not sure this restriction 
>> helps much.
>>
>> I don't think ? is legal in an NMTOKEN (but since the spec uses hex 
>> chars, I didn't exhaustively check)
>
> The point of limiting Var names to a restiction over Unicode strings 
> is that most PR rule languages have such restrictions => the idea is 
> to ask whether we can find a restriction that does not forbid variable 
> names used in some language but that remove some burden for 
> implementors...
If we specify Java naming, that removes the burden for me.  Anything 
else and I have to do some mapping, and I don't think it matters what 
that "anything else" is.
>
>> 2.1.1.3.
>>
>> builtin function, evaluated function, or fixed interpretation 
>> function, ... need consistent terminology
>
> Right. I added a note to make sure we have that discussion (I would 
> say "builtin function" cannot be the general term we use, because 
> ExtTerm can be user-defined; and I have a preference for fixed 
> interpretation function that is self-explaining. For a PR crowd, 
> however, procedural attachment might be the better name (and the best 
> name for the PRD crowd might not be the best name for BLD people)...
the rule-ml people use procedural attachment, but that means nothing at 
all to the business rule community....
>
>> Isn't the syntax 'Builtin(' Uniterm ')'
>
> Yep, that was indeed decided since. I have corrected the prez syntax 
> (not refering to Uniterm in the syntax for a TERM ExtTerm, though, 
> since the Uniterm has not been specified yet.
>
>> The syntax and semantics should be exactly the same as BLD.
>
> It is, isn't it?
>
>> Why is the op a TERM rather than a Const?
>
> I think this is because somebody prefered it that way. But I added the 
> comment to make sure that we would check the consensus on that.
>
>> 2.1.2.2.
>>
>> consistent terms: builtin, evaluated, or fixed interpretation relation
>>
>> I prefer Const op only.
>>
>> links are broken, e.g. [X F&O]
>
> See earlier comments.
>
>> not defining behavior when args are out of domain hinders 
>> interoperability
>
> I disagree strongly. This is like the discussion about how to handle 
> errors in BLD.
>
> Consummers of a ruleset know the domains of definition; if they chose 
> to use the rules outside of their domain of definition, they know what 
> they do; it is out of scope for RIF; and if it is an interchange 
> problem - and thus in the scope of RIF -, it is not up to RIF to 
> repair what is broken in the specification of the function (I mean, if 
> the rules are meant to be used out of the domain of definition of some 
> function, the definition of the function has to be changed, it is not 
> up to RIF to specify what is the expected behaviour).
>
> Or did you mean that RIF shoudl require that the user be notified? I 
> dunno... Shouldn't that rather be part of the spec of the function?
let's say we exchange a rule with a divide builtin.  we don't define 
what happens if the divisor is 0.  my builtin returns -1 in this case.  
yours explodes in a huge fireball.  do you foresee any surprises when we 
exchange rules?

>
>> 2.1.2.3.
>>
>> most PR systems have builtin equality (sides must be bound) and 
>> builtin assignment (in actions).  This "logical equals" is something 
>> more.
>
> Does you comment stand after you have read the semantics? I mean, is 
> that just a matter of amending the text of the "informal semantics" or 
> is there something more?
its seems ok after a more careful reading. 
>
> Notice that equality, if it is in Core, will be at best the same kind 
> of ground equality as what is specified here (or whatever its name, if 
> this is not what is meant with "ground equality").
>
>> 2.1.2.4.
>>
>> object and class makes more sense to me, too.
>>
>> My PR system has a builtin # predicate and a builtin "new" function 
>> that takes a (constant) class as an argument and returns a new 
>> object.  This "logical #" is something more.
>
> Even after reading the semantics?
ok
>
> I do not understand the reference to "new"? Can you explain, please?
my rule language borrows a lot from Java
>
>> 2.1.2.5.
>>
>> My PR system has a builtin ## predicate and a builtin class 
>> declaration function that takes a (constant) class as an argument and 
>> returns a new subclass.  This "logical ##" is something more.
>
> Same question as above?
same answer, too.
>
>> 2.1.2.6.
>>
>> slotKey might be a case where a Uniterm TERM makes sense, if it can 
>> represent a frame "method".
>>
>> I don't think the syntax diagram in 2.1 allows nested frames 
>> (disagrees with the presentation syntax here)
>
> No. I considered that the nested form was syntactic sugar and that it 
> did not need be in the syntax diagram (and it made the syntax diagram 
> really unreadbale, too :-).
>
> I added a sentence in the description of the syntax diagram to make 
> that clear (or so I hope!).
>
>> 2.1.3.4.
>>
>> My PR system is forward chaining.  It doesn't prove anything.  The 
>> informal semantics is simply that its truth value is the opposite of 
>> the truth value of its CONDITION.
>
> Corrected.
>
>> according the syntax, there can be no empty NAF.
>
> Right: that's because I do not see what it would mean. Hence the 
> (doppel-bottom) question: do you thing we need the possibility to have 
> empty Nafs? If yes, what would be their semantics?
empty naf makes no sense to me.  for that matter, neither do empty and 
and or.  Seems a silly and confusing way to represent true and false.
>
>> 2.1.3.5.
>>
>> is this needed in addition to 2.1.4.2.?
>
> For completeness? I dunno... I added a note in the doc.
>
>> 2.1.4.
>>
>> I suspect that aggregation is at least as important in logic dialects 
>> as in production rules.  That is because logic based languages are 
>> frequently used for querying, and querying frequently uses 
>> aggregation. Consider SQL and, to a lesser extent,  prolog.
>>
>> I would rather wait a bit and work to make sure we don't diverge too 
>> much here.  I find the linking of aggregation and quantification 
>> confusing.  I guess a SUM doesn't exist if there isn't anything to 
>> sum, but the COUNT exists and is zero if there isn't anything to 
>> count.  But maybe your intent was simply to reuse the <declare>.  May 
>> Aggregation should be a QUANTIFICATION?  (I suspect my questions are 
>> adequately reflecting my confusion :-)
>
> Aggregation is what took me the longest to figure out (and is one big 
> part of why it took me 3 months to produce the second draft after 
> Boston)... So, it is way to late today to comment on that: you will 
> have to wait until Monday for some explanation of why I propose to do 
> it that way :-)
>
> And now, have a good <whatever part of the day/week somes next in your 
> respective parts of the world; for me, that's the weekend!>
>
> </PRDeditor>
> <Chair>
>
> cheers,
>
> christian
>
>
thanks for all the hard work on this.  see you in Paris!

-- 


Oracle <http://www.oracle.com>
Gary Hallmark | Architect | +1.503.525.8043
Oracle Server Technologies
1211 SW 5th Avenue, Suite 800
Portland, OR 97204