- From: Frederick Hirsch <frederick.hirsch@nokia.com>
- Date: Mon, 28 Sep 2009 09:13:35 -0400
- To: ext Robin Berjon <robin@robineko.com>
- Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, "<richard.tibbett@orange-ftgroup.com>" <richard.tibbett@orange-ftgroup.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
+1 regards, Frederick Frederick Hirsch Nokia On Sep 28, 2009, at 9:04 AM, ext Robin Berjon wrote: > On Sep 23, 2009, at 18:32 , <richard.tibbett@orange-ftgroup.com> <richard.tibbett@orange-ftgroup.com >> wrote: >> At the moment our lightweight requirements process means no >> centralised >> requirements document. Individual (lightweight) API requirements are >> to >> be included in individual W3C DAP specs i.e. as demonstrated by the >> Camera API draft [1]. >> >> There will be requirements that have overarching scope across all DAP >> APIs (such as design patterns & guidelines, security considerations, >> exception handling, etc) but I don't see such umbrella requirements >> being used as anything more than internal guidelines to editors when >> developing the DAP API specs. >> >> My view is that a general guidelines/requirements document would not >> necessarily be a useful public output of the W3C DAP WG. All general >> requirements will be implicitly included in all DAP API specs >> produced >> (because we will check that those guidelines are followed before >> publishing any spec). > > We can have our cake and eat it too. Where we store what doesn't > matter so long as people can find it. We can use the same lightweight > process and put those requirements in a single document linked to from > the other specs. And it can have a (short, sweet, simple) section on > requirements that apply to all APIs if people find that useful. > > I think that the argument in favour of publishing this document is > that my understanding of the positions is that we have two groups: A) > people who think there really should be such a document, notably to > document that we're not doing AppConfig; and B) people who don't > really have that strong an opinion about it. > > Since moving all the requirements to a single document instead of > inside individual specs has negligible cost (given that it's not on > Rec track), but since talking about it at length will take away > precious standards-writing time, I suggest that going ahead is the > most efficient option. > > -- > Robin Berjon > robineko — setting new standards > http://robineko.com/ > > > >
Received on Monday, 28 September 2009 13:14:29 UTC