Paul Hoffman / IMC wrote:
Dispatching based on media types raises a few important issues that are
somewhat unique to XML.
If we say "every application gets a new media type" then there is no clean
way for a MIME-handling application to fall back to handing an unknown
media type to an XML parser.
Although that is the right thing to do in some circumstances, and not in
others.
An unclean way for such an application to
handle an unknown media type is to look inside the first few octets of the
body and, if it looks like XML, hand it off to the XML parser instead of
treating it as application/octet-stream or text/plain.
Increasingly, many programs contain an XML parser. XML is being used for
a very wide variety of different things. There is unlikely to be "a"
single XML parser - its a component of some other application program.
If we say "stick everything XMLish under a media type that is XML-specific
with some parameter for the kind of XML" then we assume that handing off
unknown body types to an XML parser is useful.
Right. In some cases, it may be. The thing to avoid, though, it to havce
to parse the document once to find out what sort of thing it is,
dispatch it somewhere else, and then have that "somewhere else" start
parsing again from scratch. If that can be avoided by better labelling
up front, that is a win.
I question this assumption.
Right.
What's the XML parser going to do with this block of data? Display it? Not
terribly valuable.
Not even possible, in some cases. XML is being used for all sorts of
things from serialising Java Beans to Web server configuration files to
interprocess communication - a lot of these uses are not especially
"displayable". In some cases, the fact that they are written in XML is
the least important thing about them. These are likely to need
specialised registrations, too. Further, if the specification for any
such case is not controlled by a single vendor, then registration in the
vendor tree does not seem appropriate. This would be the case for
situations ranging from a small vendor group (such as the Flashpix
group) through groups such as W3C to bodies such as ISO, ITU, IEE and so
on.
Then there is a second class of uses which are essentially textual,
where the XML markup is being used to structure headings, footnotes,
chapters and suchlike document-like things. These things do indeed
benefit, if not recognised, from being "displayed" and may even contain
an internal link to a stylesheet which can be used to display them. I
think that dispatching this 'marked up text' class of uses to a single
parser/viewer, such as a browser, make sense (not in all cases of
course, and editing should be distinguished from viewing, but full
mailcap files can do that) and thus, a MIME labelling of text/xml would
make sense.
The third class of uses which are intended to be displayed but which
requitre specialised display processors. Examples of these are markup
for chemical structures, X3D for xml-ised vrml, PDB (protein database)
format, BSML (bioinformatics sequence markup language), SVG (scalable
vector graphics) and so on. These are likely to benefit from specialised
registrations, which might be in the image, application, model, or
other top level types.
So far I havewn't seens a good case made for application/xml, sinc ehte
re isn't a single XML application; the arguments around its use have
centered around concerns for the lowest common denominator fallback to
text/plain if text/xml is not recognised (and the possibility of bit 8
mangling, if sent over email rather than http or binary ftp)
Get some namespace information from the inside and then
dispatch based on the namespace? Possibly valuable, but this begs the
question of why wasn't that information out in the MIME headers.
I tend to lean towards "every application gets a new media type".
I think that is reasonable in many cases, but not all. There still seems
to be a place for text/xml, for textlike or documentlike applications.
--
Chris