Re: [VCARDDAV] vCard XML

Simon Perreault <simon.perreault@viagenie.ca> Fri, 05 March 2010 21:09 UTC

Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: vcarddav@core3.amsl.com
Delivered-To: vcarddav@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEB6228C35E for <vcarddav@core3.amsl.com>; Fri, 5 Mar 2010 13:09:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBTusYcivJ8y for <vcarddav@core3.amsl.com>; Fri, 5 Mar 2010 13:09:37 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by core3.amsl.com (Postfix) with ESMTP id 52F7C28C173 for <vcarddav@ietf.org>; Fri, 5 Mar 2010 13:09:37 -0800 (PST)
Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4ADFA21B8D for <vcarddav@ietf.org>; Fri, 5 Mar 2010 16:09:37 -0500 (EST)
Message-ID: <4B917310.8050905@viagenie.ca>
Date: Fri, 05 Mar 2010 16:09:36 -0500
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Thunderbird/3.0.3
MIME-Version: 1.0
To: vcarddav@ietf.org
References: <D73BA7B608FA67B02A90FD64@caldav.corp.apple.com>
In-Reply-To: <D73BA7B608FA67B02A90FD64@caldav.corp.apple.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [VCARDDAV] vCard XML
X-BeenThere: vcarddav@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF vcarddav wg mailing list <vcarddav.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vcarddav>
List-Post: <mailto:vcarddav@ietf.org>
List-Help: <mailto:vcarddav-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Mar 2010 21:09:38 -0000

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>simon.perreault@viagenie.ca</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