Specify a MIME type for OpenMath

[jbs1]

migrated from Trac, where originally posted by clange on 23-Feb-2009 4:31pm

Every OpenMath encoding needs a MIME type. I am not familiar with binary formats, but for the XML encoding, let me suggest application/openmath+xml, which follows the standard recommendation.

(Background: I'm currently writing on HTTP content negotiation involving OpenMath content. A generic MIME type text/xml would be too fuzzy, as that could also subsume other formats, like MathML or OMDoc.)

[jbs1]

migrated from Trac, where originally posted by clange on 27-Mar-2010 9:01pm

BTW, should we have a separate MIME type for CDs? Or should they also be served as application/openmath+xml?

Maybe this question can be answered by retracing the introduction of a separate XML namespace for CDs.

[jbs1]

migrated from Trac, where originally posted by clange on 6-Apr-2010 3:07pm

Michael, can you please help me to answer this? Please reassign or put others on Cc as needed. This is a prerequisite for the linked data agenda (cf. #116 and the WebSci10 paper).

[jbs1]

migrated from Trac, where originally posted by clange on 29-Jul-2010 10:44am

Aha, apparently the MathML spec already knows more than we do. Therefore I'll Cc all those who have worked on it.

In an example for annotation-xml/**encoding**, the MIME type application/openmath+xml occurs: http://www.w3.org/TR/MathML3/chapter5.html#id.5.2.3.2

Technically I consider that a bug in the MathML spec, as no MIME type has been specified for OpenMath yet. So it's probably another, albeit hopefully easy task for the "OpenMath 2 2nd ed./2.1/3.0" working group to specify this, in order to make OpenMath compatible with what MathML already assumes about it.

[jbs1]

migrated from Trac, where originally posted by polx on 30-Jul-2010 9:58pm

Christoph,

I'm sorry I did not see you were questing for this.

Sure, it's application/openmath+xml because of RFC-3023.

We could have something else... but I don't think we wish it.
Indeed it would have been polite to not suggest such an example in the MathML spec and wait for OpenMath to specify one... but honestly it seems to be quite a safe bet.

I would agree that CDs should be a different CD.

paul

[jbs1]

migrated from Trac, where originally posted by clange on 30-Jul-2010 10:23pm

Replying to [comment:4 polx]:

Sure, it's application/openmath+xml because of RFC-3023.
Do you mean it is'' – or do you rather mean it ''should be? No doubt, it should be application/openmath+xml, at least for the OMOBJs, but we neither specified it explicitly (which we should IMHO do in the standard – that's what I intended with this ticket), nor did we officially register it.

Not sure how that works, does anyone of you know? There is a registration form, but it says "Registrations in the standards tree must be approved by the IESG and must correspond to a formal publication by a recognized standards body." I don't think the OpenMath Society meets the latter requirement, does it?

OK, maybe we don't need the official registration. According to the official directory, even application/mathml+xml is not registered. (Maybe it should be!) Note that being mentioned as an example in RFC 3023 does not replace the registration. Compare RFC 3236, which registers application/xhtml+xml.

We could have something else... but I don't think we wish it.
I agree with you.

Indeed it would have been polite to not suggest such an example in the MathML spec and wait for OpenMath to specify one... but honestly it seems to be quite a safe bet.

I would agree that CDs should be a different CD.
Maybe application/openmath-cd+xml? From RFC 3023 I don't see that that would be forbidden.

[jbs1]

migrated from Trac, where originally posted by polx on 31-Jul-2010 9:35am

Christoph,

the procedure for MathML is here: http://www.w3.org/2002/06/registering-mediatype
MathML puts it in Appendix B:
http://www.w3.org/TR/MathML3/appendixb.html

We certainly need an official registration but I understand we need to:

• publish a draft with our registration details
• submit it to ietf-types
• get discussed how we can get it registered

So the first thing would be to draft a few paragraphs I think (types are needed for OM, OCD, STS, and NTNs when it's defined.
I hope we do not need an RFC, at least if we have a formally announced draft.

should I ask on ietf-types?

paul

[jbs1]

migrated from Trac, where originally posted by david on 31-Jul-2010 4:22pm

On 31/07/2010 10:35, OpenMath wrote:

#106: Specify a MIME type for OpenMath
...
the procedure for MathML is here: http://www.w3.org/2002/06/registering-

... I think though that that's a special w3c/ietf arrangement and probably you would have to do the full registration procedure for a non w3c spec.

Incidentally the reason we didn't register a mime type in the first place (or after the +xml convention was formalised) was that (at the time, at least) the effects of using a specialised mime type were almost all bad. Specifically that systems that could display OpenMath objects or CD files (using generic XML processing) would not know the mime type (even if it was registered) and so would just offer a file/save menu.

David

[jbs1]

migrated from Trac, where originally posted by kohlhase on 1-Aug-2010 7:21am

Replying to [comment:7 david]:

On 31/07/2010 10:35, OpenMath wrote:

#106: Specify a MIME type for OpenMath
...
the procedure for MathML is here: http://www.w3.org/2002/06/registering-

... I think though that that's a special w3c/ietf arrangement and probably you would have to do the full registration procedure for a non w3c spec.
I had always read it this way, but maybe the OM Society can have a similar deal, maybe the W3C deal is an attempt of the IETF to simplify registration that applies to OMSoc as well. We should find out. Paul, could you?

Incidentally the reason we didn't register a mime type in the first place (or after the +xml convention was formalised) was that (at the time, at least) the effects of using a specialised mime type were almost all bad. Specifically that systems that could display OpenMath objects or CD files (using generic XML processing) would not know the mime type (even if it was registered) and so would just offer a file/save menu.

There is a difference between registering media types (so that applications can use them) and actually using them in all cases. It seems to me that we are seeing more possibilities to profitably using media types for Math (e.g. Clipboard). Having registered types is therefore a good thing. Depending on the situation application developers may still decide to use the more generic application/xml media type.

[jbs1]

migrated from Trac, where originally posted by kohlhase on 1-Aug-2010 7:24am

Replying to [comment:6 polx]:

So the first thing would be to draft a few paragraphs I think (types are needed for OM, OCD, STS, and NTNs when it's defined.
these would be the types I would have thought about as well. The only one I am not sure about is STS. It seems overly specific, especially in light of the fact that as objects STS types are OM Objects, just used in a special form.

[jbs1]

migrated from Trac, where originally posted by polx on 1-Aug-2010 3:04pm

grmbl, that Trac doesn't receive mails.

Here's a mail I sent to David yersterday.

David,

Le 31-juil.-10 à 18:22, David Carlisle a écrit :

http://www.w3.org/2002/06/registering-
... I think though that that's a special w3c/ietf arrangement and
probably you would have to do the full registration procedure for a
non w3c spec.

But as Christoph noticed, it seems they simplify.
I've seen similar registrations-request on ietf-types with documents
backed by other societies.

Incidentally the reason we didn't register a mime type in the first
place (or after the +xml convention was formalised) was that (at the
time, at least) the effects of using a specialised mime type were
almost all bad.

It is not my observation and I beg you see the zillion media-types for
TeX or Maple around the planet!

Specifically that systems that could display OpenMath objects
or CD files (using generic XML processing) would not know the mime
type (even if it was registered) and so would just offer a file/save menu.

I think it is correct that it is annoying but UTIs address that.
I'm not sure you can, for a non-developer, offer more than save with a
format that you realize is xml but otherwise don't perceive the
semantic.

paul

[jbs1]

migrated from Trac, where originally posted by clange on 16-May-2014 12:59am

I do not have the resources to push this myself, but I think it's still important that we eventually get a MIME type registered.

[jbs1]

migrated from Trac, where originally posted by polx on 20-May-2014 6:14pm

I am happy to take this over as I understood how it works with MathML3.

For me to go and submit the media-type proposals, I need our standard in draft form to specify the media-type registration using the same vocabulary as what the IETF requests, as specified in http://www.rfc-base.org/rfc-6838.html.

Which encoding do we want to register?

• OMOBJ
• OM-CD
• binary openmath?

thanks in advance.

paul

[jbs1]

migrated from Trac, where originally posted by david on 20-May-2014 7:30pm

well first we need to agree that we want a mine type, I don't really think anything has changed in years since comment 7

[jbs1]

migrated from Trac, where originally posted by clange on 2-Jun-2014 8:40pm

Replying to [comment:7 david]:

Incidentally the reason we didn't register a mime type in the first place (or after the +xml convention was formalised) was that (at the time, at least) the effects of using a specialised mime type were almost all bad. Specifically that systems that could display OpenMath objects or CD files (using generic XML processing) would not know the mime type (even if it was registered) and so would just offer a file/save menu.
Then why does, e.g., Firefox display http://publications.europa.eu/mdr/resource/authority/file-type/skos/filetypes-skos.rdf, which has MIME type application/rdf+xml, as XML? Because application/rdf+xml is hard-coded into Firefox, and application/whatever+xml is not? Or because Firefox generically supports application/*+xml?

[jbs1]

migrated from Trac, where originally posted by clange on 2-Jun-2014 8:43pm

Replying to [comment:12 polx]:

I am happy to take this over as I understood how it works with MathML3.
However note that David mentioned [comment:7 above] that for W3C recommendations the registration procedure is easier because of a special agreement.
Which encoding do we want to register?

• OMOBJ
• OM-CD
  These two would in any case be easy: application/something+xml, e.g. application/openmath+xml or application/openmath-object+xml for OMOBJ, and application/openmath-cd+xml for CDs.
• binary openmath?
  For this we'd have to make up something, e.g. application/openmath-binary.

[jbs1]

migrated from Trac, where originally posted by polx on 3-Jun-2014 6:49am

The agreement, as far as I could see, is not needed to get a media-type through.
I've seen on that list (https://www.ietf.org/mailman/listinfo/ietf-types) quite many registrations whose declaring body was not a big organization and all they need a somewhat traceable declaration correctly included in a published spec.

I think the proposals above (with a "-") are likely to go through. We still have some chances to ponder that now, later no more.

application/openmath-binary is very likely to be ok too.

paul

[kohlhase]

moved to OpenMath/OMSTD#35