- From: Lars Erik Bolstad <lbolstad@opera.com>
- Date: Fri, 01 Jul 2011 13:34:31 +0200
- To: Robin Berjon <robin@berjon.com>
- CC: Doug Turner <doug.turner@gmail.com>, public-geolocation@w3.org, public-device-apis@w3.org
On 26.05.2011 12:03, Robin Berjon wrote: > Hi Doug, > > On May 25, 2011, at 18:48 , Doug Turner wrote: >> I'd like to avoid option A, but also would like to see the >> |address| object that geolocation uses be more or less compatible >> with the one contacts uses. Given the few exceptions you listed, I >> don't see any reason not to just use your judgement and move >> ahead. > > If you think that alignment is preferable, I certainly see no reason > to object to it. To state my preference in less jocular terms, I > don't think that alignment is necessary, but of course if it's easily > reached then it's certainly nice to have. > >> Btw, we considered using the IETF Civic Address. It has a crazy >> huge address structure and can represent just about any location on >> earth. We looked closely at this and decided that exposing this >> structure as-is to the web would basically just cause developer >> pain. Instead, we decided to just use a simpler 'mailing address' >> structure. > > Yeah, I think that IETF Civic Addresses are intended for more complex > systems such as postal services backends. I doubt that we need > anything like that. > > What we did was look at vCard, PoCo, and OMA CAB, spoke to the people > behind those efforts, and found a set of properties that seemed to > make everyone happy enough while remaining reasonable in scope. > > If we're looking at alignment, which parts do you think are most > important? The easy one is |city| -> |locality|. The most useful > ones are probably having DAP's |country| be an ISO code and adding > |formatted| to Geo but this may run into implementability issues. DAP > has to rely on underlying address book implementations, some of which > don't normalise countries, and Geo services may not be able to > provide formatting given the vast international variations (I'm > guessing, at least). For the other fields, a constraining factor for > DAP would also be losing compatibility with PoCo/vCard/CAB since > those are the underlying models that we need to interface with. > It would be good if we could align the Address interfaces as much as possible while still taking our different use cases into account. It should be trivial to rename attributes to be the same at least. Lars Erik
Received on Friday, 1 July 2011 11:35:04 UTC