W3C home > Mailing lists > Public > public-geolocation@w3.org > March 2009

RE: Geolication API level 2 - editor's draft

From: Allan Thomson (althomso) <althomso@cisco.com>
Date: Mon, 30 Mar 2009 08:59:03 -0700
Message-ID: <18B307BFDE5098438B0BF42A4E508FB508156B61@xmb-sjc-228.amer.cisco.com>
To: "Andrei Popescu" <andreip@google.com>, "public-geolocation" <public-geolocation@w3.org>
Andrei - Thanks for putting this document together.

I have many comments on this draft document and rather than posting
individual comments without context I've added my comments to a single
Word document at the relevant sections. It is attached.

Let me know if you have a problem with this style of comment posting.


Allan Thomson
Cisco Systems

-----Original Message-----
From: public-geolocation-request@w3.org
[mailto:public-geolocation-request@w3.org] On Behalf Of Andrei Popescu
Sent: Monday, March 16, 2009 9:50 AM
To: public-geolocation
Subject: Geolication API level 2 - editor's draft


I have uploaded the first editor's draft for the Geolocation API v2
(or level 2):


The main change is the addition of the Address interface. Following
the evidence presented in the thread at


I concluded that the scheme based on a simplified RFC4119 is the best
choice so far. It is also reasonably close to the proposal made by
Alec Berntson.

One thing we have not discussed is the extension to the
PositionOptions interface. Alec proposed something similar to the

interface PositionOptions {
  const unsigned short COORDS_REQUIRED = 0;  // default
  const unsigned short ADDRESS_REQUIRED = 1;
  const unsigned short EITHER = 2;
  readonly unsigned short positionType;


COORDS_ONLY = The API only returns position objects when coords has
data, address can be null
ADDRESS_ONLY = The API only returns position objects when address has
data, coords can be null
EITHER = The API returns a position object whenever there is data for
either address or coords data.

Should we also have BOTH_REQUIRED as a fourth option?


Received on Monday, 30 March 2009 16:00:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:54 UTC