- From: Andrei Popescu <andreip@google.com>
- Date: Thu, 13 Nov 2008 16:39:57 +0000
- To: Richard Barnes <rbarnes@bbn.com>
- Cc: public-geolocation <public-geolocation@w3.org>
Hi Richard,
Thanks for the comments!
On Thu, Nov 13, 2008 at 2:43 PM, Richard Barnes <rbarnes@bbn.com> wrote:
>
>
> As a suggestion, I'll again refer to the structure that I posited in another
> thread, where geodetic position is one component of a richer Position
> object. v1 might define a simple structure:
> interface Position {
> readonly attribute Geodetic geodetic;
> }
> interface Geodetic {
> // lat/long/altitude etc.
> }
>
I can see why grouping lat/long into a separate interface would appear
nicer but that will be at the expense of the developers who will find
that using the Position object is now more cumbersome. IMHO, that's
not a good trade-off. I think it's better to leave the Position
interface as is and just add an 'address' attribute to it. This would
allow developers to easily test whether an implementation supports
addresses (simply test that attribute for a null value). Note that a
similar test would not be needed on your suggested 'geodetic'
attribute, since all implementations are guaranteed to support
lat/long coordinates.
> interface Position {
> readonly attribute Civic civic;
If by 'Civic' you mean address, then I agree that that placing it on
the Position interface is the right thing to do. So, as far as
extensibility goes, I think we agree. I am not sure about the naming,
as 'civic' seems to be something pertaining to a city. Anyway, that's
a discussion for v2.
Thanks,
Andrei
Received on Thursday, 13 November 2008 16:40:36 UTC