Posted by Jerry Stuckle on 11/10/06 13:36

John Dunlop wrote:
> Jerry Stuckle:
>
>
>>[A URL] describes a resource.
>
>
> Well, URLs by definition _locate_ network locatable resources,
> specifically 'information resources', as one W3C Recommendation calls
> them; whether or not the string of characters in a URL describes in
> some human-recognisable way the resource it points to is up to you the
> URL owner.
>
>
>>One of the types of resource it describes is a file.
>
>
> The crux of the matter is that if a URL points to a particular
> representation of a resource - e.g., HTML, XHTML, plain text, RTF - and
> this is reflected in the URL in the shape of suffixes, when you change
> the representation or add another representation and negotiate between
> them you have to change the URL to keep it meaningful. For example, if
> you originally publish a restaurant menu in plain text, ending its URL
> path with '.txt', but later publish an HTML version and negotiate
> between the two, the '.txt' at the end of the URL path is counter
> intuitive for the HTML version.
>
> You could solve this in one of two ways. One, publish two different
> URLs, one ending in '.txt', the other in '.html'. However, this
> undermines the value of the resource since it divides the community
> into those who refer to the plain text version and those who refer to
> the HTML version while for everyone the resource is conceptually a
> single entity; c.f., Metcalfe's Law. Two, instead of seeing the URL as
> pointing to a particular representation of the resource, see the URL as
> pointing to the resource itself - the menu in the example above. That
> way, when you change or add representations, you don't need to change
> the URL because it identifies the resource itself rather than any
> particular representation. Which way you choose depends on what you
> see the URL as pointing to.
>
> If you choose the second way, URL suffixes have no place in URLs
> because they add nothing to the identification of the resource and they
> run afoul of the principles of length (shortness), meaningfulness, and
> persistency. I regard as weak the counter argument that if URL
> suffixes are a de facto standard, then all URLs should include them.
> The BBC, for example, publishes URLs without suffixes, and URLs without
> suffixes occur in traditional media. Even if URL suffixes are a de
> facto standard, the suffix-less ones are more user friendly.
>

As I said - I see it pointing to a resource. But one size does not fit
all. There are different types of resources on the internet.

For instance, all of my printers are tcp/ip ready. All of them have
URI's associated with them, and I print to a URI. But I don't try to
load one in my browser - it's the wrong type. I also have system
backups on an internet server. These are also URI's - but I wouldn't
load one in a browser. And my email servers are another type of URI.

When dealing with file URI's, the file extension is meaningful. Maybe
not to the user, but definitely to the server. Servers make different
decisions on how to handle different file extensions for performance
reasons. You wouldn't want to try to run a .asp file through a .php
parser, for instance. And you wouldn't want to try to run everything
(including static pages) through both. It would bring any reasonably
active server to its knees.

Theory is good. And it even works in low volume sites on low activity
servers. But the overhead quickly becomes more unmanageable in more
heavily used sites. I find ignoring this fact to stick to an ideal is a
very weak argument.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[Back to original message]