- From: Robin Berjon <robin@robineko.com>
- Date: Mon, 28 Sep 2009 15:04:59 +0200
- To: <richard.tibbett@orange-ftgroup.com> <richard.tibbett@orange-ftgroup.com>
- Cc: <public-device-apis@w3.org>
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:05:37 UTC