w3c / contact-picker

Contact Picker API
https://www.w3.org/TR/contact-picker/
Other
74 stars 8 forks source link

Provide access to address properties #12

Closed petele closed 4 years ago

petele commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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:forrestgump@example.com
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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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

rayankans commented 5 years ago

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

Malvoz commented 5 years ago

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