Sorry Goran, but I really don't agree.

> 
> Here is an excerpt from 1738:
> 
> A file URL takes the form:
> 
>        file://<host>/<path>
> 
>    where <host> is the fully qualified domain name of the system on
>    which the <path> is accessible, and <path> is a hierarchical
>    directory path of the form <directory>/<directory>/.../<name>.

And another excerpt from 1738:
2.3 Hierarchical schemes and relative links

   In some cases, URLs are used to locate resources that contain
   pointers to other resources. In some cases, those pointers are
   represented as relative links where the expression of the location of
   the second resource is in terms of "in the same place as this one
   except with the following relative path". Relative links are not
   described in this document. However, the use of relative links
   depends on the original URL containing a hierarchical structure
   against which the relative link is based.

   Some URL schemes (such as the ftp, http, and file schemes) contain
   names that can be considered hierarchical; the components of the
   hierarchy are separated by "/".

And from 2396:
1.4. Hierarchical URI and Relative Forms

   An absolute identifier refers to a resource independent of the
   context in which the identifier is used.  In contrast, a relative
   identifier refers to a resource by describing the difference within a
   hierarchical namespace between the current context and an absolute
   identifier of the resource.
   Some URI schemes support a hierarchical naming system, where the
   hierarchy of the name is denoted by a "/" delimiter separating the
   components in the scheme. This document defines a scheme-independent
   `relative' form of URI reference that can be used in conjunction with
   a `base' URI (of a hierarchical scheme) to produce another URI. The
   syntax of hierarchical URI is described in Section 3; the relative
   URI calculation is described in Section 5.

> So what did I mean? :) Well, I think I meant that a *file URL* is "a
> weird thing" that can't really be treated in practice based on the RFCs
> for URIs. The tools do lots of "smart things" in order to handle a whole
> range of false file URLs.

I don't think a *file URL* is a weird thing but something that is
translatable to all file systems (and I do mean all, the examples in the RFC
are for a VAX system!). Also there is nothing stopping Squeak defining a new
scheme for mac files or unix files or zip files. Any scheme name that starts
with "x-" is considered experimental.

Russell