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.
While all of these are true, you've missed the big downside to "tweak the
dispatched-to program": Such programs lose big-time in the integration they
can offer in the client environment.
More specifically, what happens when the XML-dispatching program decides,
"Surprise! The original client is the agent best suited to display of this
particular XML object." The problem is that even in tightly integrated plug in
setups there's usually no way to communicate this sort of thing back to the
client's dispacher to the point where a truly seamless display can be achieved.
The inevitable result is suboptimal integration, which users, myself included,
loathe.
This is another instance of a problem we first encountered with security
multiparts: When you dispatch handling of a security multipart to a separate
application, getting the enclosed data back to the original client often
isn't possible. And while a few clients have adopted plugin architectures
that address this (Eudora, for example), most have not, and worse, plugins
capable of working really well in such environments have been slow in coming.
The result in the case of container objects like security multiparts has
been to force the original client to do this sort of processing. And I suspect
that similar forces will work to force a single level of dispatch for XML.
And this, I believe, argues strongly for using different media type
labels for XML in quite a few (but not all) cases.
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.
I'm afraid I have to disagree.
Ned