I'm afraid you've let your personal viewpoint color your summary
of the issues. You said:
"Solution 5 has not received any support."
and then gave quotes which, for the most part, don't really support
that summary.
The others disagree for basically two reasons. The first reason is
that we should not prevent developers from developing new media types
only because they use XML.
"Solution 5" doesn't prevent developers from developing new
media types. "Solution 5" just asks developers to code new media types
using existing media type labels. They are free to develop new
kinds of media. "Solution 5" doesn't prevent new developments.
It just says that those new developments are labeled as "text/xml"
or "application/xml".
"If the answer to this is "no, we don't want to try and
control the development, direction, and use of XML" then your
question is basically out of scope. People will design
whatever they want and register whatever they want. The
resulting mixtures and granularity will be whatever developers
decide is appropriate." (Ned)
I thought Ned's position was actually agreeing with Solution 5.
I don't think that it's a matter of whether we "want" to control
these things, but whether it's practical. I'd like to recommend
that applications use text/xml or application/xml, unless they
have a strong need to do something else, and note that in most
cases, there isn't a strong need, since the actual nature of
the data can be determined by looking inside the XML itself.
"Not just developers; increasingly, vertical markets. An XML
namespace for real-estate listings, for example. One for
dental records. So forth." (Chris)
I don't see that Chris is arguing against using text/xml or
application/xml as the MIME label for external representations
for XML bodies that use vertical market namespaces.
"This is the position of W3C; certain building blocks are made
available (foundational blocks such as XML itself, XLink,
XPointer, namespaces, etc; useful common things like
styleshets, SVG for images, RDF for metadata which can be used
or not as appropriate) but the way in which people combine
these building blocks is up to them, and the element names
that they use (when not using a building block that defines
names for them, like XHTML and SVG do) is entirely their own
affair." (Chris)
This doesn't argue one way or another against "solution 5".
The second reason is the burden of parsing.
The arguments from Chris and Frank are all about IMAP. But
the problem isn't a general one for "a mail protocol like IMAP",
it is "IMAP" that has the problem. An IMAP server has parsed
the MIME bodies of the messages in the mail store, in any case.
It's separated out multipart bodies, parsed the mail headers
into names and values, dealt with various encoding issues.
The only problem is that IMAP contains inconsistent access to
parsing and query facilities. But this is just a weakness of IMAP.
If you were using, say, WebDAV, to access your mailbox, then the
DTD of the XML body of your mail could as easily be a property
of the message body.
"Certainly with a mail protocol like IMAP you can look through
your inbox for entries based on values of the MIME header
fields. The example mentioned was a "mail-enabled"
application. For this application, the implementors on the
IETF CALSCH WG felt very much that the MIME header field
parameters were of importance." (Frank)
"Yes; especially in the case of IMAP where the initial
selection of bodis is done on the server and likely ones are
sent to the client for the calendar program to further
process." (Chris)
"But it [specialized media types] sure cuts down the class of
data to be further processed. Instead of searching through the
entire mailbox/the entire server, just search in the
text/calendar resources." (Frank)
"The overhead of having to open up every XML document to find
out what document type it is is not practical. As in the case
of email, all I should have to do is ask for a particular type
of object from the store and get it." (Frank)
"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)
"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." (Chris)
In general, we have to do this anyway: we parse the MIME to separate
out the multipart bodies, and then reparse the bodies when we do
the dispatch. If there's a generic XML dispatch engine in your
operating system, then perhaps it can pass on parsed-XML instead of
raw-XML, though, which would save some of the extra processing.
The dispatched XML media handlers would operate with DOM rather than
by reparsing, even if one of them was a DOM-toothbrush-interpreter
and another was a DOM-apartment-for-rent processor.
Larry
--
http://www.parc.xerox.com/masinter