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
ietf(_at_)ietf(_dot_)org mailing lists by 2011-05-12. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org 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
IETF-Announce(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf