W3C home > Mailing lists > Public > public-rif-wg@w3.org > July 2008

Re: at risk features

From: Chris Welty <cawelty@gmail.com>
Date: Sat, 05 Jul 2008 10:47:17 -0400
Message-ID: <486F8975.9080200@gmail.com>
To: kifer@cs.sunysb.edu
CC: Christian de Sainte Marie <csma@ilog.fr>, Sandro Hawke <sandro@w3.org>, RIF WG <public-rif-wg@w3.org>


I changed the wording in the template to "based on feedback".

Note that as previously mentioned this wording works for "last call" but not for 
CR. So our CR at-risk features should be the ones we specifically seek 
implementation experience to resolve (equality comes to mind here, for example).

-Chris

Michael Kifer wrote:
> 
> 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
>>
>>
> 

-- 
Dr. Christopher A. Welty                    IBM Watson Research Center
+1.914.784.7055                             19 Skyline Dr.
cawelty@gmail.com                           Hawthorne, NY 10532
http://www.research.ibm.com/people/w/welty
Received on Saturday, 5 July 2008 14:48:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:50 GMT