On Sep 10, 2010, at 10:24 AM, Cyrus Daboo wrote: > Hi Keith, > > --On September 10, 2010 10:09:11 AM -0400 Keith Moore <mo...@cs.utk.edu> > 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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
