Kjetil Kjernsmo dijo: > Hi! > > Interesting thread! Most things has been said allready, but I'll just > add a little .02 (whatever currency) :-) > > On Thursday 07 November 2002 23:57, Tony Collen wrote: > >> However, later I realize that using file extensions is "bad". Read >> http://www.alistapart.com/stories/slashforward/ for more info on this >> idea.
I know about that. The theory is fine, but in the real world... Are you tried to open a PDF file without the .pdf extension with MS IE 6.0 SP1? It does not work. MS IE relays mainly on the extension of the file to open a pdf file. How we can address this? I already know that Carsten and Mathew in his book dont recommend the use of extension and I agree. But how we can tell MS Internet Explorer about that? Antonio Gallardo. > > The article is interesting, but a little too narrow. Indeed, using file > extensions are Bad[tm] for URIs because you tie the address to a > specific technology, which you may not be using in some years. For that > reason not changing the default "cocoon" in Cocoon URIs are also a Bad > Thing[tm]. > > The authorative reference on this topic is TimBL's rant "Cool URIs don't > change": http://www.w3.org/Provider/Style/URI :-) > > So, using directories for everything is one possibility, and if you do, > make sure to include the trailing /, to avoid useless 301 redirects. > Another option is to use Content Negotation, which is well defined in > HTTP 1.1 (and earlier, IIRC), it's weird that it isn't more widely > used. > > But, both content negotation and using directories for everything are > both solutions that exists mainly because URIs have been so strongly > tied to the file system of the server, and the mentioned article seems > to take as granted that this connection is a necessity, but as Cocoon > proves, this is not so. Just use sensible matches. It also means that > requiring a trailing slash on every URI is a bit too much, I only do > that if there is logically a hierarchal substructure. > > As for the problem of serving different formats to the client, I really > have no good solution. What the user agents should do, was to let the > user easily manipulate the Accept-header, so if the user wants a > PDF-file, he would send only application/pdf in the Accept header, and > the server would know that the user wanted a PDF-file, and send that. > Given that it doesn't exist, appending the type to the URI is probably > not too bad. > > Best, > > Kjetil > -- > Kjetil Kjernsmo > Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer > [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > Homepage: http://www.kjetil.kjernsmo.net/ > > > --------------------------------------------------------------------- > Please check that your question has not already been answered in the > FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> > > To unsubscribe, e-mail: <[EMAIL PROTECTED]> > For additional commands, e-mail: <[EMAIL PROTECTED]> --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
