Subject: [VCARDDAV] GENDER property inconsistency

From: Arnaud Quillaud <[email-masked]>
Date: Wed, 20 Apr 2011 16:18:37 +0200

Hello,

About the GENDER property:

http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-19#section-6.2.7 
defines it as:

<<

GENDER-param = "VALUE=text" / any-param
                    GENDER-value = sex [";" text]
                    sex = "" / "M" / "F" / "O" / "N" / "U"

when http://tools.ietf.org/html/draft-ietf-vcarddav-vcardxml-09 defines 
it as:

<<

property-gender = element gender {
     element sex {
       element text { "M" | "F" | "O" | "N" | "U" }?
     },
     element identity { value-text-list? }
   }

On one hand, we have a text and on the other a text-list. Dont know how 
much difference it will make in practice but we may want to change the 
later to a value-text.

BTW, what is the difference between sex="" and sex="U" ?

Thanks,

Arnaud Quillaud

---

From: "Tantek Çelik" <[email-masked]>
Date: Wed, 20 Apr 2011 14:51:12 +0000

The vcardxml version is correct with separate sex and identity components of gender (consensus was reached on this list with thread between myself, Kevin Marks, Sarah Dopp). 

Please update the vcardrev version accordingly. Here is vcardrev sample spec text with examples:

https://wiki.mozilla.org/VCard4#GENDER

> BTW, what is the difference between sex="" and sex="U" ?

"U" = known "unknown sex" vs 
lack of property = unspecified (unknown unknown, e.g. per Rumsfeld [1]).

Thanks,

Tantek

[1] http://en.m.wikipedia.org/wiki/There_are_known_knowns

-----Original Message-----
From: Arnaud Quillaud <[email-masked]>
Sender: [email-masked]
Date: Wed, 20 Apr 2011 16:18:37 
To: CardDAV<[email-masked]>
Subject: [VCARDDAV] GENDER property inconsistency

Hello,

<<

<<

Thanks,

Arnaud Quillaud
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 20 Apr 2011 11:02:13 -0400

Hi Arnaud,
(cc'd calsify list because of comment at the end proposing a change in xCal)

> much difference it will make in practice but we may want to change the

--On April 20, 2011 2:51:12 PM +0000 Tantek Çelik <[email-masked]> 
wrote:

> The vcardxml version is correct with separate sex and identity components
> of gender (consensus was reached on this list with thread between myself,
> Kevin Marks, Sarah Dopp).
>

But Tantek, in your example there are at most two text elements, whereas 
the current xCard has value-text-list which always for multiple text 
components in the identity. I think the correct xCard definition ought to 
be:

    property-gender = element gender {
         element sex {
           element text { "M" | "F" | "O" | "N" | "U" }
         }?,
         element identity { text }?
       }

Note how I also moved the '?' onto the <sex> element. I see no reason why 
<sex> has to be present when it is empty. Same thing for <identity>.

However, this brings up a minor difference with xCal. In xCal we have two 
"structured" properties where we created "custom" value elements for the 
sub-structure: GEO and REQUEST-STATUS. For the later we have:

   # 3.8.8.3 Request Status

   property-rstatus = element request-status {

       element parameters {
           languageparam?
       }?,

       element value {
           element code { text },
           element description { text },
           element data { text }?
       }
   }

So we choose to wrap the "structured" value inside of a <value> element. I 
think that is unnecessarily verbose and we should remove the <value> 
element (in fact I think that was left over from a time when we used a 
<value> element for all value types). If there are no objects I will make 
that change in xCal.

-- 
Cyrus Daboo

---

From: Tantek Çelik <[email-masked]>
Date: Thu, 21 Apr 2011 00:30:41 -0700

On Wed, Apr 20, 2011 at 08:02, Cyrus Daboo <[email-masked]> wrote:
>>  >>
> But Tantek, in your example there are at most two text elements, whereas the
> current xCard has value-text-list which always for multiple text components
> in the identity. I think the correct xCard definition ought to be:
>

Good catch.

I agree with these fixes to xCard.

Thanks Cyrus.

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5