Five proposed solutions

[MURATA Makoto <murata@xxxxxxxxxxxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxxxxxxx