Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide access to address properties #12

Closed
petele opened this issue Mar 4, 2019 · 8 comments
Closed

Provide access to address properties #12

petele opened this issue Mar 4, 2019 · 8 comments

Comments

@petele
Copy link

petele commented Mar 4, 2019

The contacts picker API should allow access to the address properties of a contact.

Use case: shipping a gift to a friend when buying something.

@rayankans
Copy link
Collaborator

I don't think this is an achievable use case, considering how inconsistent addresses are in their representation. This applies to both sides: the source of the contact information and the destination service.

The spec would have to go into a lot of details around how to exactly format/represent the address, which is not feasible.

@aarongustafson
Copy link

@rayankans What would you think about returning all address-related fields (or blocks) as a single string, allowing the recipient of the data to break it apart (or not)?

@tomayac
Copy link

tomayac commented Apr 5, 2019

What would you think about returning all address-related fields (or blocks) as a single string, allowing the recipient of the data to break it apart (or not)?

The vCard standard is there to help solve this problem. Example (source):

BEGIN:VCARD
VERSION:4.0
N:Gump;Forrest;;Mr.;
FN:Forrest Gump
ORG:Bubba Gump Shrimp Co.
TITLE:Shrimp Man
PHOTO;MEDIATYPE=image/gif:http://www.example.com/dir_photos/my_photo.gif
TEL;TYPE=work,voice;VALUE=uri:tel:+1-111-555-1212
TEL;TYPE=home,voice;VALUE=uri:tel:+1-404-555-1212
ADR;TYPE=WORK;PREF=1;LABEL="100 Waters Edge\nBaytown\, LA 30314\nUnited States of America":;;100 Waters Edge;Baytown;LA;30314;United States of America
ADR;TYPE=HOME;LABEL="42 Plantation St.\nBaytown\, LA 30314\nUnited States of America":;;42 Plantation St.;Baytown;LA;30314;United States of America
EMAIL:[email protected]
REV:20080424T195243Z
x-qq:21588891
END:VCARD

Especially noteworthy therein the 📍 ADR, that also includes a 🏷 LABEL parameter that is meant for a written address, so you could get both the individual fields as structured data, as well as information what and how you'd need to write the address on a package. Example:

ADR;TYPE=home;LABEL="123 Main St\nNew York, NY 12345":;;123 Main St;New York;NY;12345;USA

From the LABEL you know you have to write the address like so on a package…

123 Main St
New York, NY 12345

…and the rest tells you the structured fields for your address database…

street address: 123 Main St
locality: New York
region: NY
postal code: 12345
country name: USA

🎉 Both iOS as well as Android use vCard when you share a contact from the particular native Contact app.

@rayankans
Copy link
Collaborator

@aarongustafson I'm worried that returning an unstandardized string would lead to a situation where developers would start checking the user agent or OS in the code in order to properly handle the address field. That's something we should definitely avoid.

@tomayac Thanks for sharing this, it looks like it could solve the inconsistency issue. Do you know how applicable/adopted this is internationally? It's my understanding from previous discussions around using address fields that every country has it's own addressing system (in some places postal codes / street addresses are not applicable).

@tomayac
Copy link

tomayac commented Apr 5, 2019

Do you know how applicable/adopted this is internationally?

@rayankans vCard is a global standard, its shape is very similarly applied in other standards like https://schema.org/PostalAddress.

And again, both iOS as well as Android use vCard when you share a contact from the particular native Contact app.

[I]n some places postal codes / street addresses are not applicable

Yes, the LABEL is meant for more free-formy things.

@aarongustafson
Copy link

I forgot VCARD handled addresses like that. Thanks @tomayac. And I agree 100% that we want to avoid user agent sniffing @rayankans.

@rayankans
Copy link
Collaborator

Another option would be to re-use address formats defined in the Payments API spec
https://w3c.github.io/payment-request/#physical-addresses

@Malvoz
Copy link

Malvoz commented Jul 31, 2019

Another use case is for web maps to convert an address retrieved from the contact information into a point on the map. While this could be true for any map service I'd like to emphasize this capability described in "Use Cases and Requirements" for native web maps, that could make use of such access:
https://maps4html.github.io/HTML-Map-Element-UseCases-Requirements/#capability-location-address

/cc @prushforth

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants