Re: Coordination on Address interfaces

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.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Thursday, 26 May 2011 10:04:36 UTC