1. Summary
My first mail to this mailing list lists four possible solutions for
dispatching (and content negotiation).
Solution 1. Specialized media types (possibly with some parameters)
Solution 2: New top-level media type xml and its subtypes
Solution 3: A new parameter "externalid" for text/xml and application/xml
Solution 4: Yet another parameter "optinfo" or "ADD-PARAM" on top of solution 3
Larry added another.
Solution 5: The handler of the XML media types examines the XML MIME
entity and then dispatches to one of several possible media type
handlers.
So far, solution 1 has found some strong support. Solution 2 has neither
strong opposition nor strong support, but has been questioned. Solution 3
and 4 do not work. Solution 5 has not received any support.
2. Solution 1
Solution 1 has found some strong support.
"I tend to lean towards "every application gets a new media
type." (PaulH)
"In case it isn't obvious by now, so do I." (Ned)
"My quick and dirty way of thinking of this is that the media
type/subtype should to be sufficient to get you the right
application, but the parameters then can tell that application
what to do, or when to do it, or various other sorts of things
that for whatever reason are best not stored in or derived
from the actual content." (Ned)
One concern is the burden of registration, but "Registration of media
subtypes is easy." (Agreement 1 in "What we have agreed on").
Furthermore, a specialized media type may require parameters specific
to that media type.
"However, in the general problem space surrounding these sorts
of applications, I see value in using parameters." (Ned)
"However, just having a "calendar" media type won't cut
it. The CUA needs to be able to search the MIME entity bucket
for particular types of "calendar" media types." (Frank)
3. Solution 2
We have not yet found good reasons fot a top-level media type for xml.
Fallback is not a good reason, since "Fallback to general-purpose XML
applications is not useful." (Agreement 3 in "What we have agreed
on").
Here are some other weak reasons.
"However, if the answer [My note: the more general question of whether
there is to be an attempt to "design" the XML usage space, and if there
is, whether such an attempt has any chance of succeeding.] to this is
"yes", then the task at hand becomes one of coming up with an
appropriate
set of rules that people think will actually do the job and will be
followed. And in such a world a top-level XML type might have some
value,
if only as a place to attach the ruleset." (Ned)
"The only value I would see is if the fallbacks and other behaviours of
the text/* tree were seen to be unavoidable and made the use of XML too
fragile there. XML element names and element content can use all sorts
of Unicode characters." (Chris)
"We can also lift the line termination rule of the top-level media type
"text"." (Murata)
[Note: There are some possible reasons, which I will mention my personal mail.]
However, it might make sense to introduce a top-level media type for
document-like XML, since "Document-like XML documents can be handled
by general-purpose XML viewers" (Agreement 4 in "What we have agreed
on").
4. Solution 3 and 4
Solution 3 and 4 do not work, since "Dispatch based on parameters are
not widely supported" (Agreement 2).
"I'm afraid you've missed the biggest problem with this
approach -- one that makes it almost a complete nonstarter:
The lack of ability to dispatch on parameters in most
applications that support MIME." (Ned)
5. Solution 5
Larry advocates this solution. He points out that MIME headers
cannot entirely solve the problem of dispatching and negotiation.
"In general, you cannot solve the problem of "dispatch to the
appropriate handler" by modifying MIME, since finding the
appropriate handler is platform and installation
dependent." (Larry)
"And adding more MIME types for each kind of combination of
XML seems like a recipe for disaster. If we have html, xhtml,
html-netscape, html-microsoft,
html-optimized-for-msie-on-windows-nt50, each with slightly
different definitions, would they get separate MIME types?"
(Larry)
"... specialized media types should be
introduced with caution, since a world in which every kind of
document has its own media types is one in which there is
little interoperability." (Larry)
"Neither adding parameters to text/calendar nor inventing new
MIME subtypes for text/calendar-request text/calendar-response
etc. will help implement the query capabilities that you
need.
...
Since it doesn't work, stop trying. You need some other kind
of query protocol than keying off content-type." (Larry)
"Someone has to parse them. Certainly if a search engine can
parse web pages to find the words and their lexical
equivalences, an event search engine can parse the XML
documents and index them in the multiple ways that searching
the calendar-event database needs to be searched." (Larry)
"Purchase orders that are applicable to the particular
division, purchase orders that haven't already been processed,
purchase orders that are assigned to a particular account rep,
etc. These are all database search problems, not type-indexing
problems." (Larry)
"You might also want to scan your email for "event invitations
from my boss", and you can't solve that problem with
specialized MIME media types. So the question is: are there
any realistic cases where having a "text/calendar" distinction
in the email header actually helps substantially in deciding
which email bodies to retrieve?" (Larry)
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.
"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)
"Not just developers; increasingly, vertical markets. An XML
namespace for real-estate listings, for example. One for
dental records. So forth." (Chris)
"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)
The second reason is the burden of parsing.
"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)
Makoto
Fuji Xerox Information Systems
Tel: +81-44-812-7230 Fax: +81-44-812-7231
E-mail: murata(_at_)apsdc(_dot_)ksp(_dot_)fujixerox(_dot_)co(_dot_)jp