Editors, Requirements, Style, etc.

Hi,

while this WG will only get into full swing closer to the end of  
August when people are back from vacation, we should try to get a  
number of things out of the way earlier so we don't get bogged down in  
administrativia later.

First of all, I should make it clear that this WG will operate more or  
less with two hemispheres: API and Policy. I won't take the brain  
metaphor too far lest we fall into Starship Troppers references too  
fast, but the two are linked and communicate but can also operate  
independently (so that if you're only interested in one side, you  
don't have to sift through too much crud from the other).

Frederick is handling the Policy side, while I'll do APIs. That being  
said if you need to talk to the chairs about something, please copy  
both of us as we intend to be able to cover for each other's side.

The rest of this email is largely about the API side of things, though  
should it inspire you to talk about Policies by all means go ahead.

There are quite a few APIs that we need to specify, and it would be  
nice (to say the least) if they had some form of coherence. As a  
result, the plan for the API specifications is that rather than having  
one or two editors per API, we have a pool of editors for all of them.  
So far the following have heroically volunteered:

   Daniel Coloma, Telefónica de España
   Marcin Hanclik, Access
   myself

If you have objections to these people editing, please voice them now  
or forever keep them in your drafts folder.

We very much welcome other volunteers — we'll need a fair amount of  
editing power to get all those documents out in time. The pool will be  
kept up to date at: http://www.w3.org/2009/dap/editor-pool.html.

Where the specifications are concerned, we've already had an  
interesting thread covering some of the difference between the Nokia  
and BONDI APIs. I wonder if it might not be simpler to list the  
requirements that led to the creation of these APIs, alongside other  
requirements that people may have? It would help define an target to  
be met (and features to be pushed off to future versions) for these  
specifications.

Finally I would like all of you to think about API style (e.g. the way  
in which arguments are passed) ahead of starting, and invite anyone  
with a strong opinion on the matter to post about it now.

Thanks!

--
Robin Berjon
   robineko — setting new standards
   http://robineko.com/

Received on Tuesday, 4 August 2009 14:28:35 UTC