Bureaucrats, canmove, Confirmed users
2,890
edits
WebAPI/ContactsAPI: Difference between revisions
Jump to navigation
Jump to search
→FAQ: Does every API structure imply a UI structure requirement, Which existing address books support multiple communication types
(→Priority 6 feature requests: add food like/dislike/restriction/allergy as a Priority 6 feature request) |
(→FAQ: Does every API structure imply a UI structure requirement, Which existing address books support multiple communication types) |
||
| Line 257: | Line 257: | ||
=== Is the name property a composition or something users enter === | === Is the name property a composition or something users enter === | ||
* Is the name property a composition of given and family name or is it something users can enter? | * Is the name property a composition of given and family name or is it something users can enter? | ||
** '''The name property is 'fn' and can be entered.''' The 'name' property is the replacement for 'fn' (formatted name) from vCard/hCard. This is an explicit renaming (to 'name') that multiple parties have independently done (decentralized convergent evolution), and thus is being adopted in [[hCard 2]] and thus we are adopting as well in the ContactsAPI. The 'name' property is something users can enter, DAP calls it 'displayName" or something needlessly divergent like that. | ** '''The name property is 'fn' and can be entered by users.''' The 'name' property is the replacement for 'fn' (formatted name) from vCard/hCard. This is an explicit renaming (to 'name') that multiple parties have independently done (decentralized convergent evolution), and thus is being adopted in [[hCard 2]] and thus we are adopting as well in the ContactsAPI. The 'name' property is something users can enter, DAP calls it 'displayName" or something needlessly divergent like that. | ||
=== Why are abbreviations used for adr bday org tel === | === Why are abbreviations used for adr bday org tel === | ||
| Line 268: | Line 268: | ||
* What is impp? | * What is impp? | ||
** '''impp is defined by [http://tools.ietf.org/html/rfc4770 RFC 4770] and incorporated into [[vCard4]]'''. The 'impp' property is for specifying URLs for instant messaging and presence protocol communications associated with a contact. | ** '''impp is defined by [http://tools.ietf.org/html/rfc4770 RFC 4770] and incorporated into [[vCard4]]'''. The 'impp' property is for specifying URLs for instant messaging and presence protocol communications associated with a contact. | ||
=== Does every API structure imply a UI structure requirement === | |||
* Does every API property, structure, array require similar structures in the UI? | |||
** '''No. There is no 1:1 API drives UI causality.''' For example: the vCard format exposes an array, and there are plenty of phones that import/export vCards and thus have some sort of implementation (including UI) that handles it in some way. Do all phones support all of vCard? No. But they are able to handle import/export of a format that supports whole arrays of types for example. | |||
=== Which existing address books support multiple communication types === | |||
* Which existing (shipping) address book support multiple communication types, e.g. an array of 'type' strings for tel, email, etc.? | |||
** '''Both iOS and Android ABs support types (plural) for communication properties''', as discerned by creating multiple phone numbers, and setting one of them to preferred, for each contact, and then exporting vCards, showing that the preferred phone number's type is exported as an array: "PREF,HOME" (e.g. for a home number). | |||
** Thus at a minimum for data portability fidelity from other platforms, the ContactsAPI must support the multiple types exported(emailed,shared,etc.) by iOS and Android AB. | |||
** A new Address Book UI (e.g. Gaia) can choose to support some simplified UI (e.g. looking for PREF in particular, and then assuming just one other type). | |||
== Issues == | == Issues == | ||