File extensions on the web

This is a very trivial question, but it's something for me to let my mind veg out about for a bit while I take intermittent breaks from writing a philosophy paper for my final exam.

File extensions:

1. Files on the web generally shouldn't have extensions.
2. If they do, it should be reflective of the contents of that resource, not the technology that produced the content. So, while '.php' or '.asp' as an extension is completely unacceptible (unless the resource actually does represent PHP or ASP source code), .html is arguably ok.
3. However, as we've seen with HTML, even an extension that represents the content might not be appropriate in the long term. For instance, content that represents the "same resource" might earlier have been some version of HTML, but is now XHTML. So, the same resource might appropriately have the extension .html, .xhtml, or .xml. Along similar lines, people also argue about what Content-type the resource should be served with. Though, while the Content-type can change easily, the file extension should be much more stable.

This also gets peripherally into versioning issues. This is admittedly a special and particularly dysfunctional case, but if you were to have a '.rss' extension, should you have both a '.rss' and a '.rss1.0' extension for different versions, given how different the formats are? Though, usually different versions of file formats are backward compatible.

However, take that .rss extension. The RSS is really just XML, so shouldn't it just have an .xml extension? But, of course, XML is just plain text (unlike binary formats like jpeg or gif), so it might as well have a .txt extension. Though, .txt doesn't even mean the same thing everywhere, as you can have ascii text, unicode text, ebcdic text, etc.

This episode was precipitated by me considering adding a .xml extension to my RSS feed at http://keithdevens.com/weblog/rss. But, all of the above issues make me just want to ignore file extensions on the web altogether.

Permalink | 3 Comments | id 4877

17:37 (utc-4)