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.
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.
It has always been our intent to have a 1-to-1 mapping between the two. We
in fact went out of our way to ensure that the XML schema would not
restrict in anyway what could be done with new iCalendar data objects.
--
Cyrus Daboo
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf