- From: Graham Klyne <gk@ninebynine.org>
- Date: Mon, 27 Sep 2004 17:31:03 +0100
- To: uri@w3.org
I've taken a look at the file: URI -01 draft [1], and find no argument with what it says. I would, however, like it to say a little more about recommended practices when dealing with certain system-dependent filenames. I appreciate this might be the start of a slippery slope, but I also feel there are some overwhelmingly common cases (notably MS Windows filenames) where a recommended correspondence between filenames and file: URIs might be offered, corresponding to some body of existing practice, with the goal of setting up a target for convergence of diverse and new implementations. Currently, I consider two use-cases where interoperability would be really useful: (1) using browsers and similar programs to access documents that are stored in local filestores as well as on the web. The main requirement here is that relative URI references work consistently; details of how the base file: URI is formed from a filename are less important for this purpose (e.g. file:///c:/... vs file:///C|/... on Windows systems might be chosen locally). (2) writing software that uses URIs to obtain uniform access to local filestore and Web data. In this case, assuming the same software is to run on different systems, and may exchange URIs with other such software, details of base URI formation are also important (e.g. use file:///c:/... consistently on all Windows platforms). Ideally, but this is probably too much to hope for, a single mapping algorithm might be used across a range of different systems (I have written one for use on Windows and Linux/Unix systems, but at the cost of reserving some obscure file: URI forms, which strictly is a bug). How might this be achieved? I suggest a small number of (non-normative) appendices containing recommended filename<->URI mappings for various common systems. The following is intended to give a flavour of what I think might be said, and to illustrate that I don't think it needs to be very extensive. ... For Unix/Linux -------------- filename->URI: Assume full path from root is given. IRI is "file://" ++ the given local system path, with URI-escaping applied as needed (including to any '?' and '#' characters). URI->filename.: If authority is non-empty, its interpretation is system-dependent. The URI path component is un-escaped and used as the local system path. For MS-Windows -------------- filename->URI: If filename starts with x:... (with 'x' a letter), a leading '/' is added. Convert all '\' characters to '/'. Apply URI escaping as needed (including to any '?' and '#' characters). The URI is formed by append the resulting string to file:// URI->filename: If authority is non-empty, it may be interpreted as a UNC name, otherwise if the path component starts with /x: (with 'x' a letter), strip off the leading '/'. The remaining URI path component is un-escaped and used as the local system path (possibly appended to the UNC component). For MacOS, pre OS X ------------------- [[[I don't know what the naming convention is here]]] For MacOS, OS X and onward -------------------------- [[[is this just the same as Unix?]]] #g -- [1] http://www.ietf.org/internet-drafts/draft-hoffman-file-uri-01.txt ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact
Received on Monday, 27 September 2004 16:32:03 UTC