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

Re: skeleton Geolocation API

From: Erik Wilde <dret@berkeley.edu>
Date: Sun, 29 Jun 2008 15:08:56 -0700
Message-ID: <486807F8.6030502@berkeley.edu>
To: public-geolocation@w3c.org
CC: Aaron Boodman <aa@google.com>


Aaron Boodman wrote:
> On Fri, Jun 27, 2008 at 6:24 PM, Erik Wilde <dret@berkeley.edu> wrote:
>> because this is what i am interested in, i think it is not a good idea to
>> have a location API that only focuses on spatial data. if the UA makes a
>> "location fix", the user should have the option to say "at home", and there
>> is not spatial information for that. i believe that the future of the mobile
>> web will depend of this kind of more human-centered application design.
>> on the other hand, i am sure that are many web app developers who simply
>> want to get their hands on that nice GPS data and that's all they want from
>> an API. which is why i think it's important to have use cases and
>> requirements, and to use this as a starting point to develop a location
>> concept.
> The main use cases that caused Google to propose this spec are (and
> have been) listed in the draft (near the bottom):
> http://dev.w3.org/geo/api/spec-source.html

i have seen these. they are a starting point, but i think they have to 
fleshed out substiantially to get to the point where they can provide 
good guidance and actual requirements. and from what i understand, it 
would be within the scope of this (proposed) WG to broaden (or narrow) 
them and come up with requirements derived from these. for example, use 
case 8 (social networking) talks about granularity, but probably just 
means cloaking by reducing accuracy. there are many other (and i think 
better) ways how the goal of that use case could be achieved, and the 
assumption that introducing inaccuracies is the appropriate approach for 
this use case is at least questionable.

> They all revolve around having web apps be able to discover the user's
> lat/lon. The only use case I've hear suggested for the location URI
> idea is that users should be able to manually specify their location.

i did suggest other use cases in earlier emails. if my UA's privacy 
settings allow me to specify to which web sites to expose my lat/long, 
they can also allow me to specify to which web sites to expose the fact 
that i am in california. it is exactly the same model (UA has location 
info, app wants location info), only applied to a place instead of 
coordinates. there really is no conceptual difference.

> The only thing I can see that moving it into the UA would buy is
> having it remembered across apps. If that is the goal, I'd suggest a
> far simpler solution: just standardize on a name for the input box to
> type location information into. Most browsers these days support form
> autofill and that concept can be extended to autofill location as well
> (this probably already occurs with fields called "address" for
> example). At the very most, just define a new <input type="location">
> that renders as a textbox with an autofill dropdown containing
> previously entered values. No new URI scheme required!

there is no fundamental difference between spatial and place locations, 
so if you think autofill solves your problems, you could also just 
define two form fields "lat" and "long" and you're done.

all i am trying to do is to point out that location is an important 
concept to bring to the web. the DOM API will be the first W3C to do it, 
and it really is important to clearly say what the location model should 
be, and why. if there is (sufficient) consensus that locations are only 
spatial and that this is how locations are defined, then this is how 
it's going to be. but i think we have at least some evidence that 
apparently location concepts are not entirely trivial (reference 
systems), may have parts that are not self-evident for everybody 
(bearing, speed), and thus there should be some diligence when deciding 
how web apps will be able to use locations.


Received on Sunday, 29 June 2008 22:09:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:49 UTC