- From: Henning Schulzrinne <hgs@cs.columbia.edu>
- Date: Tue, 10 Mar 2009 10:20:20 -0400
- To: Doug Turner <doug.turner@gmail.com>
- Cc: Alec Berntson <alecb@windows.microsoft.com>, Marc Linsner <mlinsner@cisco.com>, Andrei Popescu <andreip@google.com>, "public-geolocation@w3.org" <public-geolocation@w3.org>
Most cases won't need all the fields, but having them will allow more
applications and avoid the hackery and guestimes I talked about. Just
as an example, having a separate building name field is quite useful
on campus for friend-finder applications ("who is in the same
building?"). In some other cases, we may only have limited precision
(e.g., county-level for IP-address-to-location services). I admit that
I find it hard to believe that somebody doesn't understand "building
name", "floor", "street suffix" or some of the other fields proposed.
The more obscure fields, such as the street branch system, will only
apply regionally, so developers that don't care about Indonesia can
ignore them, but they do make the system capable of handling more than
just US and European addresses.
Henning
On Mar 9, 2009, at 2:44 PM, Doug Turner wrote:
> Hello Henning,
>
> I do not think we have any use cases that require comparing
> addresses for equality. We clearly did not for the v1 addressing
> (coords). I tend to think that civic addressing comparison is out
> of scope. For example, if two UAs pass back an address for the same
> place, I do not think that we should make any guarantees that the
> data the UA pass back to the requesting site is the same. In fact,
> I do not think that the addresses need to be the same between
> different runs of the same UA. The reason for this is that UAs
> might use different back-ends for determining the actual location of
> the UA. Maybe the first geolocation request uses WiFi->location,
> and the second request uses a user defined position, or what have you.
>
> Secondly, we are not designing this API for someone like your or me
> or anyone on this mailing list that can understand thirty+ fields,
> have no problem looking up extensive documentation, and enjoy
> digging through mailing list for rationale on the way things are
> they way they are.. Rather, the API must be designed for the web at
> large. I think we should design the simple-to-use over a can-do-
> everything-everyone-every-wanted address for v2.
>
> Keep in mind, that one could always create a civic address spec that
> leverages the geolocation specification and implementations. For
> example, you could add a separate civicAddress to the position
> object in a future specification.
>
Received on Tuesday, 10 March 2009 14:21:04 UTC