Closed ryan-lp closed 1 year ago
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.
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.
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
We currently use the same
.json
extension for bothchapters.json
andtranscript.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 theContent-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.