W3C home > Mailing lists > Public > public-contacts-coord@w3.org > July to September 2010

Re: gender/sex field in contact formats

From: Joseph Smarr <jsmarr@google.com>
Date: Thu, 9 Sep 2010 07:15:31 -0700
Message-ID: <AANLkTinFxJFTChx18GegMgnKRn2DTDkUPcXDCrs7mjuc@mail.gmail.com>
To: Cyrus Daboo <cyrus@daboo.name>
Cc: Dan Brickley <danbri@danbri.org>, Simon Perreault <simon.perreault@viagenie.ca>, jsmarr@stanfordalumni.org, Joseph Smarr <jsmarr@gmail.com>, Thomas Roessler <tlr@w3.org>, public-contacts-coord@w3.org, Tantek Çelik <tantek@tantek.com>
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
>
>
Received on Thursday, 9 September 2010 14:16:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 9 September 2010 14:16:25 GMT