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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf