Re: PRD review, part 1

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

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

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.

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.

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

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

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

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?

> 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 :-(

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

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

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?

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

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

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

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

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?

I do not understand the reference to "new"? Can you explain, please?

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

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

> 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

Received on Friday, 15 February 2008 20:09:09 UTC