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

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?

Thanks.

Kind regards,
Marcin

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com

-----Original Message-----
From: public-geolocation-request@w3.org [mailto:public-geolocation-request@w3.org] On Behalf Of Andrei Popescu
Sent: Tuesday, June 09, 2009 11:53 AM
To: Lars Erik Bolstad
Cc: public-geolocation
Subject: Re: updated editor's draft of the Geolocation API specification

Hi Lars,

On Mon, Jun 8, 2009 at 10:29 PM, Lars Erik Bolstad<lbolstad@opera.com> wrote:
> But we also have two open issues that should be closed before we go to last
> call:
>
> ISSUE-6: enableHighAccuracy, "Is enableHighAccuracy the right naming for
> this attribute? Should we have it at all?"
> We seemed to have consensus on renaming it, with a few members in favour of
> dropping it completely.
> Allan Thomson proposed to replace it with "reducedPowerHint", along with a
> definition:
> http://lists.w3.org/Archives/Public/public-geolocation/2009Apr/0034.html
> Is anyone against resolving ISSUE-6 by replacing enableHighAccuracy and its
> definition with Allan's proposal?
>
> ISSUE-7: heading & speed, "Should heading & speed be moved out of the
> Coordinates interface?"
> Given that Geolocation API v2 will have support for address, should
> 'heading' and 'speed' attributes be moved out of the Coordinates interface?
> They could go to a separate interface (e.g. Velocity) so that implementation
> can return any combination of (coords, velocity, address).
>
> There hasn't really been any discussion on this issue. Are there any
> objections to moving the "heading" and "speed" attributes out of the
> Coordinates interface and into a new Velocity interface?
>

Given we're about to have a lot of shipped implementations (iPhone,
Firefox, Chrome/Android/Gears, Iris, and others), 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. I realize this is a risk they took when they decided to implement
a draft, but in this case I don't think the two issues are important
enough to justify a compatibility break.

Thanks,
Andrei


________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.

Received on Tuesday, 9 June 2009 10:23:34 UTC