RE: ISSUE-5: Application Configuration API

Thanks for the clarification. It makes sense. The concensus is to create
an umbrella requirements document and I'm happy with that.

Now let's geek over some APIs :-)

br/ Richard

> -----Original Message-----
> From: Robin Berjon [mailto:robin@robineko.com] 
> Sent: 28 September 2009 14:24
> To: TIBBETT Richard RD-ILAB-LON
> Cc: BS3131@att.com; 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:44:12 UTC