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

It seems like there's a subtext here that "We have UAs that implement 
version $X of the spec, therefore version $X must be the final spec," 
even though there are still open issues with version $X.  While it's 
great that there are implementations, it's not so nice when 
implementations force things in or out of a consensus document.

I wonder if a more productive line of thinking might be to consider the 
current implementations as conforming to the *draft* Geolocation API, 
much like WiFi APs have been "Draft-N" for a while in anticipation of 
that standard.  That would give us the chance to work out some of these 
"V2" issues in the first rev.

The alternative, of course, is to explicitly agree that V1 is just going 
to be a documentation of what implementations are doing now, and reserve 
"what we really have consensus on" for V2.

--Richard



Lars Erik Bolstad wrote:
> Andrei Popescu wrote:
>> 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
>>   
> I agree. And you can add Opera to that list, btw :-)
> 
> Lars Erik
> 
> 
>

Received on Tuesday, 9 June 2009 18:19:55 UTC