W3C home > Mailing lists > Public > uri@w3.org > September 2004

Re: more 'file' suggestions for draft-hoffman-file-uri

From: Mike Brown <mike@skew.org>
Date: Tue, 21 Sep 2004 17:50:32 -0600 (MDT)
Message-Id: <200409212350.i8LNoWPB071168@chilled.skew.org>
To: Frank Ellermann <nobody@xyzzy.claranet.de>
CC: uri@w3.org

Frank Ellermann wrote:
> >     A file URI usually takes the form:
> >     file://<host><abs-path>
> 
> But that's strange.  file://localhostC:/config.sys of course
> doesn't work

That's a bad example, but first, consider this.

This was ambiguous:

file://<host>/<path>
<path> = <directory>/<directory>/.../<file>

It seems to be a syntax specification. Yet, <path> cannot be <path> as defined 
in rfc2396bis. And the definition of <path> here is expressed in terms of 
platform-specific file system conventions. It is advising the reader on how to 
construct the path component of a file URI from the things that might be in 
what a file system considers to be a "path".

I feel it should not attempt to do both. Syntax rules should be separate
from advice or examples of how the syntax components map to the naming
conventions of a file system.

So I am leaning toward making this be a syntax definition only. That being the 
case, I feel strongly that it should not be in any way in conflict with 
rfc2396bis, so I feel it should be expressed *in terms of* rfc2396bis (or in 
terms of difference from it).

I will have to revise my definition of <abs-path>; I think it will typically 
match path-abempty or path-noscheme or path-absolute. File URI producers 
should be discouraged from using path-absolute, though.

In any of these 3 cases it must start with "/", so that's why your first 
example was not relevant. The rest of your examples seem to be rooted in 
assumptions that you are making about how the "path" on your file system maps 
to the "path" of the URI. This is further argument in support of including 
such info in the standard. I just feel that it is not good to clutter up the 
syntax definitions with that info.

> Paul's syntax is better.  OTOH your explanation of "host"
> is probably better, especially the note:
> 
> > A file URI is not restricted to this syntax or
> > interpretation, however

Yeah the point of that is just to underscore the "usually"
in "A file URI usually is of the form..." - we need to be
clear that this simplified syntax is not meant to supercede
the generic syntax that rfc2396bis requires be supported.

> Maybe the "host" of file://host/stuff is not necessarily
> empty, "localhost", or another FQDN, the //host/stuff
> could be a UNC path.  I've never seen this, so maybe it's
> wrong.

IMHO the standard is here to decide what is right and what
is wrong. :)

-Mike
Received on Tuesday, 21 September 2004 23:50:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:34 GMT