[
Lists Home |
Date Index |
Thread Index
]
On Thu, Jul 17, 2003 at 04:42:40PM +0100, Dave Pawson wrote:
> At 08:09 17/07/2003 +0000, collin@seu.edu.cn wrote:
>
> >Who provide for the syntax for "file:///c:/" ?
>
> Some ****.
> I played with it, .... and came to that conclusion
> http://www.dpawson.co.uk/xsl/sect4/uriIncl.html
>
> No wonder tag cant decide how to describe a uri.
> Standards???
> or
> confusion?
Well, that part of our infrastructure is an abomination IMHO.
Sorry my code will fail on
file://c:/sgml/uriincl/uriIncl.xml
because from the small semantic I can extract from RFC 2396, it's
a file scheme with a c:/ authority, and to me C: is neither
a server nor a registered component.
The only definition I found of the file scheme is RFC 1738
http://www.w3.org/Addressing/rfc1738.txt
which obviously shows its age (and is obsoleted by 2396 except 2396
does not define specific scheme). 1738 states
----
A file URL takes the form:
file://<host>/<path>
----
it's also defined somewhere (can't remember maybe 2396) that
<scheme>:///path, i.e. without the authority is equivalent of
accessing teh service on localhost, hence
file:///c:/sgml/uriincl/uriIncl.xml
can be mapped to a given semantic.
Now to make things really crazy, on windows, depending on which set of
tools (MS, CygWin, ...) you compile your code against, file path access
semantic changes. My last rant is that nothing defines file accesses relative
to the current directory (i.e. the relative filepath mechanism in the
POSIX filesystem sense) using file:// URL .
In a nutshell when trying to design file access on Windows based on
URI then either you try to get a relatively compliant implementation and
a lot of users complains, or you try to accomodate everything and
it's just a pile of unreliable heuristic (hum is that \ a path separator
or a backslash character...).
Solution:
- avoid the Windows platform for web stuff
or
- educate your users (good luck)
or
- get someone to clean up that mess by redefining the file
scheme in a new RFC (good luck too)
Really depressing ! All bets are off in that area :-(
Daniel
--
Daniel Veillard | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
|
