- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 13 Nov 2008 23:47:44 +0000 (UTC)
- To: Erik Wilde <dret@berkeley.edu>
- Cc: Doug Turner <doug.turner@gmail.com>, "Thomson, Martin" <Martin.Thomson@andrew.com>, Andrei Popescu <andreip@google.com>, Richard Barnes <rbarnes@bbn.com>, public-geolocation <public-geolocation@w3.org>
On Thu, 13 Nov 2008, Erik Wilde wrote: > > instead of accepting valid scenarios where people say that they want to > use non-lat/long positions and this is how things are working now, this > argument asks them to use lat/long because that's how the API works. but > aren't we in a discussion about what people have as use cases and > scenarios for that API and what it should support? No, we're months past that discussion. As I've said before, there are certainly use cases for getting a postal address for the user. I'm not personally convinced that they need an API (we seem to do fine today with form fields); and I'm definitely not convinced that this API, which is optimised for a frequently changing location, should have anything to do with it. But irrespective of that, it belongs in a separate spec, if it belongs anywhere at all -- either a v2 of this spec, or another one altogether. Instead of arguing over and over about whether Geolocation v1 should have this, the people who want addresses in an API should write a separate specification optimised for those use cases. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 13 November 2008 23:48:20 UTC