Re: gender/sex field in contact formats

Cyrus-we haven't seen any interop problems with PoCo thus far--quite the
contrary. :) And as I explained below, the spec is still very
well-specified. In particular, it says the string-values "male" and "female"
(in English, as printed) *are* the canonical values (ditto for "work",
"home", and "other" for canonical type-values). So these tokens are just as
good as 0 or 1 (except you have a clue of guessing their meaning upon
inspection, heh), and it still leaves the flexibility for other values
(which can be in whatever language they choose, since they're just
non-canonical string values at that point).

Thanks, js

On Thu, Sep 9, 2010 at 7:08 AM, Cyrus Daboo <cyrus@daboo.name> wrote:

> 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
>
>