Catalogue custom mime types in jupyter_client

[ellisonbg]

I talked with @rgbkrk this weekend and there is a strong movement towards frontends (jupyterlab, nteract) starting to use custom mime types to render things in the notebook. I think everyone is supportive of this idea. but we need to have a central place where we at least list the mime types. It isn't exactly a message spec thing, but sort of. Maybe put those somewhere in this repo?

Thoughts?

@rgbkrk @minrk

[rgbkrk]

Right now the two custom mimetypes in nteract are:

• application/vnd.geo+json - GeoJSON spec
• application/vnd.plotly.v1+json - Plotly JSON Schema
  • We end up taking { data, layout }, which is equivalent to a Plotly figure, as this is what plotly.js accepts

There's a branch for vega and vega-lite support, needs to be fleshed out. We've got the workings of a custom mimetype registration system, but haven't exposed a public API for it (yet).

Definitely a fan of talking about these in general, even if I don't know where we're all going next. 😄

[minrk]

I thought I replied to this yesterday, but apparently never hit the button. I think having a short list of things here would be okay, but it's not really part of the spec. It's entirely up to frontends (nbconvert included) to define what mimetypes they support. The supported mimetypes are definitely not part of the protocol, and all mimetypes are valid in the protocol.

Do we want to bless a 'recommended' set of mimetypes? It seems like this belongs in each supporting frontends more than the protocol spec, since each frontend may have different support, and adding supported formats is orthogonal to the protocol.

[minrk]

A mimetype registry seems like a good fit for a wiki-style doc:

• what mimetypes exist
• what kernel-side projects produce which mimetypes
• what frontends support which mimetypes

(of course, liberal PR merges is ~equivalent to a wiki)

[rgbkrk]

I'd be happy with a standalone repo where we merge liberally.

[minrk]

I'm also fine merging such changes liberally here, or on another jupyter docs repo, if an appropriate example is found. Since they aren't protocol changes, they can land any time. If it's not likely to be a big list, putting it next to the display_data message is a fine place if nobody thinks of a better one.

[ellisonbg]

@rgbkrk question - what does the vnd prefix mean?

[ellisonbg]

Is there a standard for naming custom mimetypes?

[ellisonbg]

The decision we reached at the dev meeting is to document this stuff somewhere in the main jupyter/jupyter docs as it really spans all parts of the project and we can push changes quickly apart form subproject releases.

@willingc want to create a place for this in the jupyter/jupyter docs?

[Carreau]

vnd is the vendor tree:

https://en.wikipedia.org/wiki/Media_type#Vendor_tree

However, the registration belongs to the vendor or organization producing the software that employs the type being registered, and that vendor or organization can at any time elect to assert ownership of a registration done by a third party.

type / vnd. media type name [+suffix] - used in the case of well-known producer

type / vnd. producer's name followed by media type name [+suffix] - producer's name must be approved by IANA

type / vnd. producer's name followed by product's name [+suffix] - producer's name must be approved by IANA

prs. and x. also have meanings.

[Carreau]

Also I though we also said that nbconvert/nbviewer should likely be a place where library would register (and enable plugins) to render things online.

[rgbkrk]

vnd is vendor. I'm glad you asked since it looks like geojson's mimetype (per IANA):

• application/vnd.geo+json is now deprecated
• application/geo+json - preferred

[willingc]

@ellisonbg Sure thing re: docs.

@Carreau @rgbkrk @minrk If we can capture the details are/will be here, that would help with coming up with a document to go in the jupyter/jupyter repo. Thanks.

[minrk]

@willingc yup, the idea is to maintain a listing of custom mimetypes that people are using for display. At the most basic, we should have the custom mimetypes and links to whatever project is defining them (may be nteract, may be widgets, may be plotly, etc.). The possible second layer of information is what frontends support a given mimetype (possibly via plugin), e.g. jupyterlab, nteract, nbconvert, etc. If that doesn't seem maintainable, then encouraging individual frontends to maintain their own supported mime-types listing so this page can link to it is another option.