Re: Splitting key/code tables out of DOM3Event spec

On 3/14/14 8:28 AM, ext Yves Lafon wrote:
> On Fri, 14 Mar 2014, Arthur Barstow wrote:
>> On 3/12/14 5:32 PM, ext Travis Leithead wrote:
>>> From: Arthur Barstow [mailto:[email protected]]
>>>> I support your proposal but would like to hear from others that are
>>>> actively participating in this work or consider themselves 
>>>> "stakeholders".
>>>>
>>>> Travis - what are your thoughts on this proposal?
>>> Given the fairly consistent trickle of bugs related to the 
>>> presence/absence of key names/values, I think this move [forking out 
>>> the key/code tables and values] *could* help the core DOM L3 Spec 
>>> move to Recommendation faster.
>>>
>>> However, it's not clear to me that we haven't already reached the 
>>> end of the trickle of interest groups petitioning new key values. 
>>> Given the 4 previous Last Calls of this spec, you'd think the whole 
>>> W3C-world knows about this document and has cracked it open at least 
>>> once. The real truth will come at CR stage. Perhaps instead of 
>>> pre-emptively splitting this stuff out of the spec, we keep it in, 
>>> mark it at risk (to [potentially] move into another doc as feedback 
>>> arrives at CR)
>>
>> I'm not that familiar with using the Feature @ Risk process [F@R] but 
>> my understanding is that it could be used to prevent a Candidate 
>> Recommendation from going back to Last Call if/when there is 
>> agreement to add YA code value and/or key value. However, it's not 
>> clear to me if F@R can be used for Last Call docs and if it cannot be 
>> used, then if there is agreement to add YA code value and/or key 
>> value, I think that would mean all of D3E would require YA Last Call.
>>
>> Yves, PLH - would you please clarify if we may use the F@R process 
>> for a LC?
>
> F@R is here to set expectations, using this for LC is a good way to 
> ask for specific feedback on those features, so it's actually good 
> practice to document what is considered as stable, at risk of being 
> removed, or just not stable yet.

Although it seems like splitting up the spec is a `better` long term 
solution, given what Yves says above, it appears the most expedient way 
forward is to continue with a single spec that includes very clear F@R 
information re the code value and key value sections. So let's please 
continue this way and thanks Gary for your drafts (as we might need to 
come back to them).

-Thanks, ArtB