- From: Leora Morgenstern <leora@us.ibm.com>
- Date: Tue, 2 Dec 2008 10:51:33 -0500
- To: public-rif-wg@w3.org
- Message-ID: <OF09755967.39096276-ON85257513.0056A91F-85257513.00571DEF@us.ibm.com>
Below please find my review of the November 25 version of the Core document. General comments: This document is a good draft, but could benefit from changes in some areas, specifically: --- Some organizational/structural changes --- More clarifying remarks --- More examples --- More explanation of how certain choices were made Regarding the latter, I think it would be helpful to have some text addressing the following: --- What were the problems encountered in formalizing an intersection of BLD and PRD? --- How were these problems solved? Specific comments: (Note: these are in order of the document, so minor remarks (e.g., typos) sometimes precede substantive remarks.) Section 1. It would be a good idea to say early in this section that this document assumes familiarity with BLD and PRD. Oddly, you have this at the beginning of Section 6 for PRD ("The reader is assumed to be familiar with RIF-PRD as described in ...") but it's never said that the reader is assumed to be familiar with RIF-BLD. Better to have one sentence at the end of the first paragraph of Section 1, such as "This document assumes familiarity with BLD and PRD as described in ..." Then, of course, omit that sentence in Section 6. This introductory section might also be a good place to have some sort of text as I suggested above, explaining what problems were encountered in formalizing the intersection of BLD and PRD, and how these problems were solved. Section 2. It would be good to explain --- even if with just a few appositive phrases --- how you define presentation syntax and concrete syntax, and how you define normative. As it stands, this is all quite confusing. Is there somewhere where "presentation syntax" and "concrete syntax" are clearly defined? Is there a common understanding of these terms? I have seen them used before, e.g., in OWL documents, but there are differences: for example, the OWL Presentation Syntax clearly states that it's not intended to be a normative specification. Do you mean to say here that people should write rules in Presentation Syntax because it's less error-prone and it's easier to read than XML? And/or do you mean to say that the syntax and semantics of BLD were developed in something akin to Presentation Syntax, and that the XML specification was developed derivative of that? Whatever you mean, you should say it clearly. Section 2.2: This is an example of where you could explain the choices made in constructing Core from BLD and PRD. Both BLD and PRD allow named arguments, so why doesn't Core? Section 2.6: If EBNF is unable to express all of the well-formedness of Core formulas, in particular because it can't express the requirement that symbols appear only in one context, then it can't specify Presentation Syntax. It specifies a superset of Presentation Syntax. This should be said explicitly. It's just not correct to say that this is an EBNF grammar for Presentation Syntax. (I made a similar point in my April 15 review of FLD.) Section 3: The sentence "RIF-Core is a syntactic subset of RIF-BLD and the semantics of RIF-Core is identical [to] that of RIF-BLD" is repeated as the first sentence of Section 5. It should be eliminated from one of those sections. Also, this is the only sentence of Section 3. Are there plans to expand this section? Section 5: The title uses the word "Safety"; the rest of this section uses the word "safeness." You want to use "safety" throughout: it means what you want to say: the condition of being safe. Normative in End of second paragraph of Section 5: "In the absence of the data types and built-ins, this [coinciding of logical semantics of BLD and operational semantics of PRD] follows from [Vianu97]." -- Omit the "the" before "data types" -- Narrow the reference; point to a particular section or theorem of [Vianu97] Section 5.1: It would be helpful to begin this section would some development of the intuition of safety. You do, in the previous paragraph, say that "some formulas may be unsafe and cannot be executed under the RIF-PRD operational semantics." Giving some examples of this would be helpful and would serve to develop the reader's intuition on why safety is important. The definitions are a bit murky. Examples, both positive and negative, would help. In the first bullet point of the definition, Disjunction should not be capitalized. Section 5.2: As a consequence of the second bullet point after "In addition: --- that is, the bullet point starting "A conformant RIF-Core consumer is .." --- if one is a conformant RIF-BLD consumer, one is not a RIF-Core consumer. Is this what you want? It seems somewhat counterintuitive to me.\ Section 6: As mentioned earlier, The second sentence, expanded to include familiarity with BLD, should be moved to the beginning of the document. Section 6.2: What do you mean when you say "RIF-BLD allows logic and externally specified, fixed-interpretation functions as TERM, whereas ..." I would think there must be a typo here: what does it mean to allow logic? I am assuming this section is incomplete. Best regards, Leora
Received on Tuesday, 2 December 2008 15:52:22 UTC