Re: Splitting key/code tables out of DOM3Event spec

Hi Gary,

On 3/6/14 12:59 PM, ext Gary Kačmarčík (Кошмарчик) wrote:
> We have a few obvious options to do this:
> (3) Split out the tables now into a separate spec (or specs) and have 
> a separate Rec track for them. Update this spec as needed.
>
> There are pros and cons to each approach.
> (3) means we need to create new rec-track docs Right Now!
>
> Our current preference is for option (3).

Thanks for creating this proposal!

Overall, I also prefer option 3 (although I realize there could 
initially be a bit of a time hit).


> I believe that the 'key' values and 'code' values should go in 
> separate documents because it will make it much easier to search for 
> 'key' (or 'code') values. Having separate documents means that you 
> won't accidentally look in the wrong table when you search.

SGTM.

> We'd like to make this change ASAP (since it will help the D3E spec 
> get to RC). Please let us know if you can think of any problems with 
> this approach, or if you have suggestions for improving what we're 
> trying to do.

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?

Assuming we have consensus to move forward with the split, given the key 
values and code values are likely to change over time, I'm wondering 
about the tradeoffs of putting that information in a normative spec we 
push along the Recommendation track versus using a "living" document 
process that would facilitate some group (f.ex. the mobile IG, web and 
TV IG, etc.) submitting a PR to add and/or modify the data. Does some 
"interested party" actually need a Recommendation track spec for this 
data (f.ex. to normatively reference)?

-Thanks, AB

Received on Monday, 10 March 2014 18:30:30 UTC