On 04/14/2011 03:18 PM, Keith Moore 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.
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.
In many situations XML is the only acceptable data format. The work
going on for the SmartGrid has made that clear to us. Far from
decreasing interoperability this work will help keep the work done in
XML based environments in line with that in the rest of the calendaring
world.
It is already the case that other data formats are in use - we're not
going to prevent that. The best we can do is to try to provide
standardised approaches to conversion and data formats.
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.
In the JAXB and SOAP worlds at least this is not an issue. By default
those environments ignore elements they are not aware of. That's fine as
schemas can be updated when it is important to handle these extensions.
An iCalendar XML schema is being developed for use in those environments
and already does a reasonable job of handling extensions. We're aware of
the problems posed by extensibility (as is most of the enterprise XML
world) and are developing ways of mitigating them.
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
It's worth remembering that the initial motivation for this
specification was not to promote the use of XML but in response to the
already widespread use of differing and incompatible XML forms of
calendar data.
--
Mike Douglass douglm@xxxxxxx
Senior Systems Programmer
Communication& Collaboration Technologies 518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf