Subject: [ietf-calsify] XML iCalendar issues and questions

From: Steven Lees <[email-masked]>
Date: Tue, 21 Jul 2009 23:44:42 +0000

Hello,

I haven't seen much public comment on the XML iCalendar draft (http://www.ietf.org/id/draft-daboo-et-al-icalendar-in-xml-00.txt) that Cyrus, Mike, and I submitted in June. I thought it might be helpful to write up a quick summary of some of the issues that people have mentioned to me. Since one of our goals is to have consistency between vCard-in-XML and iCalendar-in-XML, I've also written up my understanding of how the vCard-XML draft handles these issues.

1) Date-time format:
The xCalendar draft breaks out date/time values into separate XML elements for year/month/day and hour/minute/second. The main reason for choosing this format was to make it easier for implementers who want to transform the XML into a presentation format like HTML. The separate elements mean that no additional parsing is necessary. It does significantly increase the size of the XML format, however. One compromise that has been suggested is to make the XML element names smaller, i.e. <y> instead of <year>.

Here's an example:
        <dtstart>
          <date-time utc="yes">
            <year>2009</year><month>2</month><day>6</day>
            <hour>12</hour><minute>0</minute><second>0</second>
          </date-time>
        </dtstart>

The xCard draft embeds the vCard time value in a single XML element:, which is obviously much more compact:

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

2) Extensibility:
The xCalendar draft describes two kinds of extensions. Extensions that originate in iCal with the "x-" prefix are converted to XML elements with the same name (but in lowercase). Those extensions are in the same XML namespace as other xCalendar elements. This makes it straightforward to convert those extensions back to the iCal format. Other XML extension elements are allowed as well, but such extensions must not be in the xCalendar XML namespace. Such extensions are not convertible to the iCal format.

In contrast, the xCard draft describes only the second kind of extension: those that are in a separate XML namespace. As far as I can tell, the xCard draft doesn't describe a way to convert those extensions to the vCard format.

3) XML attributes:
The xCalendar draft currently uses attributes in two places. There is a "utc" attribute on date-time elements, and a "sign" attribute on duration elements.

The xCard draft doesn't appear to use any XML attributes. This allows a simple transformation to key/value formats like JSON.

It would be great to hear opinions on these or other issues. If you're attending IETF next week in Stockholm, the topic of XML formats for vCard and iCalendar is on the agenda for the vcarddav working group on Tuesday July 28: http://www.ietf.org/mail-archive/web/vcarddav/current/msg01105.html.

Thanks,
Steven

_______________________________________________
ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: "Tim Hare" <[email-masked]>
Date: Tue, 21 Jul 2009 21:51:10 -0400

I won't be in Stockholm, but I'll throw my two cents in. 
 
I'm not an implementer (currently) but I think separating out all the
elements of date and time doesn't gain that much - there are well-developed
libraries of routines for parsing dates in ISO format, I believe,  so it
should not be that costly to extract the date-time value as in xCard and
deal with it.
 
My next comment is more of a question.  I would have mapped components and
properties (VEVENT, DTSTART) to XML elements, and all property parameters to
attributes - for example 
 
    <ATTACH fmttype="text/plain" encoding="BASE64"
value="binary">...</ATTACH>
 
Can you tell me what the thought process was for having so few attributes?
 
Tim Hare
Interested Bystander, Non-Inc.

  _____  

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Steven Lees
Sent: Tuesday, July 21, 2009 7:45 PM
To: [email-masked]
Subject: [ietf-calsify] XML iCalendar issues and questions

Hello,

I haven't seen much public comment on the XML iCalendar draft
(http://www.ietf.org/id/draft-daboo-et-al-icalendar-in-xml-00.txt) that
Cyrus, Mike, and I submitted in June. I thought it might be helpful to write
up a quick summary of some of the issues that people have mentioned to me.
Since one of our goals is to have consistency between vCard-in-XML and
iCalendar-in-XML, I've also written up my understanding of how the vCard-XML
draft handles these issues.

1) Date-time format:

The xCalendar draft breaks out date/time values into separate XML elements
for year/month/day and hour/minute/second. The main reason for choosing this
format was to make it easier for implementers who want to transform the XML
into a presentation format like HTML. The separate elements mean that no
additional parsing is necessary. It does significantly increase the size of
the XML format, however. One compromise that has been suggested is to make
the XML element names smaller, i.e. <y> instead of <year>.

Here's an example:

        <dtstart>

          <date-time utc="yes">

          </date-time>

        </dtstart>

The xCard draft embeds the vCard time value in a single XML element:, which
is obviously much more compact:

2) Extensibility:

The xCalendar draft describes two kinds of extensions. Extensions that
originate in iCal with the "x-" prefix are converted to XML elements with
the same name (but in lowercase). Those extensions are in the same XML
namespace as other xCalendar elements. This makes it straightforward to
convert those extensions back to the iCal format. Other XML extension
elements are allowed as well, but such extensions must not be in the
xCalendar XML namespace. Such extensions are not convertible to the iCal
format.

In contrast, the xCard draft describes only the second kind of extension:
those that are in a separate XML namespace. As far as I can tell, the xCard
draft doesn't describe a way to convert those extensions to the vCard
format.

3) XML attributes:

The xCalendar draft currently uses attributes in two places. There is a
"utc" attribute on date-time elements, and a "sign" attribute on duration
elements.

The xCard draft doesn't appear to use any XML attributes. This allows a
simple transformation to key/value formats like JSON.

It would be great to hear opinions on these or other issues. If you're
attending IETF next week in Stockholm, the topic of XML formats for vCard
and iCalendar is on the agenda for the vcarddav working group on Tuesday
July 28:
http://www.ietf.org/mail-archive/web/vcarddav/current/msg01105.html.

Thanks,

Steven

---

From: Steven Lees <[email-masked]>
Date: Thu, 23 Jul 2009 19:10:33 +0000

Tim Hare wrote:

"I'm not an implementer (currently) but I think separating out all the elements of date and time doesn't gain that much - there are well-developed libraries of routines for parsing dates in ISO format, I believe,  so it should not be that costly to extract the date-time value as in xCard and deal with it."

As you'd expect, we discussed this quite a bit. We did have a preference for the format shown in the current draft, but if there's strong opinion the other way I don't think any of the co-authors would strongly object to a single element.

Tim also wrote:

"My next comment is more of a question.  I would have mapped components and properties (VEVENT, DTSTART) to XML elements, and all property parameters to attributes - for example

    <ATTACH fmttype="text/plain" encoding="BASE64" value="binary">...</ATTACH>

Can you tell me what the thought process was for having so few attributes?"

It's been a while since we settled on that part of the format, so I don't remember all of the reasons. One reason was that there are a couple of multi-valued parameters such as delegated-from and delegated-to, and we didn't want to have to stuff all of the values in a single attribute string. We could have special-cased those parameters, but we wanted to maintain consistency if possible to make implementation easier. We were also leaning slightly away from attributes because if you don't use them at all, then you can do a simple translation between XML and JSON.

Steven