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

+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