WebAPI/ContactsAPI: Difference between revisions

Jump to navigation Jump to search
sort specific properties per methodology of inclusion sections, add 'key' property to level 4
(sort specific properties per methodology of inclusion sections, add 'key' property to level 4)
Line 120: Line 120:
4. More vCard4 features.  
4. More vCard4 features.  
* '''Is there an existing vCard feature for the requested feature?'''
* '''Is there an existing vCard feature for the requested feature?'''
* E.g. properties left out from vCard4/hCard(2), why the above is a subset of vCard4/hCard(2). Some common reasons:
** '''NU''' - Not commonly used in practice, either in address books or in publishing on the web. Reconsider such properties if usage changes.
** '''ER''' - Error prone whenever entered/published. Such properties are toast. Not getting added.
** '''AB''' - Absent from typical device address books (if you've seen a specific device with such fields in the address book, please list it here as a nested list item, preferably with screenshot of the UI). Reconsider such properties if added to address book UIs, note such research/data accordingly in [[#Considered_changes]] section below. Specific deliberately omitted property notes:
* 'logo' - NU, 'photo' is used instead
* 'post-office-box' - NU, AB
* 'extended-address' - ER. in practice such data typically ends up in a long 'street-address'.
* 'organization-name' and 'organization-unit' are rarely separately specified, users/publishers preferring to use the simple flat 'org' property instead.
Added for B2G db (but not in any known existing device address books):
* ContactAddress 'geo' property components 'latitude', 'longitude' and additional 'altitude' from GeoLocation API
* Contact 'gender' property components 'sex', 'gender-identity' (from vCard4/hCard2 in particular)


5. Feature parity with other devices.  
5. Feature parity with other devices.  
Line 171: Line 159:
=== Priority 4 feature requests ===
=== Priority 4 feature requests ===
Features requested by one or more individuals which are already present in the vCard4 spec, and likely implemented by by one or more implementations (but not interoperably).
Features requested by one or more individuals which are already present in the vCard4 spec, and likely implemented by by one or more implementations (but not interoperably).
Being considered:
* 'key' - Mozilla can be an industry leader here by including public keys in address books by default so communication application can start using and depending on them.
Some common problems:
* '''NU''' - Not commonly used in practice, either in address books or in publishing on the web. Reconsider such properties if usage changes.
* '''ER''' - Error prone whenever entered/published. Such properties are toast. Not getting added.
* '''AB''' - Absent from typical device address books (if you've seen a specific device with such fields in the address book, please list it here as a nested list item, preferably with screenshot of the UI). Reconsider such properties if added to address book UIs, note such research/data accordingly in [[#Considered_changes]] section below.
E.g. properties left out from vCard4/hCard(2), why the above is a subset of vCard4/hCard(2). Specific deliberately omitted property notes:
* 'logo' - NU, 'photo' is used instead
* 'post-office-box' - NU, AB
* 'extended-address' - ER. in practice such data typically ends up in a long 'street-address'.
* 'organization-name' and 'organization-unit' are rarely separately specified, users/publishers preferring to use the simple flat 'org' property instead.
* 'sort-string' / 'sort-as'. per suggestion from Jonas, the Japanese iPhone has a field for "phonetic last name" which can be used for sorting. The existing vCard3 sort-string property or vCard4 sort-as (sub)property could be used to capture this if the only intended use is sorting.
* 'sort-string' / 'sort-as'. per suggestion from Jonas, the Japanese iPhone has a field for "phonetic last name" which can be used for sorting. The existing vCard3 sort-string property or vCard4 sort-as (sub)property could be used to capture this if the only intended use is sorting.
* 'related' - human relationships (MOAB)
* 'related' - human relationships (MOAB)
Line 180: Line 182:
** manager - no existing value, there is mention on the [http://microformats.org/wiki/xpn-examples XPN Examples] research page on the microformats wiki
** manager - no existing value, there is mention on the [http://microformats.org/wiki/xpn-examples XPN Examples] research page on the microformats wiki
** PhD supervisor - no existing value. similar to previous 'manager' request. may be too domain specific to be worth standardizing.
** PhD supervisor - no existing value. similar to previous 'manager' request. may be too domain specific to be worth standardizing.
* vCard4 extensions


* vCard4 extensions
Added for B2G db (but not in any known existing device address books):
* ContactAddress 'geo' property components 'latitude', 'longitude' and additional 'altitude' from GeoLocation API
* Contact 'gender' property components 'sex', 'gender-identity' (from vCard4/hCard2 in particular)


=== Priority 5 feature requests ===
=== Priority 5 feature requests ===
canmove, Confirmed users
2,887

edits

Navigation menu