At 01:12 AM 5/8/99 -0700, Larry Masinter wrote:
I'm opposed to creating more top-level media types than are necessary,
or to adding more parameters and other doodads than are necessary,
where I define 'necessary' as 'having a compelling application TODAY'.
I agree with Larry here.
I don't believe that "xml" fits into the guidelines for new
top level types, which seem to rest, not on the argument about
"default processing" but rather "device/gateway filtering".
At least notionally, the distinction was between text/ image/
audio/ video/ and (now) model/, with "application/" being the
catch-all for everything else. I think "xml" is, for the
most part, "application/".
It sure seems to be. It is an application that can be processed by multiple
processors.
Let me turn around the "desirable?" question. In many ways, I think it
would be better for the XML world to *not* have a top-level "xml" type.
Take a look at the situation today, which will probably be the same a year
and five years from now:
1) You have a MIME-receiving agent (mail agent, HTTP client, etc.). That
agent knows how to dispatch based on MIME information. It knows how to
dispatch to programs. These dipatched-to programs might display the content
directly, or might make a decision and launch a different display program.
2) You have a generic XML-display program (XMLShow) and some programs for
displaying particular XML types (DisplayEDI, DisplayCal, and so on).
3) Someone invents a new XML type (XMLFoo) and a special display program
(DisplayFoo).
At the point that step (3) happens and you receive a message with that
content type, you want your agent in (1) to do The Right Thing, which is to
launch DisplayFoo or, if you don't have a copy of DisplayFoo, to launch
XLMShow.
If all XML items come in with MIME types of "xml/foo", then someone needs
to tweak the settings in your client to know about DisplayFoo. If all your
XML items come in with the type "application/xml", then someone needs to
tweak the settings in the dispatched-to program to know about DisplayFoo.
I believe that "tweak the dispatched-to program" is a much better
environment than "tweak all the MIME-receiving clients" for many reasons:
- If you have more than one MIME-receiving client, the user tweaks fewer
settings.
- There is no need to register every sub-type: XMLShow can decide to launch
based on the content of the XML, such as from the DTD or XML namespaces
used. This speeds up adoption of new XML types.
- If "application/xml" automatically launches XMLShow, it is XMLShow that
can be told about the "smarter" applications like DisplayFoo, and it might
be able to cooperate with them in many ways. For instance, DisplayFoo might
be able to ask XMLShow to render parts of a document while DisplayFoo
renders other parts.
- XMLShow will be able to open a file off of disk (with no MIME
information) and still be able to hand off the file to DisplayFoo. The
MIME-receiving clients can never do this.
- Given today's MIME-receiving clients, it is more likely that XMLShow will
be more flexible about adding new DisplayFoo viewers than the
MIME-receiving clients are.
In summary, I believe that specialized XML viewers are better off in an
environment where they are launched by the thing that "application/XML"
launches, not by their own MIME sub-types.
--Paul Hoffman, Director
--Internet Mail Consortium