W3C home > Mailing lists > Public > public-device-apis@w3.org > May 2011

Re: Coordination on Address interfaces

From: Doug Turner <doug.turner@gmail.com>
Date: Wed, 25 May 2011 09:48:14 -0700
Message-ID: <BANLkTiki5CODZjWV7+=6=junHhVM2U56BA@mail.gmail.com>
To: Robin Berjon <robin@berjon.com>
Cc: public-geolocation@w3.org, public-device-apis@w3.org
Hi Robin,

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.

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.

Doug


On Wed, May 25, 2011 at 8:35 AM, Robin Berjon <robin@berjon.com> wrote:
> Dearest Geolocation Working Group,
>
> as you may know, the Device APIs WG has been working on an API to expose address book information, the Contacts API:
>
>    http://dev.w3.org/2009/dap/contacts/
>
> The group is of the opinion that all issues with this specification have been addressed, and as a result, barring any strong comment to the contrary, we are planning on moving this draft to Last Call next week.
>
> It so happens however that there is an aspect about which we need to coordinate with you: the Address interface. The one used in Geolocation v2 is indeed different from the one used in Contacts:
>
>    http://dev.w3.org/geo/api/spec-source-v2.html#address_interface
>    http://dev.w3.org/2009/dap/contacts/#contactaddress-interface
>
> The differences are:
>
>    • Only Contacts has pref, type, and formatted. This is probably an acceptable difference.
>    • In Contacts country is the name of the country, whereas in Geo it's the ISO code. I like the latter much better, but I wonder how workable it is for common address book databases (where the user often enters the country in text).
>    • Only Geo has county, premises, additionalInformation. I wonder how much this difference matters.
>    • Geo has street and streetNumber where Contacts has streetAddress. I think that this reflects the differences in usage.
>    • Contacts calls locality what Geo calls city. All the names in Contacts are derived from Portable Contacts.
>
> There are several ways to approach these differences:
>
>    OPTION A — We decide that they're important and that we should align, start long cross-posted discussions about naming and use cases that start out politely but promptly degenerate into a generalised bloodbath, have a conciliation joint meeting at which out of exhaustion we decide that everyone is right, pile all of the alternatives onto the same interface, and produce a monster that no one can implement or understand, which doesn't matter anyway since in the time it took to reach consensus the web has been displaced by a gigantic app store.
>
>    OPTION B — We agree that, while the underlying physical information may be the same for both cases (i.e. addresses), actually modelling the type of information returned by a geolocation civic addresses service and entered by users into their personal database of contacts produces different results and addresses (no pun intended) different use cases.
>
> On balance, I have a (personal) preference for option B. I think that our use cases are different and that the nature of the data which we expose is different. I also think that the Javascript required to convert between both won't tax anyone's axons.
>
> So the conclusion of this coordination email is that I think we shouldn't coordinate. Of course, that's a decision that I'd like to make sure everyone is comfortable with — hence the coordination.
>
> Thoughts?
>
> --
> Robin Berjon - http://berjon.com/
>
>
>
>
>
Received on Wednesday, 25 May 2011 16:49:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:20 GMT