- From: Andrei Popescu <andreip@google.com>
- Date: Fri, 6 Mar 2009 13:49:58 +0000
- To: Charles McCathieNevile <chaals@opera.com>
- Cc: Ian Hickson <ian@hixie.ch>, "public-geolocation@w3.org" <public-geolocation@w3.org>
Hi Charles, On Wed, Mar 4, 2009 at 8:42 AM, Charles McCathieNevile <chaals@opera.com> wrote: > > So this comes back to the use cases and requirements. If being able to > compare addresses and make useful inferences matters, then it is important > to split out the semantics, with the level of detail determining how far > down the semantic split should go. Otherwise, you are right that it is not > really important. > I think you're absolutely right, this is the issue. We could go down the route of splitting semantics in such a way that the address format has a field dedicated to every particularity of any address on Earth and satisfy all use cases from here to eternity. Or we could have a slightly more pragmatic approach of drawing the line at a level of detail that we deem reasonable in terms of complexity (i.e. easy to understand by developers and capable of satisfying the use cases we now have in the document). If we're careful to design the API in an extensible manner, we can act on feedback from application developers and API implementers and extend the format based on their needs. To me, this latter approach is the one that we should take: start from from rfc 4119 and simplify it (i.e. coalesce some fields and give them humanly understandable names) as I proposed. This yields a solution that is also reasonably close to what Microsoft has in products that ship pretty much everywhere, which is rather reassuring to me. Thanks, Andrei
Received on Friday, 6 March 2009 13:50:37 UTC