Re: at risk features

On Fri, 04 Jul 2008 11:43:55 +0200
Christian de Sainte Marie <csma@ilog.fr> wrote:

> 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).

Implementation experience is too vague. Granted, "based on feedback" is also
vague, but it does not limit the inputs to just implementational experiences.

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

Right. So why put everything into the same category?

> 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).

If the spec is ambiguous then please point specifically to what is ambiguous
there. I cannot see how this particular bit can be implemented in two
non-equivalent ways.

As far as I can understand your motivations, you are simply not sure if this
feature is useful for you or not. This is fair. But then, as I explained, the
conformance clauses are such that you are not required to implement that in
order to be conformant.

> 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).

If the strictness clauses are removed, an implementation that rejects unknown
data types, builtins, and other features (like external frames) is still
conformant.

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

Right.

> 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.

What about the at-riskness of the strict conformance clause?  The issue here is
not whether it should be implemented, but whether this notion is useful in the
first place. I, for one, feel it is not, but it is not based on anything
concrete. Therefore, I would like to see feedback on that from the community
(whether it is implemented or not).

Ditto about rif:text. The reason here is not implementational, but convergence
and feedback from other standards groups.

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

Sandro said it does.


	regards
	  --michael  

> 
> Cheers,
> 
> Christian
> 
>

Received on Friday, 4 July 2008 17:44:18 UTC