Thanks for a well though out comment.

I don’t think we are too far away from each other. I agree totally regarding the language, as this is possible to check i.e. the browser-settings. And the language doesn’t change the file format. But language and format-headers are from two different sides – the format is “forced” from the server, while the language is requested by the client.

What I didn’t mention is that I believe it’s good practice to have fallbacks, either by “best fit from what I can sniff – content negotiaton”, or sometimes by directly defined defaults. What I still do mean is that the extension is an important hint to the users when considering what the resource is. And that when data is available in multiple formats it should/could be possible to overrule that by the extension as the URI points to the same data, but we’d might want it in a different format.

It’s alsom important to mention that the software requesting the resource should of course consider the Content-Type-header over the extension.

I’m checking out svnwiki, it seems like a good project that might come handy. Thanks for the links!

Well, those are there for _exactly_ this kind of usage pattern. Tools which don’t support them are borken, don’t you think?

I guess it depends on your notion of a resource: “microsoft.com” could be thought of as a resource, however in practice it is useful to include subaddresses like “msdn” or “/docs/blah.html” when referring to this resource. Similarly, notions such as file format, natural language and character encoding used can be thought of as indexes for projections of a multi-dimensional root resource.

There is a greyish line here that isn’t well defined across the different Internet protocols. The closest we have to a standard would be HTTP, which most would rather not duplicate the “Content-Accept” and “Accept-Language” functionality of when defining their HTTP URLs. However, that doesn’t make doing so invalid.

Including as much specifics of a resource in the URL has several advantages, for example, simplistic software that handles URLs can be trivially taught to address language and encoding variations of a resource without extra code. You can see this today e.g. in the W3C’s feed validator. In this scenario the resource’s projections are often included as child parts of the URL’s path. You can see some examples of this in the GData APIs, or anywhere you’ve ever seen something like “/docs/help/en.html”. Such a subaddress does not occlude the existence of “/docs/help”, in fact there’s no reason why the two styles can’t be used as part of a single scheme.

There are other issues, some theoretical and some practical, but I have no idea where I read about any of this, sorry.

For instance, if the user is loading an image, he shouldn’t have to use different URLs depending on whether he wants to get the version in JPEG or in PNG format. He should be able to just give the URL that uniquely identifies the image; it is the job of the HTTP headers (ie. the content negotiation) to figure out which of the available representations is preferred.

The same goes for the language, he shouldn’t have to switch from ‘index.en’ (or, worse, ‘index.en.html’) to ‘index.es’ (or ‘index.es.html’) to change the language; instead the right headers for picking the language should be used.

For my CMS (svnwiki, http://wiki.freaks-unidos.net/svnwiki) the approach that I’m taking is to not show the format in the URL by default and use Apache’s Content Negotiation module to handle these things smartly. I really like the approach offered by Apache’s Content Negotiation module, where you can say ‘index’ (pick the best language and format), ‘index.en’ (pick the best format, but force that language) or ‘index.en.html’ (to fully specify language and format). This works very beautifully with the ‘Baked, not Fried’ approach (http://wiki.freaks-unidos.net/pre-rendered%20model).

That’s correct – and probably one of the best as it helps with the separation of URL’s and the physical files.

Now, I do not think that it isn’t honest to server “static” file-types with parameters, although I agree that it might seem a little weird as it’s – as far as I’ve experienced – mainly because it’s not what we’re used to. But that’s something I’d like to see change. I think it’s a very good point you’re making there none the less.

You can use that to make static-looking URLS (mydomain.com/graphics/somefile.jpg) which actual point to dynamic data (mydomain.com/graphicserver.php?get=somefile.jpg).

Also, in my opinion, making the scripted/dynamic content look like a static file is OK until it is parameterized. Once you start adding foo=bar parameters, you might as well be honest about it being scripted.

I completely agree with you that the Content-Type is the most important one, especially with regards to the UA’s. And I also agree that the URL’s shouldn’t necessarily (ideally) have to match any real files at all (I see from my examples that it didn’t come through good enough) – but that’s not the real case here. I’m thinking of the URL’s as presented to the clients (which might be parsed as anything you’d like for the servers). UA’s should also completely ignore the file-extension (except for i.e “application/octet-stream” where the extension might provide a hint if none good hints is given by the file-content).

Indeed browsers are some very forgiving creatures.

My intensions with this post were primarily for the users, not the user-agents. In essence I’d like the extension to comply with the content, not define (while it, although, indirectly will if used consistently).

URLs are uniform _resource_ locators; a resource doesn’t have a particular format. That should be obvious: an image could be a JPEG or PNG or TIFF or GIF and yet contain exactly the same data–and thus be the same resource.

Even then, browsers are built to expect cruddy data, so if you feed it an image/png and the image _actually_ is a jpeg, the browser will figure it out from the image.

I don’t believe the extension should define the output format, since the extension is defined on the server which, as you say, could interpret it in different ways.

AFAIK, according to the W3C specs, URLs should be pretty much disconnected from the whole data that comes from it. i.e. You should be able to navigate to http://wobble.blip.com/hooo?haa#hee!!!.xml=woo and the document to render correctly.