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(_at_)cs(_dot_)utk(_dot_)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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf