"Formatted" field as a fallback for the "location" section

[shea256]

Can you add a "formatted" field for location as a fallback, just in case someone wants to specify their location as a string? This is what Gravatar does and it's also compatible with the format that Twitter uses for it's "location" field (it's just a string).

[shea256]

It'd just be nice to allow a user to build his/her resume after connecting with Twitter or after pulling the data from Gravatar. And there's a very high chance that the only location data that will be obtained is a string.

[DonDebonair]

But then we're going to model the spec after the ambiguity of possible source data. I don't think we should do that. It's up to the tools and users to extract the data in a format suitable for jsonresume.

[ocram]

100% agree with @DandyDev. Twitter or Gravatar have a string only because the location in your profile isn't important there. We shouldn't make JSON Resume worse just to simplify the import from those two sites.

Anyway, the fields that we have for the location right now should suit all needs.

Can we close here?

[shea256]

OK I'd just point out real quick that addresses and locations are much more complex than this spec seems to indicate.

https://developers.google.com/places/documentation/details

[ocram]

If you take a closer look at that page, you see that only address_components[] is important and this is what they have and what we have in the specification right now:

• (theirs) => (ours)
• street_number => address
• route => address
• postal_code => postalCode
• locality => city
• administrative_area_level_1 => region
• country => countryCode

Actually, there's not even a single property missing. Anyway, I don't see how a single plain text field should be better than our location object.

[wdoekes]

+1 to closing this.

[shea256]

Fair enough.