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

Re: DOM based API

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 6 Jun 2008 11:15:42 -0700
Cc: public-geolocation@w3.org
Message-Id: <E9361279-716D-449E-940A-2784108E2D14@apple.com>
To: Doug Schepers <schepers@w3.org>

On Jun 6, 2008, at 10:55 AM, Doug Schepers wrote:

> Hi, Folks-
> (- public-webapi, just to reduce cross-posting)
> Maciej Stachowiak wrote (on 6/6/08 12:58 PM):
>> On Jun 6, 2008, at 7:55 AM, Mark Baker wrote:
>>> On Thu, Jun 5, 2008 at 4:20 PM, Andrei Popescu  
>>> <andreip@google.com> wrote:
>>>> I am interested in working on a specification of a DOM API that  
>>>> allows
>>>> Web pages to access the user's geolocation information (e.g.  
>>>> latitude
>>>> and longitude).
>>> I'm very glad to see somebody mention using the DOM API for this  
>>> kind
>>> of information, right off the bat.  I'm a big believer in reuse, and
>>> feel that this API is an obvious candidate for reusing the DOM, i.e.
>>> providing a "Location" Javascript object that's also a DOM Document.
>> I don't understand why you would want the "Location" object to be a  
>> DOM Document. (It needs a better name, by the way, so it doesn't  
>> conflict with the Location object that is window.location.) And I  
>> don't think that is what Andrei had in mind, as I understand it, he  
>> just wants an API that aligns well with the DOM, not necessarily  
>> one that makes non-markup information appear to be part of a  
>> Document.
> I think I read the idea of hanging it off the Navigator object  
> instead of the Document or Window object, which puzzled me... a  
> request for access comes directly from a particular site, so  
> granting it should apply only to the requesting tab/window.

The navigator object has traditionally been the place to hang  
information and APIs that are not specific to a particular frame or  
document (like UA version info, available plugins, online/offline  
status, etc). But I could see doing it either way.

>> I think presenting geolocation info as a Document would have the  
>> disadvantages of more memory use and less obvious access for authors.
>> What are the advantages?
> I'm not sure I'd count it as an advantage, but there is the way KDDI  
> [1], DoCoMo [2], and (as information) Microformats [3] deals with  
> this in markup.  I'm not suggesting we align around that, more  
> mentioning it for context.


> <off-topic>
> I'm sure it's out of scope for the Geolocation API, but it might be  
> interesting to discuss how location could be codified in markup such  
> that if you found a resource that had a specific location (a web  
> page for a pizza place), a user could find the relation between  
> their current location and that place.  I know, more of a service,  
> but I thought I'd toss it out there.
> </off-topic>
> [1] http://sideshowbarker.net/gps/
> [2] http://www.nttdocomo.co.jp/english/service/imode/make/content/gps/

These both seem to be a way to send location info to a server along  
with an HTTP request (via an HTML extension), not a client-side API.  
There doesn't seem to be a document representation of the location  
info itself, it is just a string sent as an extra request parameter,  
at least in the DoCoMo case.

> [3] http://microformats.org/wiki/geo

Interesting, though I don't think this includes all the info we'd want  
in a geolocation response.

Received on Friday, 6 June 2008 18:16:23 UTC

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