- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Mon, 10 Mar 2014 14:29:53 -0400
- To: "Gary Kačmarčík (Кошмарчик)" <garykac@google.com>, "www-dom@w3.org" <www-dom@w3.org>, Travis Leithead <travis.leithead@microsoft.com>
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