Re: Coordination on Address interfaces

On Fri, 01 Jul 2011 13:34:31 +0200, Lars Erik Bolstad <lbolstad@opera.com>  
wrote:

> 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.

Certainly. From the perspective of getting developers not to make  
mistakes, I think it is worth putting some work into it. Otherwise what  
we'll get when we ship this to the world is developers who assumed that  
what they knew from one API applied to the other, and we'll have to do a  
post-hoc merge, which is possibly more painful.

>>> 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.

Hmm. Both geolocation and contacts have an attribute  
(formatted/additionalInfo) that seems intended to allow that to be dropped  
in, and I think it's an important piece to retain (and should be easy  
enough to unify the attribute names).

>> 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.

Yeah, I think that's a hard constraint that we should maintain.

One possible approach, where there are strict and lossy ways of describing  
part of a location, is to have an attribute for the strict one and another  
for the lossy one. Converting from a strict value to *a* lossy value is  
easy, although the reverse isn't true. So you for example we could add  
"ISOCountryCode" as an attribute.

> 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.

Yep, and we should get that right. The tricky bit is in working out what  
the right balance is between enabling systems that understand more  
powerful data models to include that. Perhaps some kind of extension  
mechanism, or a "metadata" attribute that expects machine-readable data of  
some kind, would be helpful.

After all, I live at an address in Norway that is precisely identified by  
a formal address, but I don't actually know it to that level of detail -  
so what I give to someone as an address won't be automatically matchable  
to the same level of detail as what the immigration department tells the  
tax department.

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Friday, 1 July 2011 16:01:57 UTC