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

Re: updated editor's draft of the Geolocation API specification

From: Andrei Popescu <andreip@google.com>
Date: Tue, 9 Jun 2009 11:44:00 +0100
Message-ID: <708552fb0906090344t419d320awe3cb6e287c94f740@mail.gmail.com>
To: Marcin Hanclik <Marcin.Hanclik@access-company.com>
Cc: Lars Erik Bolstad <lbolstad@opera.com>, public-geolocation <public-geolocation@w3.org>
On Tue, Jun 9, 2009 at 11:22 AM, Marcin
Hanclik<Marcin.Hanclik@access-company.com> wrote:
> Hi Andrei,
>
>>>I would like to propose we keep the spec as it is and move these issues to V2. Since
>>>we're talking about renaming a boolean and moving two attributes to a
>>>new interface, I think we can safely live with what we have and avoid
>>>making all these implementations incompatible from the day they come
>>>out.
> There seem to be plans to modify the "existing" interfaces in V2, as above.
>
> http://dev.w3.org/geo/api/spec-source.html states:
> "Future versions of the API may allow additional attributes that provide other information about this position (e.g. street addresses)."
> I.e. monotonic growth of the spec is assumed.
>
> My question:
> Let's imagine we are now post-V2:
> Is there already any way planned for a potential JS developer to discover the interface that is actually implemented and shall be used without the need to check for all the potential attributes?
>

I think the established way of doing that is the DOM hasFeature() API:

http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-102161490

I am not sure but I think this requires us to define a "feature
string" like "org.w3.dom.geolocation". The developer can just query
the implementation using "hasFeature("org.w3.dom.geolocation",
"2.0");".

Another way would be to add a "version" string attribute to the
Geolocation iface. What do you think?

Thanks,
Andrei
Received on Tuesday, 9 June 2009 10:44:38 UTC

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