specific media-types for MathML3 ?

Paul Libbrecht paul at activemath.org
Mon Apr 6 11:08:41 CEST 2009


Le 05-avr.-09 à 23:13, Mark Baker a écrit :
> We call them media types now 8-)

noted (changed subject also).

>> Here are my questions:
>> - do you see any danger in having three mime-types if we have the  
>> provision
>> above?
>
> I wouldn't use the word "danger", but I personally don't see much
> value in having three media types based on your explanation and the
> spec itself.  The only reason I could see for needing another one (not
> necessarily two more) would be if there were agents which would only
> be implementing one of the two forms of MathML document and, most
> importantly, were unable to understand documents which contained the
> form they didn't implement.  But that doesn' t appear to be the case.

Martin J. Dürst replied:
> I agree with what Mark said.


Sure, that's the question and sure there are such agents even though  
nowadays they mostly do both.

For example giving only presentation into Maple works "often" (in an  
anglo-saxon world) but often interpretes wrong (e.g. with a limit).
The conversions are ready, they're just impossible to do fully.

The same would happen at the http level. Most tools can process all  
the three forms (they're all MathML after all) but they would process  
far better and fail less if they would know the specific types.

Martin J. Dürst also wrote:
> I guess you want multiple clipboard types because you want to give
> the receiving application a chance to use either of the two  
> representations. For media types, that would correspond to the  
> situation that you want your user agent to tell you which  
> representation
> it prefers, and the server to send one or the other depending on the
> request from the user agent.


I think this is the very best explanation I can see for the case of  
content-negotiation for http: give a chance to the client to indicate  
its preference and to the server to actually be able to do the effort  
of the conversion better than "just doing it generic".

One of the other example would be a component displaying a formula  
that would use the same URL as a content consumer (a function plotter  
for example) but interested to display that formula to  clients in  
their own language (or context of notation).


>> - is there a chance our registration for three mime-types is  
>> rejected for
>> other reasons?
>
> The use of "+" is incorrect in a couple of ways.  First, that the
> convention is used to indicate the possibility of generic processing
> by indication of a generic format, such as XML or JSON; "mathml" isn't
> such a generic format.

My feeling was different: mathml+xml definitely tasted generic enough  
to what it names.
But if you say so, we can certainly change the first +s to -!  
Nothing's fixed here.

paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2203 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20090406/44ad0af3/attachment.bin 


More information about the Ietf-types mailing list