Subject: Re: [VCARDDAV] vCard XML

From: Renato Iannella <[email-masked]>
Date: Tue, 2 Mar 2010 11:02:21 +1000

I am still not clear why we add the datatying to the XML instance.

XML Schema is good at validating such datatypes.

In both vCard and iCal we have syntax like:

       <anniversary>
         <date-time>20090808T1430-0500</date-time>
       </anniversary>

Anniversary is either a date-time or string, which XSD can handle with union types.

I also think that compact XML is good, so this:

       <tel>
         <parameters>
           <type><work/><text/><voice/><cell/><video/></type>
         </parameters>
         <uri>tel:+1-418-262-6501</uri>
       </tel>

could be represented as:

       <tel type="work, text, voice, cell, video">tel:+1-418-262-6501</tel>

Cheers...  Renato Iannella
NICTA

---

From: Renato Iannella <[email-masked]>
Date: Tue, 2 Mar 2010 11:03:40 +1000

In relation to consistency between vCard and iCal.....(at the XML instance value level):

vCard GEO is an URI, iCal is a lat,long string
vCard EMAIL is text, iCal is a mailto URI
vCard Dates are 8601 strings, iCal is separate structure for year, month, day

Any chance of these being more consistent? (from either end...)

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 02 Mar 2010 12:31:54 -0500

Hi Renato,

> vCard GEO is an URI, iCal is a lat,long string

This is just the way the "base" vCard and iCalendar specs use that 
property. To maintain one-to-one mapping between the XML and "base" 
representations we need to stick with that.

> vCard EMAIL is text, iCal is a mailto URI

There is no EMAIL property in iCalendar. Calendar user addresses in 
iCalendar are defined to be a URI - often those are mailto:, but they are 
not limited to that. I guess you could argue that EMAIL in vCard should be 
a URI, but that would be a big change.

> vCard Dates are 8601 strings, iCal is separate structure for year, month,

The current icalendar-in-xml spec defines date/date-time values as "text" - 
i.e. the 8601 strings used in iCalendar.

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Fri, 05 Mar 2010 16:09:36 -0500

On 2010-02-26 12:47, Cyrus Daboo wrote:
> 3) All XML elements in the "urn:ietf:params:xml:ns:vcard-4.0" namespace
> must be mapped to their vCard equivalents (component, property, parameter).

> (3) is wrong right now in that the vCard XML: property as defined allows
> for normal vCard properties to remain encoded as XML in the vCard itself
> as shown in the example in Section 5. I think this issue was discussed
> before (at a meeting or on the list) and consensus was to change that to
> follow what is proposed for iCalendar.

I don't recall any discussion on this issue. Personally I don't care, 
but a priori I would tend to favour flexibility.

Why is it important that this cannot be written?

XML:<email><text>[email-masked]</text></email>

> (6) I think this is OK. Though I note we took a slightly different
> approach in the RelaxNG scheme in the icalendar-in-xml spec. We chose to
> define schema elements almost on a one-to-one basis with iCalendar and
> actually added comments that related the RelaxNG schema to the sections
> in the iCalendar spec where the iCalendar equivalent item was defined.
> Whilst this "breaks" up the RelaxNG schema into a lot of small pieces, I
> think it is easier to relate back to the original syntax (i.e. anyone
> looking at the XML schema can quickly find the matching section in the
> base iCalendar spec). That is probably a personal preference, but I
> would prefer the vCard spec to do what we did.

Well, remember that in vCard the use of dates and times is very limited. 
We have three properties that use these value types (BDAY, DDAY, 
ANNIVERSARY) and only one of those was present in vCard 3. And as you 
said XML tools usually can handle dates by themselves. I would prefer to 
keep this really simple.

> Also, I think we should
> prefix/suffix schema elements with "property-", "param", "value-" as we
> did in iCalendar. Again that is important to avoid a clash of names
> (e.g. if the same name is used for a property and parameter in vCard).

I think we should forbid name clashes completely in vCard. I'll add that 
to the vCard base spec, and then we don't need the prefixes anymore.

We could even remove the <parameters> element now that clashes are not 
an issue.

