Registration of media type application/calendar+xml

[Cyrus Daboo]

Hi Keith,

--On September 10, 2010 10:09:11 AM -0400 Keith Moore <moore at 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.

>> 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