Subject: Re: [VCARDDAV] GENDER property inconsistency

From: Simon Perreault <[email-masked]>
Date: Fri, 20 May 2011 11:49:14 -0400

On 2011-04-20 11:02, Cyrus Daboo 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:
> 
>    property-gender = element gender {
>         element sex {
>           element text { "M" | "F" | "O" | "N" | "U" }
>         }?,
>         element identity { text }?
>       }

I will do it like this:

property-gender = element gender {
    element sex {
      element text { "M" | "F" | "O" | "N" | "U" }
    },
    element identity { value-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>.

You can't have an <identity> tag without a <sex> tag because that would
not be representable in vCard. We have the same issue with other
"structured" properties like ADR (in that case all components must be
present, whereas the identity component can be absent in sex).

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Simon Perreault <[email-masked]>
Date: Fri, 20 May 2011 11:53:40 -0400

On 2011-04-20 10:18, Arnaud Quillaud wrote:
> BTW, what is the difference between sex="" and sex="U" ?

Consider this example:

  GENDER:;queer

The sex is not unknown, therefore "U" does not fit. "" means "no
information".

Simon

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 20 May 2011 12:13:42 -0400

Hi Simon,

>     element identity { value-text }?

Why value-text inside identity? That would result in:

<identity>
  <text>XYZ</text>
</identity>

rather than:

<identity>XYZ</identity>

I don't see why the extra <text> element is needed. It looks like there are 
several property values where we "embed" a text element inside a 
"structured value" element that will only ever be text, e.g.:

property-n = element n {
    element parameters { param-language, param-sort-as, param-altid }?,
    element surname { value-text-list? },
    element given { value-text-list? },
    element additional { value-text-list? },
    element prefix { value-text-list? },
    element suffix { value-text-list? }
  }

That seems overly verbose. Can't we instead do:

property-n = element n {
    element parameters { param-language, param-sort-as, param-altid }?,
    element surname { text }?,
    element given { text }?,
    element additional { text }?,
    element prefix { text }?,
    element suffix { text }?
  }

These are the properties that I think have extra nesting that should be 
removed:

property-n
property-gender
property-adr

That is the approach we have in xCal for various "structured values", e.g.:

   property-geo = element geo {

       element parameters { empty }?,

       element latitude  { xsd:float },
       element longitude { xsd:float }
   }

   property-rstatus = element request-status {

       element parameters {
           languageparam?
       }?,

       element code { xsd:string },
       element description { xsd:string },
       element data { xsd:string }?
   }

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Fri, 20 May 2011 12:19:56 -0400

> That is the approach we have in xCal for various "structured values", e.g.:

Please talk to your co-author! Mike Douglass (sorry for pointing the
finger at you, but we need to coordinate quickly) was the one that
pointed out the inconsistencies in xCard and suggested that we use value
type elements everywhere, even when only a single value type is allowed.
I thought you guys would be doing the same thing.

What you are suggested is in line with earlier WG consensus (value type
elements not necessary in "structured" properties) and I would agree
with it.

Simon

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 20 May 2011 12:42:56 -0400

Hi Simon,

> elements not necessary in "structured" properties) and I would agree

I think Mike's point related to parameters rather than properties. That is 
what we got wrong and changed in xCal. Mike's point mostly related to 
having mixed content - complex and simple types - i.e. some parameters have 
a child element and some having child cdata - that is bad from an XML 
schema point. In the -09 draft all the parameter elements are complex 
types, so that issue has been addressed.

Sorry if that did not come across clearly, but I think what I am proposing 
is correct now. I will ping Mike and have him confirm.

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Fri, 20 May 2011 12:49:13 -0400

On 2011-05-20 12:42, Cyrus Daboo wrote:
> Sorry if that did not come across clearly, but I think what I am
> proposing is correct now. I will ping Mike and have him confirm.

Thanks. Once that's sorted out I'm ready to publish -10.

Simon

---

From: Mike Douglass <[email-masked]>
Date: Fri, 20 May 2011 14:21:11 -0400

I thought I was going to have to refute Cyrus but I think not.

For example in xcal we have

<uid>
<text>[email-masked]</text>
</uid>

We also have

<dtstart>
<parameters><tzid><text>America/New_York</text></tzid></parameters>
...

Why - because this approach makes all properties and parameters 
complexTypes in the schema and this allows a base type for all of them 
and a significant simplification of the programing model - as well as 
allowing extensibility. Otherwise we can only pass this as Object.

Now GEO looks like

<geo>
<latitude>...</latitude>
<longitude>...</longitude>
</geo>

It's still a complexType with a 2 part value

The logitude/latitude elements are type elements.

So

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

doesn't require the <text> to be consistent. <sex> is essentially the 
value type as is identity so I think that becomes

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

I'm not sure about

     element identity { value-text-list? }

just because the <text> element was a nice way to make a list - I 
suppose <identity> could repeat

Most of the others look fine with the possible exception of n and addr 
where all the value elements take a text-list. The choice seems to be
<identity>
<text>...</text>
<text>...</text>
<text>...</text>
</identity>

or
<identity>...</identity>
<identity>...</identity>
<identity>...</identity>

The first is what you have now and has the benefit that schema compilers 
would generate a list of text for the values.

If you choose the second approach it's still consistent with what I was 
trying to say and I guess (excuse my RelaxNG)

property-adr = element adr {
     element parameters { param-language, param-altid, param-pid,
                          param-pref, param-type, param-geo, param-tz,
                          param-label }?,
     element pobox { value-text-list? },
     element ext { value-text-list? },    element street { value-text-list? },
     element locality { value-text-list? },
     element region { value-text-list? },
     element code { value-text-list? },
     element country { value-text-list? }
   }

could be

property-adr = element adr {
     element parameters { param-language, param-altid, param-pid,
                          param-pref, param-type, param-geo, param-tz,
                          param-label }?,
     element pobox { text }+,
     element ext { text }+,
     element street { text }+,
     element locality { text }+,
     element region { text }+,
     element code { text }+,
     element country { text }+
  }

I'm sorry I didn't take a closer look at this sooner - I've been in my 
own version of schema hell lately....

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication&  Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

---

From: Simon Perreault <[email-masked]>
Date: Fri, 20 May 2011 14:36:14 -0400

> The logitude/latitude elements are type elements.

Got it! Thanks.

Simon