RE: ISSUE-5: Application Configuration API

I agree with Robin, and can support an editor role for such an umbrella document. I expect it would be short, not much more than a guide to the current documents that form the work plan and how it has changed over time (key aspects only, like AppConfig).

Best regards,
Bryan Sullivan | AT&T
-----Original Message-----
From: Robin Berjon [mailto:robin@robineko.com] 
Sent: Monday, September 28, 2009 6:24 AM
To: <richard.tibbett@orange-ftgroup.com>
Cc: SULLIVAN, BRYAN L (ATTCINW); public-device-apis@w3.org
Subject: Re: ISSUE-5: Application Configuration API

Hi,

I think we're getting ahead of ourselves here, and devolving into  
process clutter when we should be geeking over the APIs.

On Sep 23, 2009, at 18:30 , <richard.tibbett@orange-ftgroup.com> <richard.tibbett@orange-ftgroup.com 
 > wrote:
> Agreed we need a note if we drop things from our charter. The same  
> would be true if our charter needed to grow at any point (e.g. if we  
> decided we need to add additional APIs in the future).
>
> We should therefore have a process for dealing with both of these  
> events as this problem could crop up again. My understanding of W3C  
> process is that a charter can be changed with membership consent but  
> I would be interested in clarification.
>
> Anyway, failing a straightforward change to the charter, there are a  
> few other options for including the required note. Such as:
>
> - an addendum to the charter (though perhaps this would be subject  
> to the same rules as changing the charter itself?).
> - a DAP Primer/Introduction W3C Note (as suggested by Bryan and  
> Kangchan on the call)
> - an 'empty' App Config API spec with the following words: 'The  
> Application Configuration API was not addressed as detailed in the  
> W3C DAP charter because...'
>
> My preference would be to change the charter directly if at all  
> possible or include the note as an addendum to the existing charter.

I don't think that we need a process to handle modification to our  
deliverables. If deliverables are added, that requires a charter  
change anyway, and the process for that is already in place. If we  
decide to drop one deliverable, as happened here, we have no  
obligation other than to document it.

Changing the charter is a costly process since it needs large review.  
It can also fail if there is opposition in the membership. Let us not  
overestimate the number of people who read charters. The majority of  
the people whom we'd like to see use our technology never read  
specifications, of those who do only very few know what a charter is,  
of those fewer still bother to read it, and amongst the charter  
readers not all care about what it says.

Our primary constituencies are developers and implementers here.  
Neither will ever notice that we've dropped AppConfig because they  
know it's already available through Web Storage or TWI. I think the  
information will somewhat register on the radars of some standards  
bodies who are tracking this, but I would expect barely. BONDI had  
already discussed dropping this, so they'll know why for instance.

An empty AppConfig specification won't help much either - I can't  
think of a case in which someone would actually go and see it.

So I'd think that simply putting a paragraph in the umbrella  
requirements document (if there's consensus on that) should do the  
trick. Anything more is make-work IMHO.

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

Received on Monday, 28 September 2009 13:40:52 UTC