- From: Jason Dusek <jason.dusek@gmail.com>
- Date: Sun, 12 Jun 2016 00:39:38 +0000
- To: Matthew Kerwin <matthew@kerwin.net.au>
- Cc: uri@w3.org
- Message-ID: <CAO3NbwPRKDakW9RRvVS4DVZCVq0FTiheerNZHwjiJknBsJ15sw@mail.gmail.com>
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