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@xxxxxxxxxx> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf