- From: Mark Nottingham <mnot@yahoo-inc.com>
- Date: Mon, 6 Feb 2006 14:21:45 -0800
- To: paul@activemath.org
- Cc: www-tag@w3.org
Hi Paul, I'm no MIME expert (compared to quite a few folks in the IETF, certainly), but it seems to me that that's outside the scope of what a Media type should be expected to do. It sounds like your use case is more along the lines of CC/PP <http:// www.w3.org/Mobile/CCPP/>; i.e., publishing profiles of capabilities. Thinking out loud, it could also be a media type parameter; that would be much more appropriate, from a MIME perspective. E.g., Content-Type: application/mathml+xml; symbol-set="http:// www.example.com/foo-symbol-set/" The alternative that you're putting forth, as I understand it, is to do something like: Content-Type: application/mathml_foo_symbol_set+xml ... with other media types for each other kind of symbol set. This approach has the disadvantage that a well-written generic mathml handler has to know about all of the media types for different versions of mathml, so it can catch their dispatch, and has to update the dispatch mechanism every time there's a new one. If I understand you, you're saying that implementations that dispatch only on the media type and nothing else (not even content type parameters) constrain you, and force you to use media types for *all* dispatch. If so, that's a shame, but I think the proper thing to do is to fix those implementations (by providing more capable dispatch/ negotiation mechanisms), rather than devaluing the entire media type system. Have you tried to register these symbol-set specific media types? I'd imagine that doing so would run into some pushback; in particular, section 4.1 of RFC 4288 says: > Media types MUST function as an actual media format. > Registration of > things that are better thought of as a transfer encoding, as a > charset, or as a collection of separate entities of another > type, is > not allowed. For example, although applications exist to decode > the > base64 transfer encoding [RFC2045], base64 cannot be registered > as a > media type. Content negotiation is tricky; some people have called conneg in HTTP a failure (and indeed, there were many, many attempts at it). One of the problems is that when you get more and more specific about the capabilities and preferences of a device and/or service, you have to be more and more verbose, and it becomes less and less likely that you'll be able to come to an agreement, or use shared services like caching. Media types weren't intended to allow such fine-grained negotiation, and they lose a lot of their value when they're used in that fashion. Cheers, > As you probably know, the only way to negotiate inter-application > copy-and-paste or drag-and-drop are mime-types... so I have to be > sure that these are working for our purpose. > > One requirement I have on these mime-types is the necessity to > describe the set of mathematical symbols supported by the clients. > One such set is the MathML-content specification set of symbols. > But, typically, there are others: > - for example if you go to some mathematical systems which have > traditionally different set of symbols (I think Maple needs some > classical symbols to be non-MathML-symbols). > - for example if you go to some places where the input is highly > limited hence even supporting the whole MathML-content is too much. > > I even think these set of symbols should even be authorable. > Enabling this to be declared at the negotiation allows source- > applications (or their authors) to respond to such limitations by > providing the necessary translators, if possible. Right now, I also > serve these clips by HTTP GETs and I dare say that a request for > text/xml can only be honoured in a completely arbitrary fashion... > > Are you saying that such set of symbols should not be declarable as > easy as a web-publication ? I tend to believe that my requirements > say the contrary... > > paul > > -- Mark Nottingham mnot@yahoo-inc.com
Received on Monday, 6 February 2006 22:25:59 UTC