[BLD] My comments on version dated 5/10

All,

Here a some comments on a version I printed on Friday (Oct. 5) => some 
of them may be obsolete already (we live in such a fast paced world!).

Concerns sections 1 and 2 only: I embedded my comments in my version of 
section 3 [1] and my comments re sections 4-6 will come next.

A first general comment: overall, the document improved a lot. I am 
impressed!

Then, ome comments (that I think are) worse a general disucussion, or a 
decision:

- I propose that RIF BLD should be simply written RIF BLD; the RIF^BLD^ 
notation does not add value and may be difficult to reproduce in some 
settings;

- Should we add a glossary, e.g. definig terms such as "body", "head", 
etc, to make the doc easier to read to the non-LP, or even the non-rule 
folk?

- Since the signature stuff has no impact on either the presentation 
syntax, XML syntax or semantics of BLD, couldn't we move that part of 
the spec to a different place? That stuff is useful to people who will 
extend BLD, not to people who will implement it, as I understand it, and 
I am afraid that it might scare implementers away! If it cannot be 
easily moved, maybe all the relevant paragraphs could be clearly 
identified (e.g. boxed) and marked as non-required reading for 
implementers or something like that?

- Sometimes, the spec says "...is required..." (as in "...LITERAL is 
required to be an element of the lexical space..."), "...must..." (as in 
"A compliant RIF interpreter must reject ill-formed symbols"), etc: 
shouldn't we use MUST, MUST NOT, etc, instead?

- The separation of the specification of the condition language between 
a non-slotted and a slotted part is mostly historic, isn't it? It would 
make the doc an easier reading if they were reunited.

- In some examples, we have 2 different serialisation for the same 
expression: how do we deal normatively with that? We could define a 
normal form for RIF XML rules; or we could require that implementations 
preserve the form of an expression, for round-tripping purposes (that 
would be kind of difficult, though)

- Remove section 2.3 (Lists)
-------------------------------------------
Editorial comments, "au fil de l'eau", finally. Some comments are fairly 
minor; others are not:

- Organisation of the document: some sections are very long and contain 
a lot of material. Couldn't they be cut into pieces? It would make it 
easier to refer to material in the document.

- Abstract, 2nd par., "We give an abstract syntax (with UML 
visualsation)...": replace "We give" by "This document specifies"; 
replace "abstract syntax" by "presentation syntax"; also: "with UML 
visualisation of the abstract structural model" would be more exact;

- Abstract, 2nd par. "Examples...illustration": remove

- Abstract: add a sentence about the XML syntax and the mapping from PS 
to XS, e.g.: "This document also specifies an XML syntax and a mapping 
between the presentation syntax and the XML syntax."

- Sect. 1, 1st par., "All logic-based dialects will be based on RIF 
BLD": "All future logic-based dialects are expected to be based on RIF 
BLD", or "RIF BLD has been designed to be extended by all future 
logic-based dialects" would be more realistic (except if we mandate 
logic-based diialects to extend BLD, but is this something we really 
want to do?

- sect. 1, 2nd par., 1st sentence, "...(and with a standard first-order 
semantics): why the parenteses?

- sect. 1, 2nd par., 2nd sent., "...(IRIs) RFC 3987 as identifiers...": 
something is missing around the reference to RFC 3987, e.g. "...(IRIs, 
as specified in RFC 3987) as indeitifiers..."

- sect. 2.1, 1st par. 1st sentence, "...what can appear in a body (the 
if-part)...": for the non-LP folk, maybe we can extend this to "... what 
can appear in a body (aka condition, if-part, antecedent, etc)..."?

- sect 2.1, 2nd par., "The condition language...RIF condition language": 
redundant; remove

- sect. 2.1.1.1, 2nd par, first example, "p ( p ( a ) p ( a b c ))": 
wouldn't something like "p ( p ( a ) p ( a p c ))" be even more 
illustrative?

- sect. 2.1.1.1, subsect. "Signatures in the condition language of RIF 
BLD", 1st par. after the list of items, "RIF BLD also reserves a special 
predicate, =, to represent equality. Etc...": that comes after the 
signature of = has been specified!

- sect. 2.1.1.1, subsect. "Symbol space", end of 1st par., "...we will 
introduce a syntax for for defining prefixes for compact URIs.": is that 
true? Is that something we really want to do? Same for "TO DO: Define 
CURIES", btw...

- sect. 2.1.1.1, but-last par., last sentence, "A RIF interpreter must 
reject...": shouldn't that be "A RIF BLD interpreter..."?

- sect. 2.1.1.2, 5th par. ("We now give an EBNF...), but-last sentence, 
"It is not intended to be used as a concrete syntax for a rule 
language": add "RIF concrete syntax is the XML syntax for interchange"?

- same section, 1st par. after the EBNF, "The exists formula, where Var+ 
stands for the list of free variables in CONDITION...": replace with 
"...where Var+ stands for a list of variables that are free in 
CONDITION..."; also, the next sentence: "In RIF BLD, it is the only kind 
of quantified formula but in other dialects..." must be modified, e.g. 
"...the only kind of quantified formula that is allowed in a condition, 
but..."

- sect. 2.1.1.2, last par., "When RIF conditions...to the caller": remove

- sect 2.1.1.3., XML elements box, the description of the arg elt says 
"positional/non-positional with/without optional "index" attribute": remove

- sect. 2.2.1.1, 1st par., "The most important addition...": isn't that 
redundant? remove

- sect. 2.2.1.2, example 3: the full URIs make the example completely 
unreadable; same with part (a) of example 4, in section 2.2.1.3.

Christian

Received on Tuesday, 9 October 2007 11:29:07 UTC