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

RE: ISSUE-14: Gathering requirements [System Info & Events]

From: David Rogers <david.rogers@omtp.org>
Date: Wed, 14 Oct 2009 12:52:38 +0100
Message-ID: <4C83800CE03F754ABA6BA928A6D94A0601DD5438@exch-be14.exchange.local>
To: "Robin Berjon" <robin@robineko.com>
Cc: <public-device-apis@w3.org>
Hi Robin,

Your comments about prioritisation conflict with the discussion on the
16th of September about prioritisation of APIs[1].

Let's approach this in an orderly fashion otherwise this group will not
get anything done. We have a clear list of inputs, so get those
delivered as per the preferences stated in [1] and concentrate on the
nice-to-haves as a secondary objective. We also need guidance from legal
about IPR. 

I do not believe we have consensus on a way forward for sensors.
Clearly, there is a lot of thinking to be done rather than just piling
into designing an API that could well be redundant within a year because
it addresses a use-case which is too narrow. Sensors is a huge subject.

Thanks,


David.

[1]
http://lists.w3.org/Archives/Public/public-device-apis/2009Sep/0050.html


-----Original Message-----
From: Robin Berjon [mailto:robin@robineko.com] 
Sent: 13 October 2009 16:07
To: David Rogers
Cc: public-device-apis@w3.org
Subject: Re: ISSUE-14: Gathering requirements [System Info & Events]

Hi,

On Oct 9, 2009, at 16:24 , David Rogers wrote:
> Chairs, please could you give some direction on the next steps? I'm  
> concerned that a lot of parallel activities are going to start, then  
> stall.

I'm not a big fan of top-down prioritisation. Consider the case in  
which the WG decides (all other things being equal) to prioritise APIs  
for Unicorn Control and Pony Training, but there's a smaller handful  
of people who are only (or mostly) interested in the Shiny Donkey API.  
It seems unproductive to keep them from working on it.

We have tools to deal with that. First of all we can simply let that  
group work on it, conducting its business on list, and taking a slice  
(but not the majority) of the agenda. If it stalls, the WG can either  
decide that it was a good idea to prioritise it anyway and redeploy  
resources, or figure out that we'll get to it as originally planned.

If the volume of work on Shiny Donkey becomes overwhelming, then  
obviously it's not stalling, but we can run into a situation in which  
it is taking too much of the WG's bandwidth. For that we have Task  
Forces, which we (the chairs) can charter at will. TFs can have their  
own phone (and even f2f) meetings, their own list, their own  
(informal, delegated) chairs. It's not ideal in that it tends to split  
the WG somewhat, but sometimes WGs are split de facto, and since the  
situation has cropped up before there is a body of experience in  
handling it.

What concerns me is that we seem to be spending more time going meta  
than actually putting MUSTs and NOTs into HTML specifications.

I think I would summarise the direction in which I'd like us to go as  
follows:

   - The WG has a scope, outlined in the charter, outside of which we  
won't go.
   - The WG has priorities, but won't stand in the way of people  
wanting to get work done.
   - v1 specifications need to be as simple as they can be, and v2  
needs to be thought about.
   - People need to have read
http://www.w3.org/TR/html-design-principles/
   - In addition, Java has very clearly demonstrated that theoretical  
straightjackets don't produce quality APIs. Primary concerns in API  
design (in addition to those listed in the HTML DP) are therefore:
     . Vernacular (grown around usage)
     . Idiomatic (fits in the language and the way in which it is used)
     . Ergonomic (looking at it should tell me what it does, i.e.  
unlike Node.insertBefore())
   - Consistency is less important than the three previous aspects,  
but usually flows from applying them.

Finally, code speaks louder than words and solutions louder than  
principles. We can agree on a zillion and one a priori top-down ways  
in which work should be conducted, if six months down the line we have  
the choice between a solution that sticks to them, and a better  
solution that breaks them, we'll have no option other than to break  
them. So, given that we're aware of all the exiting input, why not  
just build the good solution based on that experience that we're  
chartered to build?

The CVS repository is open to all WG participants, and HTML is  
reasonably straightforward to handle (at least, it should be for  
people working in this WG!). People are always welcome as editors, and  
editors are always welcome to dump their brains in there so that we  
can pick them apart.

--
Robin Berjon
   robineko - setting new standards
   http://robineko.com/
Received on Wednesday, 14 October 2009 11:53:34 UTC

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