> (8) The current vCard spec does use elements for enumerated types, e.g.:
>
> element type {
> element work { empty }?,
> element home { empty }?,
> element media { \text }?
> }
>
> In the iCalendar spec we did things like:
>
> roleparam = element role {
> "CHAIR" |
> "REQ-PARTICIPANT" |
> "OPT-PARTICIPANT" |
> "NON-PARTICIPANT"
> }
>
> Given that parameter values are text and in vCard are allowed to contain
> characters that are possibly disallowed as XML element names (e.g. "<"
> or ">" !!) I think we need to make these enumerations text values and
> not XML elements.

Done. (There was consensus on this issue in Hiroshima.)

Thanks,
Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 05 Mar 2010 16:34:24 -0500

Hi Simon,

--On March 5, 2010 4:09:36 PM -0500 Simon Perreault 
<[email-masked]> wrote:

> I don't recall any discussion on this issue. Personally I don't care, but
> a priori I would tend to favour flexibility.
>

A vCard parser seeing this will treat it as an opaque value. vCard parsers 
should not be expected to parse XML into vCard properties - that is the 
duty of the XML<->vCard converter.

> We could even remove the <parameters> element now that clashes are not an
> issue.

I don't think we should forbid the use of the same name in a property, 
parameter or value. Its seems somewhat unfair to say we can't have a DATE 
property or parameter now given that the only concern is how the XML schema 
is written (and its really just a stylistic feature of the schema - after 
all there is nothing that requires the relaxNG definitions to use names 
that match their vCard equivalents - the names of elements have to match of 
course).

> Done. (There was consensus on this issue in Hiroshima.)

Thanks.

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Fri, 05 Mar 2010 16:41:30 -0500

On 2010-03-05 16:34, Cyrus Daboo wrote:
> A vCard parser seeing this will treat it as an opaque value. vCard
> parsers should not be expected to parse XML into vCard properties - that
> is the duty of the XML<->vCard converter.

Yes of course. A proper converter would do that. But I don't see why the 
example above should be illegal.

Here's a use case: Suppose you have to pass XML vCards through something 
that groks only text vCard. Your XML-speaking endpoints don't have or 
need a text vCard parser. So they can just wrap their vCard with:

BEGIN:VCARD
VERSION:4.0
XML:<XML vCard goes here>
END:VCARD

and it will come out on the other end unaltered.

> parameter or value. Its seems somewhat unfair to say we can't have a
> DATE property or parameter now given that the only concern is how the
> XML schema is written (and its really just a stylistic feature of the
> schema - after all there is nothing that requires the relaxNG
> definitions to use names that match their vCard equivalents - the names
> of elements have to match of course).

Then it would be better to use different XML namespaces for the 
properties, parameters, and values instead of prefixing their tag names, 
don't you think?

Simon

---

From: Filip Navara <[email-masked]>
Date: Sat, 6 Mar 2010 07:36:51 +0100

> On 2010-03-05 16:34, Cyrus Daboo wrote:
[snip]
> Then it would be better to use different XML namespaces for the properties,
> parameters, and values instead of prefixing their tag names, don't you
> think?

I don't think Cyrus was ever talking about *tag names*, just the
schema element names. See this example taken from iCalendar XML:

   property-created = element created {
       element parameters { empty }?,
       value-date-time
   }

"property-created" is the schema element name, "created" is a tag name.

Best regards,
Filip Navara

---

From: Cyrus Daboo <[email-masked]>
Date: Sun, 07 Mar 2010 13:15:05 -0500

Hi Filip,

> "property-created" is the schema element name, "created" is a tag name.

Yes, that is precisely what I was trying to get at - sorry if it was not 
clear from my original post. All I care about is that the schema 
element/definition name be prefixed to avoid naming problems. The actual 
element tag names are fine being a direct character for character match 
with their vCard counterparts.

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Mon, 08 Mar 2010 08:24:16 -0500

On 2010-03-07 13:15, Cyrus Daboo wrote:
>> schema element names.

Ah! I understand now! Sorry for this.

Of course the names used internally in the schema can be anything. I'll 
change them all according to your wishes.

Simon