Dave Before getting into detail, I'd like to say that I do agree in principle with what you said below.
My real issue probably lies in the fact that I have been around computers too long. If I look at archives of my files from the early 90's; when DOS still reigned supreme, I see names like "birthday.inv" and "new-pc.mem" and "tax91.let". We had WordPerfect back then and I used the file extension to indicate what type of document it was. Both the program and I were happy - and neither had to pretend that the file extension indicated what type of _application_ was needed to open that file! The dawn of M$ Windows and its office "sweet", along with long file names, led us down the road of "the file extension is reserved by the OS so it knows what to do with the file". Its only now, as I come to Linux, that I realize what a distortion that was. A name is just a name - the real issue is "what is in the file?". Its a bit like meeting someone, who because he is wearing a suit and tie, you assume is a manager (in fact, he turns out to be the cleaner on the way to his daughters's wedding!). The unfortunate side-effect of the dominance of IE as a browser is that it too has inherited this annoyance from its siblings; this despite the fact that the Internet is the most heterogenous computing environment that exists, and its more than likely that a "." in the context of the web means something quite different from the context of one's OS. When I look at the suggested syntax for REST-based URLs, the authors seem to have the same way of thinking - an example is mydomain.com/hotels/hawaii/list/all -> which we would assume returns a list of all hotels in Hawaii. But is this really different in meaning from mydomain.com/hotels.hawaii.list.all -> would anyone looking at this (excluding a Windows application) really think they are getting some strange "all" file? Are either of these URLs "better" or "more generic" - I think not. The bottom line - I want my "." back - in fact, I want all of them back! :) Derek PS The answer to your question of Microsoft Word file is - neither! The existing URL (poor though it might be) is still a valid one and should be kept. Ideally it should also keep delivering the M$ file since that is what the users are expecting. I might publish a new URL called: http://myorg.org/importantdocs/thisweek.xml or, perhaps better, http://myorg.org/importantdocs/thisweek or even http://myorg.org/importantdocs/thisweek/xml (if I am going to be all RESTy) and deliver the new document via this address. (Of course, I would pursue a parallel course persuading my readers to switch to the new address... and yes, in time, eventually deprecate the old one in some way). The point here is that a URL, especially a widely accessed one, should be able to remain in place if possible, but that this has little to do with a supposed "extension" appearing in the name. PPS I do agree with pretty much everything in the W3C doc - except for the notion that the "." has some special meaning - well, it might to M$, but in the context of designing a URI it is neither here or there (see above example for the REST service). >>> On 2008/10/09 at 12:27, in message <[EMAIL PROTECTED]>, David Legg <[EMAIL >>> PROTECTED]> wrote: Derek, > Please add the reference/link for why URLs in Cocoon should not > have an extension - I know its required, but why is it "bad"? > It's not specific to Cocoon. I only mentioned that because Cocoon's sitemap makes it particularly easy to map a URL without an extension to some content. So in general, it is not a good idea to include extensions in a URL if you want that URL to be useful for a long time to come. The extension may contain implementation specific details which may not always be true. It's generally considered better to publish a generic URL and then let the browser use content negotiation to determine whether it can accept that content. For example, what if your organization regularly published an important document as a Microsoft Word file (*.doc) and published it on your site with a URL of: http://myorg.org/importantdocs/thisweek.doc That's great and you would probably bookmark it and everything would be fine... until your organization decided to move with the times and publish it as a styled xml document. Now you have a dilemma... do you change the url so it contains a .xml extension and risk losing your loyal followers (whose bookmarks no longer work) or do you keep the same url which ends in .doc but is actually an xml file? A great resource for all this is the W3C's own Cool URIs [1] page. There are a lot of other url advocates out there like this one [2]. I suppose though, if you are talking about downloads this might all be a bit academic. After all if you want to download an executable file the chances are it will remain in the same format forever... but you should at least spend half a second thinking about the format of the URL you expose it with. Regards, David Legg [1] http://www.w3.org/Provider/Style/URI#remove [2] http://blog.welldesignedurls.org/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
