canmove, Confirmed users
2,887
edits
WebAPI/ContactsAPI: Difference between revisions
Jump to navigation
Jump to search
→FAQ: add more q&a: Why are abbreviations used for adr bday org tel, What is impp
(→Goals: clarify related work re: a more 'appy' API) |
(→FAQ: add more q&a: Why are abbreviations used for adr bday org tel, What is impp) |
||
| Line 161: | Line 161: | ||
=== Why are givenName familyName arrays instead of optional === | === Why are givenName familyName arrays instead of optional === | ||
* could use clarification of why a number of fields are arrays instead of optional DOMString. e.g. givenName, familyName. Those seem like 0-or-1 cases, not lists. | * could use clarification of why a number of fields are arrays instead of optional DOMString. e.g. givenName, familyName. Those seem like 0-or-1 cases, not lists. | ||
** ''' | ** '''i18n.''' Experience with vCard3 and hCard with international content has shown that multiple different languages/cultures have multiple given names and family names, and thus the change was made in [[vCard4]] to make these multivalued. - [[User:Tantek|Tantek]] 10:37, 25 October 2011 (PDT) | ||
=== Why are flattened adr properties arrays instead of optional === | === Why are flattened adr properties arrays instead of optional === | ||
* could use clarification of why a number of fields are arrays instead of optional DOMString. e.g. fields of the flattened adr. Those seem like 0-or-1 cases, not lists. | * could use clarification of why a number of fields are arrays instead of optional DOMString. e.g. fields of the flattened adr. Those seem like 0-or-1 cases, not lists. | ||
** ''' | ** '''Simplification and i18n.''' The multivalued adr properties are a result of both lack of use / common mis-use of post-office-box and extended-address properties (such data is more often/reliably shoved into multiple lines of street-address) and countries having multiple lines/values for street-address and/or locality/region. - [[User:Tantek|Tantek]] 10:37, 25 October 2011 (PDT) | ||
=== 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' from vCard/hCard (what the DAP folks call 'displayName' or similar). 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 the 'adr', 'bday', 'org', and 'tel' properties? | |||
** '''property names re-used literally from vCard/hCard.''' 'adr', 'bday', 'org', and 'tel' are re-used with the same semantics from [[vCard]] and [[hCard]] (which itself is a [http://microformats.org/2010/07/08/microformats-org-at-5-hcards-rich-snippets#billions-hcards well-established part of the web platform]). It is better to re-use names of existing properties rather than re-name them in a good intentioned (but ill-wrought) attempt to "fix" names (for differing opinions/values of "fix"). This is a general design principle borne out of experience with earlier attempts at re-use/re-naming which resulted in unnecessary vocabulary divergence. See '''[http://microformats.org/wiki/minimal-vocabulary#preserve_literal_vocabulary_when_reusing_meaning preserve literal vocabulary when reusing meaning]''' and the subsequent section '''avoid renaming when reusing''' with the example of the failed/divergent efforts to rename the 'org' property in particular over the years. | |||
=== 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. | |||
== Articles == | == Articles == | ||