Larry Masinter wrote, in part:
I'm saying you definitely have a problem: you have a complex space
of possible objects:
NO, this is not a complex problem. This is an existing 20+ year old mail
enabled application. This nut has already been cracked for Internet
developers using the "text/calendar" content definition. I queried
Kurita-san and Paul Hoffman because I was interested in utilizing XML
representation of iCalendar. We have a DTD defined. It is an isomer of the
iCalendar standard format, but the MIME content type defintiion for text/xml
and application/xml stinks. It doesn't provide us (and soon other XML
application developers too) the right tools to do our job. Tools that are
already in place for the iCalendar content type.
This is not a problem with MIME. This is not a problem with calendaring.
This is a problem with the current definition for the XML content type. This
mailing list is to air our discussion on how to best fix this, right?
Yes, the example is real, and shows that this problem can't be solved
by overloading the MIME type space.
Well, I personally don't think that we have "overloaded" the calendar
content type in the iCalendar content type definition. There needs to be
some balance between an infinite number of media types/subtypes for each
transaction type and a smaller, managable number of media types for each
logical application object type. As Ned has pointed out, this example and
other show that leaving "hooks" on the outside of the object wrapper is very
useful in providing a scalable, practical Internet solution using XML.
- - Frank