The vCard 3.0 validator is ten years old. The standard has moved on, Python has moved on, and I’d like to think I’ve learned a thing or two as a developer. But I’m not working on any vCard validators, and probably won’t be for the foreseeable future.
Maybe I’m suffering from second-system syndrome, but I’ve tried to reboot the project at least three times now. The Python code isn’t very elegant, fast or well tested. I set up skeletons in Java version and Rust, both excellent languages. I tried defining an ANTLR grammar. But I’ve got nothing to show for any of that. The main problem is motivation: vCard 3, 4 and jCard are incredibly out of date, to the point where writing a parser is equal parts painful and boring.
And now, because the Internet needs more opinions (and standards): a human friendly address card format is possible. vCard/jCard is not it. When someone brave and tenacious enough to take this on comes around, I really hope they take at least the following into account:
- Use a popular, existing serialization format. JSON won in this space. It’s not perfect, but it’s here to stay and it’s a good compromise between human and machine readable.
- Don’t create another jCard. If you were developing the world’s first address card format, what would users and developers want to see?
- Conversely, vCard did many things right. UTF-8, base64 and ISO dates are definitely good things.
- All caps is hard to read. Don’t shout.
- Don’t limit (or even recommend) a line length or line splitting scheme. Address cards shouldn’t be inlined into emails or documents any more than CSV files.
- Dictionaries (as in associated key/value pairs) are useful. Use them.
- Lists are useful. Use them.
- Preferred name should probably be the only required name field.
- Time zones are not UTC offsets. I do not live in time zone “+12:00”, because that offset changes twice per year. I live in time zone “Pacific/Auckland”. This can be the difference between being on time and wasting everybody’s time.
- Allow linking to photos. Sure URLs are ephemeral, but so is basically everything in an address card.
- Any property not in the standard should simply be ignored, as long as the entire document is still a valid instance of the serialization format.
- Internationalization and localization are complex but important.
What will such a standard look like? Maybe something like this will be possible:
{ "preferred name": "Jane Doe", "phone": { "cell": ["+99 9999-9999", "+11 0000 0000"], "home": "+99 9999-9999" }, "URL": { "blog": "https://…", "work": ["https://example.org/", "https://example.com/"] }, "photo": "https://…", "my custom property": "…", "time zone": "Pacific/Auckland" }