Coordination on Address interfaces

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 15:37:35 UTC