[VCARDDAV] vCard XML

[Cyrus Daboo <[e-mail]>]

Hi,
Here is a summary of what the CalConnect folks came up with with 
icalendar-in-xml 
(<http://tools.ietf.org/html/draft-daboo-et-al-icalendar-in-xml>) as 
applied to vCard. I think the same principals should be applied to what we 
do in vcard:

1) Full round tripping of vCard data to/from XML. Semantic equivalence is 
required, but syntactic equivalence is not required (e.g. lowercase vCard 
property -> XML -> uppercase vCard).

2) All syntactic elements on the vCard side (components, properties, 
parameters) must be mapped to XML elements in the 
"urn:ietf:params:xml:ns:vcard-4.0" namespace. This applies to X- properties 
as well - only exception is the XML: property described below.

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).

4) Any XML elements not in the "urn:ietf:params:xml:ns:vcard-4.0" namespace 
must be mapped to an XML: property in vCard. Note that this restricts 
"extension points" to only the "level" of vCard properties. i.e. you cannot 
have a non "urn:ietf:params:xml:ns:vcard-4.0" element as as parameter. Each 
xml element at the "property level" in the XML is mapped to its own XML: 
property in vcard. Ordering of those is not considered significant.

5) Minimal use of XML attributes on elements.

6) Some structured value types should be "broken out" into sub-elements in 
XML, e.g. FN. But other types (DATE) should be left as-is because XML tools 
typically know how to handle those (originally the icalendar-in-xml draft 
did actually break out the DATE/DATE-TIME values into sub-elements but we 
changed that based on the feedback we received).

7) Because components and properties can be mixed in iCalendar we choose to 
encapsulate each in their own XML element to avoid namespace issues. vCard 
currently does not support the notion of a sub-component so that 
requirement is probably not needed unless we anticipate ever wanting 
sub-components.

8) Enumerated values remain as text, not XML elements.

So how does this apply to the current draft: 
draft-ietf-vcarddav-vcardxml-01?

(1) is pretty much OK.

(2) is OK.

(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.

(4) By fixing (3) I think we take care of this one too.

(5) is OK.

(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. 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).

(7) We probably don't care about this now. If we do ever want to have 
sub-components in vcard, the we could simply choose names to avoid a clash 
with properties. Actually if we added a requirement on iCalendar we could 
do the same there. That requirement would be that no new property name 
match an existing component name and vice-versa. We originally choose not 
toi do that because we did not want the xml spec to add constraints on the 
base iCalendar spec.

(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.

Overall, I think if we can agree to the above changes, then iCalendar and 
vCard in XML specs will be pretty close - and that would be good. There are 
some minor structural differences and some more descriptive sections in the 
iCalendar spec that I think are worth bring in to the vCard one too (e.g., 
<http://tools.ietf.org/html/draft-daboo-et-al-icalendar-in-xml-01#section-3.1>).

-- 
Cyrus Daboo