Re: at risk features

Michael Kifer wrote:

> I still do not like that wording because the reasons for marking several of the
> different features as "at risk" have little to do with them being implemented.
> "Based of feedback" is a much more neutral and acceptable wording.
> 
> If we retain the present wording then I would insist on reexamining the
> reasons behind marking each particular feature as "at risk" so that only
> the features that truly depend on the availability of implementations would
> be marked as such.

Notice that we say "based on implementation experience", not "depending 
on availability of implementations".

Even if we marked these three features at risk for different reasons, 
these reasons are all related to implementation concerns. And, of 
course, it is trivially correct to say that they can be removed based on 
implementation experience (even if it is not the only criterion).

Of course, only equality in the head we marked at risk specifically 
because of concerns about implementation.

But we marked external frames at risk because we wanted to clarify what 
they are: if this (what they are) is really ambiguous in the current 
spec, implementers are liable to experience problems implementing them 
(e.g., we can end up with different implementations implementing 
different things).

Re the strictness conformance clause, if I remember correctly, I asked 
that it be marked at risk, because I feared that it might be too 
restrictive for practical uses of BLD as an interchange format (based on 
my experience in a PR worls that, in practice, many rule sets use 
external predicates and/or functions).

Ok, that one is, maybe, more related to usage than implementation.

So, I am not convinced that replacing "based on implementation 
experience" by "based on feedbcak" is a good idea: except for the 
further discussions that we wanted to have wrt external frames and 
strict conformance, it is really implementation experience that could 
influence the decision, not just any kind of feedback.

This being said, if you insist on "feedback", it is fine with me, as 
long as it works from a process point of view.

Cheers,

Christian

Received on Friday, 4 July 2008 09:43:57 UTC