Re: Registration of media type application/calendar+xml

[Keith Moore <[e-mail]>]

Let me say off the bat that I'm now convinced that there is at least some marginal utility in having an XML representation of iCalendar.   And the barrier for registration of new types is deliberately low, so I now think there's enough utility in having such a type.

I still think it would be helpful to improve the mapping so that it's clear that it will work across reasonable changes/extensions to iCalendar format, and to simplify it so that it's easier to understand and implement.  

I also think it would be appropriate for the document to make it clear that the standard for exchange of calendar data between systems is still iCalendar format, and that implementations should still have the ability to import and export iCalendar.

>>> We need to distinguish between alternate syntactic forms, versus alternate
>>> semantic environments.  Translating between versions of the former do not need
>>> to lose information.  Translating between versions of the latter almost
>>> certainly do.  Losing information is about differences in semantics.
> 
>> I'm not convinced that there is a difference in practice between the two. 
>> Different syntactic forms tend to get used in different environments, and to
>> adapt to the requirements/conventions of those environments.
> 
> That has not been my experience. My experience has been that when it comes to
> interoperability in both the short and long term, clear, accurate and concise
> specifications of the formats and the mappings between them are key.

I certainly agree that if you're going to have multiple file formats, those are the optimal conditions.  If the mapping is simple enough, and the specification clear and concise enough that it's obvious how to write correct code to map between the two, the chance that implementations will support both formats is very good.

And without quoting and responding at length, I think your example of CGM is instructive.

Though I do have to wonder, if the mapping is really that simple, clear, and concise - why is there a need for any implementation to support multiple external formats?  Each system that prefers a tree-structured internal representation can just use that specification to convert at the boundary.

Anyway, I feel like I've made my point and it has been given due consideration, and I hope that the discussion has been useful for the authors and/or IESG.

Keith