Re: [Core] ACTION-656: review Core (November 25 freeze)

Christian de Sainte Marie wrote:
> 
> All,
> 
> Here below my comments on the Core document, version frozen on November 
> 25. This completes my action-656.

Thanks.

> Section 1: ok.
> 
> Section 2: Presentation syntax
> 
> - Sorry to restart that old discussion, but I always have difficulties 
> with the presentation syntax being normative but not the concrete one: I 
> guess it might be confusing for the outside reader too. I really believe 
> that we should settle for another term for the non-concrete syntax: I 
> like "abstract syntax", since this is what it is, as far as I 
> understand; but I am open.

As you say this is an old discussion. Core is just following the 
structure and nomenclature from BLD. Since BLD is frozen it seems we 
have little room for manoeuvre.

> - Sorry to restart that other old discussion, too, but I continue to 
> object to having Core specified wrt to RIF-BLD only: if anything, it 
> should be the other way around (BLD/PRD being specified wrt Core). If 
> Core is to be a real dialect all by itself, the spec should stand alone 
> for the potential user to read and understand. I am not against having a 
> duplicate spec (oh, ok, a triplicate one), as a specialisation of BLD 
> (and PRD) and stand alone, but, if there is only one, it must be the 
> stand alone one.

I originally advocated having Core as a standalone document.

However, it is clear that Core is such a large fraction of BLD that as a 
standalone document it would duplicate most of the BLD document. That 
seems redundant, hard to maintain and may leave people confused as to 
the relationship between the two. [I have visions of people doing diffs 
on all the duplicated text trying to work out where the subtle 
differences are.]

Given that BLD is in last call then a complete restructuring of that 
document seems out of the question.

Originally I tried to have Core be a little easier to read by having the 
"math english" section and examples standalone and only defer to the BLD 
document for the semantics (since that really is unchanged and seems 
pointless to duplicate). This wasn't acceptable to others who preferred 
the very short specification-by-reference style. Working groups are a 
series of compromises and this seemed like a acceptable compromise :-)

> - Section 2.6: I am kind of puzzled that the only part of the spec that 
> is detailled in extenso is also the only non-normative part, that is, 
> the EBNF, when the normative parts (abstract syntax, semantics and XML 
> syntax) are all specified only by reference. Even the exemples are only 
> references. If there is a specific point in specifying the EBNF 
> extensively, it should be made explicit.

I felt it helps people understand what can and can't be expressed in 
Core in a way that the math english deltas don't. Even though it is not 
normative I suspect many implementers will use the EBNF as a guide to 
understanding the syntactic structure of the language.

Thanks for all your other comments which we'll take a look at and see 
how we can improve the phrasing for future drafts.

Dave

> Sections 3 and 4: ok
> 
> Section 5: Conformance and safety
> 
> - Shouldn't it be "safeness", in the title, rather than "safety"?
> 
> - "For safe Core documents, the logical semantics of RIF-BLD and 
> operational fixed-point semantics of RIF-PRD coincide. In the absence of 
> the data types and built-ins, this follows for Vianu97." Lest this might 
> seem a bit short to the outside reader, I suggest adding an editors' 
> note to the effect that a complete specification of Core as a 
> specialisation of PRD will be included in a future draft (see also my 
> comment re section 6).
> 
> - section 5.1: definition of safeness. The first bullet in the 
> definition is not cristal clear (at least to me): does it mean that a 
> variable ?v is safe wrt a RIF condition formula phi iff it is free in 
> Phi and it does not occur in External atoms only and it does not XXX
> 
> - section 5.2: Conformance clauses
> 
> ** "RIF-Core does not require or expect conformant systems to implement 
> the RIF-Core presentation syntax". That sentence is confusing, I 
> believe: is that the concrete PS (EBNF) or the abstract syntax? If the 
> former, the sentence is useless (the concrete PS is non-normative) in 
> addition to being confusing: it should better be removed, I think. If 
> the latter (the abstract syntax), I do not understand how an conformant 
> system can implement a semantic-preserving transformation without 
> implementing the abstract syntax: but, assuming it can, why make it 
> normative, then?
> 
> ** "Conformant Core producers and consumers are required to support only 
> the entailments of closed RIF condition formulas." Isn't that a 
> well-formedness condition for rules? I mean: do free variables have a 
> semantics in BLD/Core? They do not in PRD, as far as I understand...
> 
> ** Strictness requirement: I kind of remembered that we had resolved to 
> remove the "at risk" mark from the strictness requirement, but I cannot 
> find when, nor a resolution about it. I do not see a problem with the 
> strictness requirement, at least the way it is phrased in the Core 
> document (although I think that I was the one raising it, initially).
> 
> Section 6: I agree that PRD and BLD should be treated symmetrically in 
> Core, but section 6 is not at the level of the rest of the document, in 
> its current state. I suggest removing its content and replacing it with 
> an editors' note to the effect that, in a future draft, RIF-Core will be 
> specified as a specialisation of RIF-PRD as well. Also, the structure of 
> the document should then be reworked to have the spec of Core wrt BLD 
> and its spec wrt PRD be more on a par.
> 
> That's all, folk!
> 
> Cheers,
> 
> Christian
> 
>

Received on Tuesday, 2 December 2008 16:00:29 UTC