W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2009

Re: ISSUE-14: Gathering requirements [System Info & Events]

From: Max Froumentin <maxfro@opera.com>
Date: Mon, 5 Oct 2009 11:33:14 +0200
Cc: "Tran, Dzung D" <dzung.d.tran@intel.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-Id: <F404F278-91A4-46DF-9E12-587DBE9B3136@opera.com>
To: Robin Berjon <robin@robineko.com>

On 5 Oct 2009, at 11:15, Robin Berjon wrote:

> On Oct 4, 2009, at 17:27 , Tran, Dzung D wrote:
>>>> -       Compass
>>> As in the existence or absence of a Compass device, right? But not
>>> providing a heading, since that would overlap the geolocation
>>> specification.
>>> If that's right, then add: Geolocation device
>> Providing access to Geolocation information via the System Info &  
>> Events API is logical, although it would be duplicitous.
> I think that what Max meant here was that the SIE would expose  
> whether geolocation and compass capabilities are present, not the  
> actual information.


>> I'm not sure the Geolocation API has in mind the use case where  
>> orientation info comes from a compass rather than being  
>> extrapolated over time from GPS coordinates.

The geo API is agnostic about the device that provides geolocation,  
and will just report one value for "heading", which it is up to the  
implementation to figure out.

>> If we choose to provide compass data via the Geolocation API, it  
>> should have an orientation Use Case and an orientation Requirement  
>> added, e.g. requirement 6.2.4 should be modified to read: " The  
>> Geolocation API MUST allow an application to register to receive  
>> updates when >>either the position or the heading<< of the hosting  
>> device changes."

So maybe the geolocation specification should be refined, specifically  
the statement below to make it clear the position includes heading,  
and even speed.
"[watchPosition] then must continue to monitor the position of the  
device and invoke the appropriate callback every time this position  

Received on Monday, 5 October 2009 09:33:50 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:39 UTC