Re: Seeking feedback on a new WG to specify APIs for device services

Philippe --
Good points all.

Assuming that "if it must be done, then it must be done at the
W3C" with respect to the APIs work, could you help the membership
understand the following with respect to resourcing -- staff
resources, chair resources etc with  for (A) and (B) below: 

A) The work is added to WebAPI WG
B) The work is started under a new WG.

Assuming that bean-c0ounting apart, the work to  be done remains
the same, it would be nice to understand the above when
evaluating pros and cons.

Philippe Le Hegaret writes:
 > > 1. While we welcome Nokia's "straw person" proposals as starting
 > > points (and the royalty-free declarations on patents that accompany
 > > the straw persons), we continue to be uncomfortable that a _new_ WG
 > > is coined for the purpose of creating APIs exposed to scripting
 > > contexts on the web.
 > 
 > I don't think there is a clear cut explanation of why a brand new WG
 > is necessary. Let me list some concerns that could be raised if we do
 > this in WebApps:
 > 
 > - load on Chairs and Team contacts. Those folks are expected to know
 >   what's going on in the Group. Are we just expecting to take on the
 >   extra work?
 > 
 > - IP scope. The more we'll go into APIs that are heavily used in the
 >   mobile market, the more likely it will raise concerns over patent
 >   portfolios. This might not be a concern for Mozilla but I wouldn't
 >   like to have to participate in 2 or 3 PAGs for WebApps (as a
 >   reminder, we already have one). Of course, a counter argument would
 >   be that it's better to face those issues now, but it will make my
 >   first point about workload even stronger.
 > 
 > - Where do we stop? Should we put a boundary to the set of Web APIs
 >   developed in the WebApps Group? This is not the first request that
 >   I'm getting to add more APIs into that Group. We already have 23
 >   deliverables in that Group. Some of them haven't been updated since
 >   April 2006, like the Window object specification.
 > 
 > Don't get me wrong. I do believe that the APIs submitted by Nokia
 > provided some important functionalities and we shouldn't wait several
 > months before starting an effort on them.
 > 
 > > 2. Again, while we have concern that a new WG is required, we also
 > > have concern that charter approvals for extensions to an existing
 > > activity's scope take far too long. In practice, I have not seen
 > > evidence that proposing new topics for exploration within a healthy
 > > space (such as Web Apps) works efficiently.  This is distressing to
 > > see; I'd like commentary about why this is, and what can be done to
 > > expedite this.  I am particularly concerned that it may prove faster
 > > to coin a new WG than approve a charter amendment to an existing WG.
 > > Why is this?
 > 
 > Part of today's problem is that we don't do charter amendment. For
 > example, to add Web Workers into the set of deliverables of WebApps, we
 > had to get a complete charter to the AC for review. It triggered
 > comments that were not related to that particular addition but on other
 > aspects, like CORS or Widgets. It may make things easier if we don't
 > have to review the entire charter in order to add an additional
 > deliverables but, as usual, there are some pros and cons to the
 > approach. As Art pointed out, part of the discussion happens prior to
 > the AC review. In the case of the device APIs, one of the issues is
 > indeed about whether it should be into WebApps or not. My position is
 > that it can only be there if we increase Chairs and Team contacts
 > resources at the minimum. Dominique Haza$(ÿ > on device APIs at the moment. We're still certainly interested in
 > feedback in any case.
 > 
 > Philippe
 > 
 > 

-- 
Best Regards,
--raman

Title:  Research Scientist      
Email:  raman@google.com
WWW:    http://emacspeak.sf.net/raman/
Google: tv+raman 
GTalk:  raman@google.com, tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc

Received on Tuesday, 5 May 2009 17:09:30 UTC