file: URIs (was: Minutes URIREV04 BOF)

At 20:55 08/08/04 -0700, Larry Masinter wrote:
>'File:' it deeply broken.  Is it worth trying to fix, given how widely
>deployed the broken implementations are?

My own sense is that while there is lots of file: software out there, 
there's still lots more to be written, and that an attempt to clarify the 
relationship between file: URIs and actual file systems for future 
developers would be most useful.

Also, I think that file: is less broken (in practical terms) then the 
specification mess would suggest:  as noted elsewhere, relative forms still 
seem to work quite nicely.

>Are we prposing new protocol work?  It isn't worth doing new protocol
>work if the people responsible for the deployed software aren't going
>to participate in the process. Would having a spec be a forcing
>function? Should we just describe the way in which current
>implementations differ?

I've raised questions about this precisely because I've been writing 
software that uses file: URIs in software as the way of integrating local 
file access with web resource access (e.g. in XML parser logic to access 
external entity definitions).

As an implementer, my main concern has been that by applying 
transformations to URIs that "look like" they contain Windows drive letters 
in order to get a filename (e.g. transforming 
"file://localhost/C:/dir/file" to "C:\dir\file" results in a small number 
of URIs that are not usable (employing portable code) on a Unix system.  I 
don't know what happens on Mac platforms.

>Larry thinks there's some common practice around UNC pathnamess &
>drive letters. It would be useful to document what's there. And people
>can use file: URIs interoperability as long as they're really relative
>URIs based on files that are selected in some other manner.
>
>Martin thinks it would be useful to give implementors something
>they can converge on... perhaps within 5-10 years.
>
>Larry suggests describing common practice and stopping there; if
>convergence is desired, all of the implementors can pick, say,
>"Section 2" and recommend it. We can even make that an editorial
>suggestion in the specification.
>
>Is this 'a description of what is out there', but 'not a description
>of what people have to implement'?

I think _anything_ would be better than nothing.  But I also think that 
having a proposal with some force of recommendation would be useful in the 
sense that Martin suggests.

#g


------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Received on Monday, 9 August 2004 09:35:09 UTC