[PRD] Issues to resolve before publication (et proposed resolutions)

All,

Based on Gary's, Adrian's and Paul reviews, on-going discussions on the
mailing lits, my own views on the subject, and the assumptions that
everybody agrees that we must publish PRD FPWD sooner rather than later,
and get feedback from the larger community as early as possible, I
listed a limited number of issues (below) where, I believe, we are close
to agreement ("issues" in the general sense of the term, not WG formal 
issues).

Along the issues, I also listed proposed resolutions that, I believe,
can be acceptable for everybody.

I propose that we consider only these issues before before publish the
FPWD, and I believe that, if everybody set themselves in a conciliatory
mood, we can freeze PRD FPWD on Tuesday's telecon and publish right
after (that makes a lot of believes; but remember that this is only a
FPWD, not a LC).

Cheers,

Christian

------------------------------ >8
Issues are listed in no particular order
"Current versio" refers to [1]. It includes the changes I made, as
proposed in [2] (in response to Gray's review [3]), ...
[1] http://www.w3.org/2005/rules/wiki/PRD
[2] http://lists.w3.org/Archives/Public/public-rif-wg/2008Jun/0190.html
[3] http://lists.w3.org/Archives/Public/public-rif-wg/2008Jun/0078.html
[4] http://lists.w3.org/Archives/Public/public-rif-wg/2008Jun/0097.html

#1. Section 1.1: Introduction. I propose that we keep that section as it
is in the current version, except for typos and blatantly bad english. I
added an editor's note about the presentation syntax and will open the
corresponding issue. (Gary, could you check that I got the PS right in
example 1.2, please?)

#2. Section 1.3: Running example. I propose that we keep it as in the
current version. I added a paragraph at the end of the section to clarify
some of the assumptions (per [4]):
"The assumption is that a system that consumes a RIF
document published by Jim knows how to map Jim's published data model
and specification of fact predicates and functions to/from its own
underlying data representation. What a consumer is expected to do when
this is not the case is still under discussion and will be specified as
a conformance clause in a future version of this document."

#3. Section 2.1.1.1.: Non-standard data types in the spec of Const.
Proposal: keep as in the current version. As proposed in [2]:
  * I removed the second sentence (from "They can also..." to the end of 
the alinea) from the first alinea of the paragraph about symbols with 
non-standard types, as well as the following alinea;
  * I changed the last alinea to start with "Dialects and applications
that extend...";
  * I added the editor's note.

As a consequence, I also removed the example 2.1.e (but I would still
like to understand your comment in [3], Gary).

#4. Sections 2.1.1.3 (External) and 2.1.2.1 (Atom): Named Arguments
Uniterm (NAU). I really believe that we should not have them in PRD. But
I understand that others think we should. I propose that we decide by
simple majority vote, between the following two options (for FPWD only,
and we open an issue to keep the discussion open):
  1. No NAU (in FPWD), that is, leave the draft as it is (in the current
draft, I commented out the NAU in the PS, as this was easier to do that
to add them in the XML syntax etc);
  2. NAU in FPWD, with an editor's note asking for feedback (if this is
the majority decision, I will uncomment the NAU in the PS, and add them
in the XML syntax).

#5. Section 2.1.3.5 (NmNot): tag name? I do not care, but we must choose
one. I see two options, here again, and I propose, again, that we decide
by a simple majority vote:
  1. Keep NmNot, pr PRnot, or whatever other name that is not overloaded
(but rather meaningless, as a consequence);
  2. Change for Not.
In any case, add an editor's note that name may change (I added one in 
the current draft).

#6. Section 2.2 (Actions): Assign or not Assign in FPWD? I propose to 
keep it, now that it has been re-included with Ed: Adrian wants it, Mark
wants it, I am rather in favor, Gary balances. I added an editor's note 
in section 2.2.1.3 (Assign) to the effect that this was still under 
discussion and that the syntax was liable to evolve.

Gary, I see that you changed the examples: I did not check exactly how, 
but if we agree on the above solution, you will have to revert that 
change, right?

#7. Section 2.3.1 (Rule): Adrian added ATOMIC as a form of RULE, to 
allow a RULE to be used to represent facts. However, a production rule 
without a condition is not a fact: it is an unconditional action. I
propose to revert to the previous version, as in [1], where the "if"
part can be omitted (meaning ture by default) , to represent rules where
the action part is intended to be executed for all the bindings of the
varaibles.

#8. Section 2.3.1.2 (Forall): Gary does not want the CMP example to be 
presented with binding patterns. On the other hand, they are included in 
this version of RIF-PRD because all the mainstream PR languages use 
them, and there is an editr's note asking for feedback about them and 
the nested forall: so, providing an example makes sense.

I propose that we include a small example with patterns, and that the 
XML rendering of the complete CMP rule be moved to an appendix, where it 
can be serialized without patterns nor nested Forall, as Gary prefers, 
with a comment to the  effect that the serialization of a rule is not 
unique, and that that specific serialization correspond to the PS 
rendering as stated in 1.3 and 2.5.

#9. Section 3.3 (Operational semantics of actions):
  a. Semantics of Assign. I added a transition that defines the 
semantics of Assign, basically as a set of Retracts followed by an 
Assert; and I added an editor's note warning that this was unstable;
  b. Semantics of Execute. I added an example, as suggested by Gary.

Proposed: leave it as in the current draft.

#10. Section 3.4.1: matching theory. As I explain in [2], it is needed 
to take the semantics of datatypes into account. That is mentionned in 
an editor's note only, out of laziness rather than anything else (and 
also because it relates to the question of application-specific 
background knowledge).

Options:
1. keep the editor's note as it is;
2. add a paragraph in the text re how it takes into account the
semantics of data types etc, and leave an editor's note saying that this
might be extended to take application-specific theories into account
(such as app-specific object models etc).

I propose that we go by option 1 for the FPWD.

#11. Section 3.4.2 (PICK) and 3.4.2.1 (fireableINSTANCES): No-repeat. I 
have not looked at that one yet. I will propose a, hopefully consensual, 
solution by Monday night (my time).

If we could agree that these 11 question are the only ones we want to 
deal with before FPWD, and, further, if we could agree on the proposed 
solutions or some variation of them, and if we could do that by email 
before the telecon Tuesday, then, we can essentially freeze PRD for FPWD 
on Tuesday!

Cheers,

Christian

Received on Friday, 27 June 2008 15:25:34 UTC