W3C home > Mailing lists > Public > uri@w3.org > June 2016

Re: File URIs, home and relative paths

From: Jason Dusek <jason.dusek@gmail.com>
Date: Sun, 12 Jun 2016 00:39:38 +0000
Message-ID: <CAO3NbwPRKDakW9RRvVS4DVZCVq0FTiheerNZHwjiJknBsJ15sw@mail.gmail.com>
To: Matthew Kerwin <matthew@kerwin.net.au>
Cc: uri@w3.org
On Sat, 11 Jun 2016 at 16:23 Matthew Kerwin matthew@kerwin.net.au
<http://mailto:matthew@kerwin.net.au> wrote:


> On 12/06/2016 5:57 AM, "Jason Dusek" <jason.dusek@gmail.com> wrote:
> >
> > It is strange to me that the draft neither provides for home and the
> present directory semantics, nor clearly speaks to the issue (in a section
> titled "Special Paths in UNIX and File URLs" or something similar). Perhaps
> it would inspire future work in this area.
> >
> > Kind Regards,
> >   Jason Dusek
>
> In URI space current directory references are achieved using relative
> references. "./foo/bar" is a valid relative reference, which can be
> resolved against a base URI that represents $PWD.
>
This works out strangely in practice because you can’t write
file://<something> to get it.

User home directory and tilde expansion both, AFAIK, come from the shell,
> not the file system. I could add a warning that a relative reference that
> starts with "~/" (or "~username/") won't resolve against a base URI the
> same way bash would resolve an equivalent path; but since no other URI
> scheme special handles '~' is anyone going to find this valuable?
>
Well, I have not been collecting statistics over the years — but many a
time have I seen confusion and consternation with file URLs. It seems
valuable to mention a feature that might be mistakenly expected but is not
provided for.

It is worth pointing out that there are variety of “pseudo URL schemes”
that have grown up around Git which implicitly rely on resolution relative
to . or ~ on a remote server.

Perhaps people will put some thought into an approach as a result.

Cheers
>
Very Best,

Jason Dusek
​
Received on Sunday, 12 June 2016 00:40:16 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 12 June 2016 00:40:23 UTC