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

Re: File URIs, home and relative paths

From: Graham Klyne <gk@ninebynine.org>
Date: Sun, 12 Jun 2016 10:00:58 +0100
Message-ID: <575D24CA.8010100@ninebynine.org>
To: uri@w3.org
On 12/06/2016 03:47, Jason Dusek wrote:
>>
>> Like I said at the very start, I think you're trying to use URLs for
>> something URLs aren't meant for.
>>
> That is by no means clear. Their charter is pretty broad. I would hope that
> ...://... could name everything under the sun.
>

Indeed that is the goal of URIs.  It's not *what* they identify that's in 
question here, but *how*.

URIs do not, of themselves, allow for relative naming.  That aspect is covered 
separately in RFC3986 by "URI references", which are strings that are used in 
contexts that allow them to be resolved to full URIs.  Relative references are 
necessarily processed without reference to any particular URI scheme, and as 
such must be used according to the rules of RFC3986 or interoperability problems 
may arise.


> Relative resolution is strictly hierarchical, always, in all hierarchical
>> URI schemes.
>>
>> URI templates can be used to achieve your non-hierarchical resolution,
>> using variable substitution.
>>
> Could ~ be made part of the RFC? It is an ubiquitous concept. Only at the
> beginning of a path, sure. What are the objections to that?
>

Offhand, I see no particular reason why a file system implementation may not 
choose to implement `file:///~/my.file` or `file///~fred/freds.file` in the way 
you suggest, but I don't see any value in trying to standardize that behaviour.

Behaviour of file: URIs is necessarily dependent on the file system they are 
used with, and in my experience there is no general value in passing full file: 
URIs between systems.  (This as opposed to relative URI references which can be 
resolved against a local file: base URI on the target system.)

Trying to deal with this kind of edge case is something that has delayed 
production of a new specification for file: URI scheme specification for many 
years, and as such leaving us without a formal specification for common and 
uncontroversial uses of file: URIs.  Matthews current proposal is the closest we 
have come to resolving this.  So while I'm not implacably opposed to trying to 
raise and discuss these issues (notwithstanding my views above), I do oppose 
trying to deal with them in the current draft (draft-kerwin-file-scheme) - I 
really would like to see that proceed to reinstate file: as a standardized URI 
scheme, without getting bogged down in features that have not previously been 
specified.

>>> 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.

>> Sure, but you're talking about pseudo URL schemes, not misunderstandings
>> of the file: scheme. This is a whole new scope. Why don't you write a new
>> informational draft that addresses it?
>>
> I am happy to write such a draft; but I bring them up here just to point
> out they face the same issue with respect to home and dot and an accurate
> treatment of them puts them in disharmony with file://.
>

I'm not clear what you refer to here, but if they are in disharmony with file:// 
URIs it may be because they are in disharmony with URIs (per RFC3986).

#g
--
Received on Sunday, 12 June 2016 09:02:47 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 12 June 2016 09:02:48 UTC