Re: gender/sex field in contact formats

Hi Joseph,

--On September 9, 2010 6:56:47 AM -0700 Joseph Smarr <jsmarr@google.com> 
wrote:

> In my experience, gender is almost always returned by providers as a
> string, and they don't all agree on canonical string values for male and
> female. But the following heuristic usually works: "if the gender string
> starts with 'm', normalize it to 'male', if it starts with 'f', normalize
> it to 'female', otherwise, leave it as is". In PoCo, our string-valued
> fields work exactly like this--we specify a few "canonical values" that
> people should try to use if possible, but leave the value open for people
> to also use non-standard or extensible values. Then depending on your UI
> for displaying/changing gender on your end, you can either look for the
> canonical values and map them to male/female radio buttons, or recognize
> that it's not male/female and show "other", or even show the exact string
> value.
>
>
> Seems like with <sex><integer>1</integer></sex> you're stuck throwing out
> all the non-male/female string gender values, right? 

Sounds like PoCo is just asking for trouble with interoperability. By not 
pinning this down more carefully you open yourselves up to arguments like 
"why can't I use my own languages terms for 'male' and 'female'".

>
> Thanks, js
>
>
> PS: And I still can't get over the fact that
> <sex><integer>1</integer></sex> is just ugly and bloated and semantically
> opaque. This kind of thing *does* matter if you want developers to
> understand, use, and, like your spec. Just because a spec is official
> doesn't mean it will automatically get wide adoption! Caring about being
> beautifully designed and user-friendly isn't just a smart tactic for
> consumer software/hardware, it's for anything humans have to deal with! :)

"semantically opaque" - absolutely not! "syntactically opaque" maybe, but 
the semantics are very explicitly given in the specification. You cannot 
infer anything about semantics by simply looking at some example XML - you 
have to go look at the specification for the schema (which in our case 
means looking at the vCard base spec and the vCard-in-XML spec).

-- 
Cyrus Daboo

Received on Thursday, 9 September 2010 14:09:25 UTC