W3C home > Mailing lists > Public > public-webapi@w3.org > June 2008

Re: Dedicated Geolocation List and Channel

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 3 Jun 2008 10:53:35 -0700
Cc: Web API public <public-webapi@w3.org>, Ian Hickson <ian@hixie.ch>
Message-Id: <4EE49419-975E-48E8-8E39-B9A275C97C96@apple.com>
To: Doug Schepers <schepers@w3.org>

At this point I am really confused about where to discuss geolocation  
APIs, and I would rather not have it bounce back and forth. Maybe we  
should just wait until the chartering process reaches its conclusion.


On Jun 3, 2008, at 7:24 AM, Doug Schepers wrote:

> Hi, Ian-
> Ian Hickson wrote (on 6/3/08 6:04 AM):
>> On Mon, 2 Jun 2008, Doug Schepers wrote:
>>> Matt Womer and I have started a new email list for discussing  
>>> geolocation. The new list, public-geolocation [1], will be  
>>> archived, and the intent is for it to be the public list for the  
>>> planned Geolocation WG:
>>>  http://lists.w3.org/Archives/Public/public-geolocation/
>> Could we please keep the discussion to this group? It seems like  
>> most people on this group agree that the work should happen in this  
>> group,  and it would be very confusing to have to move stuff back  
>> and forth, especially if the charter proposal for geo fails, as  
>> seems likely given several browser vendors have requested that it  
>> stay in this group.
> I appreciate that sentiment, and I see the browser vendors as a  
> vital constituency in a successful Geolocation API specification.   
> However, they are not the only stakeholders.
> To make this a truly open and universal API with broad uptake, we  
> want to cultivate the participation of other industries in addition  
> to browser vendors; camera manufacturers, GPS vendors, car makers,  
> mobile phone operators, other standards bodies, etc.  While some of  
> them may have no direct interest in an API, they are likely to have  
> insight into other aspects of geolocation that will inform an  
> effective API.  Many of them have shown interest in this in the past.
> From an IPR perspective, in order for a large company (or other  
> organization) to get involved in the WG, they would have to do a  
> wide-ranging (and lengthy and expensive) patent search.  To join the  
> WG, the company's patent search would have to cover *everything*  
> that the WebApps WG is doing, not just geolocation.  As you know,  
> geolocation itself is a very mature technology, and there are  
> hundreds of patents regarding its minutiae; if it turns out that the  
> work we do ends up being contentious and spawning a PAG (Patent  
> Advisory Group), it is better that it be isolated and not slow down  
> the work going on in the rest of the WebApps WG.
> In addition to this, the vast majority of topics and emails on this  
> list will not concern these other folks at all; it is rather  
> overwhelming to get involved in such a high-traffic (and frankly  
> contentious) list, especially if you aren't already in Web standards  
> culture.
> So, regardless of where the actual deliverable ends up, it is  
> therefore better to have a dedicated mailing list, for exactly the  
> reason you state: it's confusing to have it move around, and keeping  
> it on one list devoted to the topic will be much easier to track.   
> If it happens that the Geolocation WG chartering fails, then the  
> list can simply be attached to the WebApps WG.  Easy.
> There is no additional burden on the WebApps WG participants to  
> subscribe to one more list (or join one more WG), and there is a  
> substantial burden on other interested parties in monitoring the  
> public WebApps list.  Seems like a clear choice to me.
> So, I'd respectfully ask that geolocation topics be conducted on  
> public-geolocation, rather than slowing down the technical  
> discussion by debating where we should be doing the work.
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG, CDF, and WebAPI
Received on Tuesday, 3 June 2008 17:54:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:27 UTC