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

Sounds OK to me.

Paul Vincent
TIBCO | Business Optimization | Business Rules & CEP
 
> -----Original Message-----
> From: public-rif-wg-request@w3.org
[mailto:public-rif-wg-request@w3.org]
> On Behalf Of Christian de Sainte Marie
> Sent: 27 June 2008 16:26
> To: RIF WG
> Subject: [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 Saturday, 28 June 2008 16:20:35 UTC