A path is the route to a file, in other words, its name and the names of all its containers in order. On Unix systems (including Mac OS X), paths start with /; on older Macs, with anything; under Windows, with something like C:\. For instance, as I write, this file’s path on its server is .

A URI (sometimes called a URL) is a path that includes the name of a server, as though it were just another directory. Thus URIs work as web addresses, because your browser can tell what server to connect to, and the server can tell what file to send back.

Here’s a color-coded imaginary URI:

http://www.example.com/plants/cacti/sajuaro.html

• Gray is the protocol — here, the Hypertext Transfer Protocol — which defines how the browser and the server will communicate.
• Green is the domain name, which points to a particular computer.
• Blue is the directories which lead to the file we want to see.
• Purple is the file’s name.
• Red is the file’s suffix.

There are a few things to worry about in this system. What about capitalization and spaces between words? Do we need or want the suffix? [closure, baby]

I think the biggest mistake anyone ever made with paths was introducing file extensions. There are several ways to tell whether something in an HTML file:

1. by content: seeing whether it parses or validates as HTML (or maybe just checking for a doctype declaration as the first bytes)
2. by metadata: asking the filesystem for the file-type attribute
3. by suffix: looking for .html at the end of its path

An attributed filesystem relies on the co-operation, or at least lack of suck, of its users. The filesystem shouldn’t be expected to have . A file’s creator, last modifier, or direct user-agent (e.g., Change File Type inspector)

The ability to hide file extensions is a relief, but not a solution. Supposing two files identical in every way except file extension are on the desktop, how am I to tell them apart? If by their icons, suppose the thing responsible for setting icons doesn’t recognize either extension, or that one has no extension at all. Okay, I guess it could hide only known extensions. But surely it will not hide them from the C library’s fopen() function, and therefore third-party tools will have either to rewrite or to see a world different from the user’s. (In other words, how do I tell a text-only program which of two visibly different but apparently identically-named files I want?)

So just hiding extensions is kind but not wise. The power of the idea of paths – a simple and useful abstraction from the physical filesystem – is more important than avoiding a minor eyesore. I think it can be both elegant and pretty, though: all we need is more metadata. As it is, files are associated with more than a path: modern systems keep track of their kind (file proper, link, directory, etc.) creation and modification times, and owner and permissions. The old Mac also stored two four-byte fields which defined the file’s type and parent application; this was how icons were assigned, and so forth.It worked really well, and the only thing I’d change would be to make the field larger and thus less arbitrary. Some of the four-character codes were pretty bizarre: I recall R*ch for BBEdit, MOSS for Navigator (probably a reference to the Mozilla, which was an early mascot), and Eric for some system files.

Anyhow, a new system could use the Mime types or just about anything else, and we’d all be happy. You could even have an optional or graphical-only translation layer, so appending .html would changed the filetype metadata (and, perhaps, revert to the old name – heh heh).

That