On Sep 10, 2010, at 10:24 AM, Cyrus Daboo wrote: > Hi Keith, > > --On September 10, 2010 10:09:11 AM -0400 Keith Moore <moore@xxxxxxxxxx> wrote: > >>> 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. > > Fair enough. We can adjust e.g. Section 3.7 that talks about only X- extensions to also refer to any new iCalendar data objects. The basic premise being that new iCalendar data object names map directly to an XML element name. After each table in the previous sections we can add a reference to section 3.7 with a statement that that is how new items will be handled. That would help. But why do you need specific rules for any of the iCalendar data object names? I can understand one or two exceptional cases, but if the mapping you have is truly adaptable, it shouldn't need many of those rules. Keith _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf