Re: file: URI scheme

Hi Mike.

Thank you again - your reply post has helped solve the remainder of my
issues with file-uri-01 draft.

In Short;  I am +1 with reply solutions. (all positive)

Many thanks :-)
Jason

-----------------------

In Long;

>Jason-
>
>A number of your points have been topics of discussion already.
>I'll address and expand on those here.
>

Oops, sorry but thankyou for reposting back up.  I was unsure if
the issue/s have been resolved.

>>    This scheme, unlike most other URL schemes, does not designate
>>    a resource that is universally accessible over the Internet.
>> 
>> *I am just a little un-easy about the 'universally' bit
>
>Everyone seems to be in agreement that the phrase needs work. Roy came 
up with 
>a more accurate idea of how to get the point across that there is a 
certain 
>conceptual incongruity between 'file' URIs and URIs of other schemes. 
See my 
>summary of the discussion in the first part of 
>http://lists.w3.org/Archives/Public/uri/2004Sep/0075.html
>(up through the quoted text from Roy).
>

I was somewhat confused by that discussion because it refers to other 
schemes
while it seemed to myself that the initial work on the file-uri stated 
otherwise
that file-uri is a kind of 'only OS' related protocol. 

Its a little bit over my head but I do agree with your statements in that 
post 
along with what Roy had to say.  I am kind of suffering a complex about 
it but
feel that your going in the right direction for documenting in anycase.

>> *URL? vs URI?
>
>I assume "URL" was just left over from the previous draft; I'm sure Paul 
will 
>fix it in the next version.
>

Oh I see - it is all good.  :-)

>>   Further, implementers on a single platform have often disagreed
>>   on the syntax to use for a particular filesystem.
>>
>> *I kind of dislike the use of syntax because it relates to part of 
grammar
>> in treating of arrangement of words in a sentence (meaning of n)
>
>I don't feel strongly about it, but would you feel better if it were 
rephrased 
>to something like "Further, implementations on a single platform often 
differ 
>in how they relate file system paths to file URI components."?
>

I kind of like how that is written and feel much better about it that 
way.

>>    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>.
>> 
>> *I think the <path> should be more over related to 'local service' 
>> as in if DNS is accessible and the 'local' system is then resolved 
>> to a FQDN; only then is the <path> is accessible as a FQDN URI with
>> permissions (share/user/both) or other security settings and even 
>> symbolic links on linux/unix**
>
>I don't fully grasp what you're getting at, but I think it's safe to 
leave 
>those qualifications in the realm of implementation-defined behavior.
>

thats a fair choice even if I don't agree - it would I guess be out of 
file-uri scope so I will drop it.

>As for how to describe <path>, as I mentioned before, I feel strongly 
that we 
>need to clearly separate the statements we make about what is being 
>represented by a file URI versus what lexical syntax rules apply in the 
file 
>URI itself. Currently it's all mixed up and I think this is part of the
>problem.
>

I fully agree with you here.  I know a lot of the readers in the list may
be able to understand the current draft but it is hard to get ones mind
around dealing with this issue of the <path> vs other operating systems
given the examples for FQDN, etc.

>>    Some systems allow URLs to point to directories.  In this case, there
>>    is usually (but not always) a terminating "/" character, such as in:
>> 
>>    file://usr/local/bin/
>> 
>> 
>> *file is for file as defined in this document.  I do not see how this 
can
>> make a jump to explain how a linux path is known as a file as any such
>> uri like the above in my view should be treated as a directory booting
>> up another interface to handle the requests (IE swaps to explorer mode).
>
>Hmm. I was about to argue that there is a well-known concept of what a 
>hierarchical 'file system' embodies, and part of that is this notion of 
a 
>containment structure where certain files are actually 'directories' 
which 
>have a parent-child relationship with other directories and files, and 
that 
>unlike regular files, happen to NOT have a well-defined byte stream 
associated 
>with them that can be used as the retrievable representation for 
themselves.
>Neither of those properties of directories preclude the use of calling 
the
>directories Resources that can be Uniformly Identified by a 'file' URI.
>However, perhaps it is worth explicitly mentioning something to this 
effect. 
>

I like the use of the term 'well-known concept' in regards to file 
systems
that have files for directories and so on which are (that can be) localy 
defined on that system - A split between requestor and resolver systems?

>Your other concern, about terminating slashes, is best explained as 
something 
>that may or may not be necessary for purposes of identification -- it is 
>possible for some file systems to have both a directory and a file with 
the 
>same name, leading to the situation where the only way to distinguish 
between 
>them with a straightforwardly mapped URI is via a trailing slash -- but 
that 
>is necessary for resolution of relative references occuring in the 
>representation of the directory resource -- hence the common practice of 
HTTP 
>servers issuing a redirect to force the browser to append a trailing 
slash.
>

I know it is like picking on file-uri vs other protocols for no real 
reason
but I just feel that it needs to be expanded to something like what you
have below:

>How about this:
>
>"A file URI may identify a special kind of file that is actually a 
directory 
>or other containment resource (e.g. a 'folder') in a file system. A file 
URI
>that represents a directory usually, but not always, has a terminating 
'/'
>character, such as in
>
>  file:///usr/local/bin/  [note I added a slash so 'usr' is not a host]
>

thankyou - thankyou - thankyou.  You have taken out two issues in the one
solution here.

That ideal may be correct but I just have no idea without going around 
and
physicaly testing the URI on various linux, browsers, etc.
I do not know how linux handles file-uri in older browsers but from a 
windows
point of view your change to the file-uri above makes more sense in 
reading
and understanding the file-uri protocol.

>The use of a terminating '/' is recommended in the canonical form of a 
URI 
>representing a directory, in order to disambiguate a directory from a 
file of 
>the same name, and for the proper resolution of relative references that 
might 
>appear in a representation as obtained by dereferencing the URI. If a 
file URI 
>without a terminating '/' is dereferenced and the resource is found to 
be a 
>directory, implementations should append a '/', if possible."
>
>I'm not especially thrilled about the ending there, so if anyone has any 
other
>suggestions, please speak up.
>

I liked your ending but am unsure about the 'if possible' part as in:
IE5 swaps to explorer mode and appends the trail of '\' so I feel that
the handle of file should only be of file and not directory in that case
for IE5 – unknown about affects for others.

I have been unsure if these issues goes out of the scope 
when a file is a directory, etc

I would prefer to see 'or if for ?parell? operation to an OS do blah'
However - I can understand where your going here and will accept
current ending mainly because of the 'recomended' statement
in regards to the 'canonical' name conventions.

>> Perhaps adding more URI/URL examples or a table to the
>> draft could solve this issue without it becoming one; even
>> if its a history list - its just a something to work from**
>
>I think the more documentation, the better, but I also feel that How To 
>Interpret A File URI involves just
>
>1. expressing that a file URI represents a resource (file, directory, 
pipe, 
>symlink, device node...) in a file system, by representing (a) the host 
>associated with that resource (by a name, '', or 'localhost'), and (b) 
the 
>resource's name (path) in the file system;
>
>and
>
>2. expressing the relationship between the components of a file URI and 
the 
>components of a file system path.
>
>Rules of equivalence, How To Construct A File URI, and How To 
Dereference A 
>File URI are related topics that can/should be distinguished from the 
>statements related to interpretation. IMHO.

While I find it harder to understand such writings sometimes. 

I do fully agree with you that this method of documenting would be 
better for many reasons as it is more inclusive of describing how 
the protocol should or could operate given a file-URI. 
Including that documentation updates made at a later date would also 
be better without the need for re-testing examples, etc.

>
>-Mike

-----------
Message-Id: <200410110352.i9B3q6hm006303@chilled.skew.org>
In-Reply-To: <20041011.8175256@home.kitchenpages.net>