- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Sun, 16 Mar 2014 08:48:47 -0400
- To: Travis Leithead <travis.leithead@microsoft.com>, "Gary Kačmarčík (Кошмарчик)" <garykac@google.com>
- CC: Yves Lafon <ylafon@w3.org>, "www-dom@w3.org" <www-dom@w3.org>, Philippe Le Hégaret <plh@w3.org>
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:art.barstow@nokia.com] >>>> 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
Received on Sunday, 16 March 2014 12:49:31 UTC