Proposal: replace generic *.json extension with specific extensions for each file type

[ryan-lp]

We currently use the same .json extension for both chapters.json and transcript.json which means that we can't define a deterministic mapping from file type extensions to MIME type. One use case is that it allows you to configure a web server to automatically set the Content-Type response header based on the file name extension, but also allows desktop applications to associate the correct application to open a file based on its file name (e.g. double clicking on a chapters file could some day open a desktop app for editing chapters).

I think we can come up with a specific extension for each different file type, and I also think there should probably not be an issue with continuing to support the original .json extension for backwards compatibility, because current podcast apps will open whatever filename is in the link.

[theDanielJLewis]

I think SRT is the more widely supported transcript type.

By the way, there is no “chapters file.” It’s an episode metadata file that can contain many things, including chapters.

[ryan-lp]

Whether I agree or disagree with those points, they have no bearing on the proposal :-)

Before JSON, XML tended to result in a similar practice of using an .xml extension for every file type. It was generally not an issue for configuration files only edited by programmers, but in the case of files that are intended to be edited using authoring tools or viewed with specific viewer tools, it helps to have a specific extension so that that extension can be associated with the correct application. A popular example of this is the MS Word format which, once they switched to an XML-based format, they chose a filename extension of .docx. Another common example being the SVG (Scalable Vector Graphics) format which is an application of xml, but uses the .svg extension rather than the .xml extension so that it can be easily mapped to a content-type by web servers, and also so that it can be associated with the correct application on desktops.

[theDanielJLewis]

Thanks for the clarification!

So am I understanding correctly that you are proposing something essentially like the following (but compressed)?

• *.episodejson for episode metadata (chapters, notes, image gallery, etc.)
• *.transcriptjson for transcripts in JSON format

[ryan-lp]

The tradition for filename extensions is to use 4 letters or less.

JSON Chapters format (spec)

Suggestion: *.jchp

(standing for Json CHaPters)

JSON Transcript format (spec)

This format has problems that I think are preventing adoption (e.g. variable granularity), and those same problems also prevent me from coming up with a coherent extension for it. But one example might be *.jcap (Json CAPtions).

Channels/networks (discussion)

There is talk of introducing another JSON format for channels or networks, and if that time comes (which I hope it doesn't), it would similarly be good to give it a distinct filename extension so that it can be easily mapped to its own MIME type on web servers.