Re: Forward/backward compatibility

Hi Andrei

> I think it's better to leave the Position
> interface as is and just add an 'address' attribute to it. 
> ... since all implementations are guaranteed to support
> lat/long coordinates.

That assumption -- that all UAs have lat/long -- shows up all over this 
list, and I don't know where it comes from, unless it's a deliberate 
limitation on the scope of the API.

There are many examples of location providers that don't naturally 
provide a lat/long, but can do pretty well with civic information.  Some 
random examples:
-- A fixed-line ISP that has a database of service addresses that they 
offer as a location provider
-- An enterprise network that hands out location down to the floor and 
cubicle number
-- An IP-based geolocation service that is reasonably accurate to the 
metro-area level, but not down to a point (see [1],[2])
The best a lat/long will do in these cases is get to the front of the 
building; at worst, it'll be geocoded into something meaningless.

So I would be much more comfortable if a geodetic location were optional 
(at least in v2), since there are deployments were it would be 
detrimental (inaccurate and unnecessarily complex) to add geodetic 
location.  I'm not sure how do go from a geodetic-only API to one where 
geodetic is optional in a backwards-compatible fashion.

[1] <https://addons.mozilla.org/en-US/firefox/addon/9534/>
[2] <http://www.maxmind.com/app/ip-location>


>> 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.

As I understand it, the name "civic location" or "civic address" (in 
contrast to "geodetic location") has fairly wide, standard usage in 
communities that deal heavily with location.  For example, the emergency 
services community (9-1-1 / 1-1-2).

Cheers,
--Richard

Received on Thursday, 13 November 2008 19:40:15 UTC