On Sep 10, 2010, at 9:56 AM, Cyrus Daboo wrote:
Hi Keith,
--On September 10, 2010 1:40:16 AM -0400 Keith Moore
<moore(_at_)cs(_dot_)utk(_dot_)edu> wrote:
But here's the acid test. If you can define a mapping from iCalendar to
XML that doesn't require any string constants to describe it (other than
for iCalendar keywords that imply nesting, and separators that are used
in a regular fashion in iCalendar), and if you can define the inverse
mapping from XML to iCalendar without naming more than a couple of
specific element or parameter names - then I'll concede that the mapping
will probably continue to work in the face of extensions to the iCalendar
data model. Otherwise, I'm highly dubious.
That is precisely the goal of draft-daboo-et-al-icalendar-in-xml. iCalendar
components, properties, parameters and values all map to XML in a consistent
manner with no need to "special case" based on type or value.
But you're not doing that in the draft. You explicitly list every keyword.
Every time a new component, property, parameter, etc is added to iCalendar, the
mapping code will have to change also. The trick is to be able to translate
between formats, with no changes to the code needed even when the format is
extended.
Conversion to/from XML is trivial - I have coded at least one half of that
and I know others who have done both ways.It should also be easy to put
together an XSLT to go from XML to iCalendar - with the only possible
difficulty being having to apply escaping and line folding as required by
iCalendar.
That would be great, again provided you don't have to explicitly list every
keyword. It still wouldn't convince me that XML iCalendar is sufficiently
valuable to be worth the degraded interoperability. But if you're going to
have two formats, being able to automatically convert between them is the best
way to do that.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf