Subject: Re: Last Call: <draft-daboo-et-al-icalendar-in-xml-08.txt> (xCal: The XML format for iCalendar) to Proposed Standard

From: Keith Moore <[email-masked]>
Date: Thu, 14 Apr 2011 11:52:37 -0400

I appreciate that great pains have been taken to ensure that this format is a dual of the standard iCalendar format, that translation can be performed in both directions without loss, and that at least some attempt has been made to specify the conversion algorithms in such a way that (if carefully implemented) they should continue to work with extensions to iCalendar.

I think it's confusing that many elements are referred to using an ICAL: prefix, when (a) the xml examples don't actually associate that prefix with a namespace, and (b) when iCal is probably a trademark of Apple.

However (and I think it's been at least 10 years since this was first proposed) I still find myself wondering, why is this format needed or even useful?    Practically speaking, I think the adoption of this format will only increase the burden on implementations and decrease the likelihood of interoperability between implementations.  It will increase the burden on implementations because now implementations will need to be able to accept, and possibly generate, two different calendar data formats instead of one.   

It will decrease interoperability because there will certainly be some attempts to send xCalendar data created by new implementations, to old implementations that only accept iCalendar data.  It will also decrease interoperability because, inevitably, some implementations of the conversion routines will fail to be sufficiently general in order to handle currently-undefined properties and components.   This is an almost inherent consequence of the likely use of XML schema description languages that explicitly enumerate element names, and processing languages that associate explicit element names with processing actions.   Finally it will decrease interoperability because it will no longer be the case that only producers and consumers of iCalendar data have to interoperate - it will then be necessary for producers, consumers, and converters to all interoperate - thus introducing more opportunities for both implementation bugs and version skew to create problems.

I also get the impression that the mapping of "values" or data types (section 3.6) between iCalendar and XML is not sufficiently general to permit continued interoperability across extensions.

I think that adoption of this format will in practice require that (a) any extensions to iCalendar to also explicitly specify how they are mapped into xCalendar, and (b) every, or nearly every, iCalendar<>xCalendar conversion product to be updated every time there is an extension to the iCalendar format.  

I also suspect that converting the format to XML will encourage ad hoc extensions to xCalendar which might not map well to iCalendar - since the constraints and extension model of iCalendar will not be obvious to the typical XML code developer.

Use of the "XML" property in iCalendar implies that the conversion routine needs to know which properties are "already" defined in iCalendar, which either implies that iCalendar cannot be extended, or that different converters (knowledgable about different versions of iCalendar) will produce different results (some mapping unknown properties to the iCalendar XML property, and some mapping them to native iCalendar properties).

Correct conversion from iCalendar to XML appears to require the converter to know about the types of each of the properties even though these are not explicitly specified in the source iCalendar document.   This is problematic if new properties are defined for iCalendar, as old converters won't know about the types of those properties.

So, in summary, I still don't think this is worth the trouble.   Regardless of the application, providing multiple ways to represent the same information generally seems to degrade interoperability.

Keith

On Apr 14, 2011, at 11:20 AM, The IESG wrote:

> 
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'xCal: The XML format for iCalendar'
>  <draft-daboo-et-al-icalendar-in-xml-08.txt> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2011-05-12. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-daboo-et-al-icalendar-in-xml/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-daboo-et-al-icalendar-in-xml/
> 
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 14 Apr 2011 12:57:37 -0400

Hi Keith,

--On April 14, 2011 11:52:37 AM -0400 Keith Moore 
<[email-masked]> wrote:

> I appreciate that great pains have been taken to ensure that this format
> is a dual of the standard iCalendar format, that translation can be
> performed in both directions without loss, and that at least some attempt
> has been made to specify the conversion algorithms in such a way that (if
> carefully implemented) they should continue to work with extensions to
> iCalendar.

Yes, that has always been a requirement for this mapping.

> I think it's confusing that many elements are referred to using an ICAL:
> prefix, when (a) the xml examples don't actually associate that prefix
> with a namespace, and (b) when iCal is probably a trademark of Apple.

Section 2 explains that the ICAL: prefix is used when elements are referred 
to outside the context of an XML fragment - i.e. in the actual text. As 
regards the possible trademark issue, to remove any possibility of that I 
will change to using IC: instead (hopefully there are not "legal" 
objections to that).

> However (and I think it's been at least 10 years since this was first
> proposed) I still find myself wondering, why is this format needed or
> even useful?    Practically speaking, I think the adoption of this format
> will only increase the burden on implementations and decrease the
> likelihood of interoperability between implementations.  It will increase
> the burden on implementations because now implementations will need to be
> able to accept, and possibly generate, two different calendar data
> formats instead of one.

First of all the real burden in handling iCalendar is not the syntax, it is 
the semantics (dealing with recurrences, timezones etc). In most cases, 
apps that use iCalendar parse the data into their own internal object model 
and deal with it there. Those implementers that have already developed 
iCalendar-in-XML parsers/generators have found it trivial to do and map to 
their internal object models (I have done that, and I am sure others can 
chime in and confirm this too).

Secondly, there is a great push on now to include iCalendar data in various 
web tools and automated systems, where XML is the primary format that is 
used. In particular, OASIS is planning on adopting this specification as a 
key component of smart grid work they are undertaking. The Calendaring and 
Scheduling Consortium has been advising them and helping develop APIs 
(REST, SOAP) etc to enable the kinds of calendar data access and 
manipulation that they need.

> I think that adoption of this format will in practice require that (a)
> any extensions to iCalendar to also explicitly specify how they are
> mapped into xCalendar, and (b) every, or nearly every,
> iCalendar<>xCalendar conversion product to be updated every time there is
> an extension to the iCalendar format.

I disagree that extensions will need to describe anything related to 
iCalendar-in-XML. We have tried very hard to have an automatic mapping. In 
fact I have several iCalendar extension drafts in the works and none of 
them will make reference to iCalendar-in-XML.

> I also suspect that converting the format to XML will encourage ad hoc
> extensions to xCalendar which might not map well to iCalendar - since the
> constraints and extension model of iCalendar will not be obvious to the
> typical XML code developer.

That is a concern. But any changes to the semantics of iCalendar that go on 
the standards track are covered by the IANA registration procedures 
outlined in 5545. As such designated experts get to review those and those 
experts can keep this problem in check (yes I happen to be one of those 
designated experts).

> Use of the "XML" property in iCalendar implies that the conversion
> routine needs to know which properties are "already" defined in
> iCalendar, which either implies that iCalendar cannot be extended, or
> that different converters (knowledgable about different versions of
> iCalendar) will produce different results (some mapping unknown
> properties to the iCalendar XML property, and some mapping them to native
> iCalendar properties).

One of the primary uses for iCalendar-in-XML is to allow it to be easily 
embedded in other XML documents (e.g. business-to-business automated 
transactions that require detailed specification of timing), and to also 
allow "annotation" of the iCalendar data with other XML elements (in a 
different namespace) that may provide references back to the enclosing 
data. The "XML" property is designed to allow round-tripping of XML data in 
other namespaces embedded in the iCalendar-in-XML data.

> Correct conversion from iCalendar to XML appears to require the converter
> to know about the types of each of the properties even though these are
> not explicitly specified in the source iCalendar document.   This is
> problematic if new properties are defined for iCalendar, as old
> converters won't know about the types of those properties.

Hrmm, good point. I will need to think about how the default value type can 
be handled in that case.

> So, in summary, I still don't think this is worth the trouble.
> Regardless of the application, providing multiple ways to represent the
> same information generally seems to degrade interoperability.

I take it that you would consider offering similar comments on the 
vCard-in-XML draft (draft-ietf-vcarddav-vcardxml) which is also in IETF 
last call?

-- 
Cyrus Daboo