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

All,

Here below my comments on the Core document, version frozen on November 25. This completes my action-656.

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.

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

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

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 10:50:40 UTC