canmove, Confirmed users
2,887
edits
VCard4: Difference between revisions
Jump to navigation
Jump to search
reviewed thru section 6.2.10
(reviewed thru section 6.2.8) |
(reviewed thru section 6.2.10) |
||
| Line 291: | Line 291: | ||
Thus while there is no existing evidence of address books that provide this kind of user interface feature, I believe this may be an instance where it makes sense to add this field, given the *address book* use cases documented above. | Thus while there is no existing evidence of address books that provide this kind of user interface feature, I believe this may be an instance where it makes sense to add this field, given the *address book* use cases documented above. | ||
Naming: while the name "DDAY" I'm sure appeals as a parallel to the BDAY property, the term DDay already has a widely known/used historical semantic and thus it may unnecessarily cause confusion. | |||
I suggest instead the term "DECEASED" as that is much more indicative of the meaning (less cryptic). | |||
"Deceased" was also the original suggestion provided on the microformats page for this property: http://microformats.org/wiki/vcard-suggestions#Deceased | |||
In addition, consider permitting a simple "Y" value to indicate that the person is deceased but no precise date or even year is known. This would enable modeling of a simple checkbox interface to indicate that someone has passed away without burdening the user with entering a date or year. | |||
I would also be ok postponing this property to a "genealogy" extension. | I would also be ok postponing this property to a "genealogy" extension. | ||
| Line 316: | Line 324: | ||
Recommendation: drop from vCard4. | Recommendation: drop from vCard4. | ||
=== section 6.2.9. ANNIVERSARY === | |||
6.2.9. ANNIVERSARY | |||
I have seen "anniversary" as a field in address book application user interfaces (anecdotal, off the top of my head), and thus this seems like a reasonable addition to vCard. | |||
Should allow same date-and-or-time data type as BDAY, including year-only, month-day, year-month etc. | |||
=== section 6.2.10. SEX === | |||
6.2.10. SEX | |||
It's a good idea to add the general idea of this feature to vCard. | |||
The specific implementation is roughly close but does leave something to be desired. | |||
The current draft has: The value 0 stands for "not known", 1 stands for "male", 2 stands for "female", and 9 stands for "not applicable". | |||
While this discretization into 4 values makes sense, and if I'm not mistaken, is based on the work in the microformats community: | |||
http://microformats.org/wiki/gender-brainstorming | |||
The translation to opaque numerical values is a negative. | |||
Instead use the single letter prefixes of the English terms as noted in the microformats page: | |||
sex: M(ale) F(emale) O(ther) N(one or Not applicable) | |||
This reflects common use in both social networking sites which permit M or F (see microformats research at above URLs), as well as previous formats that have worked on representing this information, e.g. openid.sreg.gender permits "M" for male, "F" for female. | |||
Finally, sex without gender is problematic from a gender identity perspective and discriminatory against a marginalized minority. | |||
Thus for the sake of allowing a more flexible representation that avoids such marginalization, an additional property should be introduced: | |||
GENDER-IDENTITY | |||
which takes a string that the user can assign any label. | |||
Alternatively (and preferably), rather than the SEX property, introduce a new *structured* property: | |||
GENDER | |||
Purpose: To specify the components of the sex and gender identity of the object the vCard represents. | |||
Value type: A single structured text value. Each component can have a single value. | |||
Cardinality: (0-1) | |||
Special notes: The structured property value corresponds, in sequence, to the sex (biological), and (optional) gender identity. The text components are separated by the SEMI-COLON character (ASCII decimal 59). | |||
Sex component: The value M stands for "male", F stands for "female", O stands for "other", N stands for "none or not applicable". | |||
Gender identity component: a single text value. | |||
In addition the current draft includes a notion of "not known", which, though I haven't seen evidence for, can understand the potential utility as it may help represent the explicit not knowing of information. Thus I would be ok with: | |||
Sex component: The value M stands for "male", F stands for "female", O stands for "other", N stands for "none or not applicable", and U stands for "unknown". | |||