W3C home > Mailing lists > Public > public-device-apis@w3.org > September 2009

Re: ISSUE-22: Should we have an umbrella requirements document?

From: Robin Berjon <robin@robineko.com>
Date: Mon, 28 Sep 2009 15:04:59 +0200
Cc: <public-device-apis@w3.org>
Message-Id: <0F8C197B-3A22-4D3F-90EC-614446329373@robineko.com>
To: <richard.tibbett@orange-ftgroup.com> <richard.tibbett@orange-ftgroup.com>
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
Received on Monday, 28 September 2009 13:05:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:38 UTC