xml-dev - Re: file: URIs and MS Windows

[tpassin@home.com]

James Clark  told us about more confusion in Windows file: URLs:

> Richard Tobin wrote:
> >
> > Henrik Frystyk Nielsen <henrikn@microsoft.com> wrote:
> >
> > >The specification of file: is somewhat fuzzy - RFC 1738 has been
replaced
> > >with RFC 2396 which does allow the short format you have above (and
which is
> > >the one I like the best - it also works with "file:/c:/foo").
> >
> > Does it?  The only reference in 2396 I could find was this:
> >
> >   The URL host was defined as a fully-qualified domain name.  However,
> >   many URLs are used without fully-qualified domain names (in contexts
> >   for which the full qualification is not necessary), without any host
> >   (as in some file URLs), or with a host of "localhost".
> >
> > which I take to be saying that "host" in "file://host" can be empty,
rather
> > than that the // can be omitted too.
>
> The relevant production is:
>
>   hier_part     = ( net_path | abs_path ) [ "?" query ]
>
> "/c:/foo" is a abs_path.
>
> > There ought to be a separate (short!) RFC for file URLs.
>
> Yes. Things are not at all well-defined.  There are several issues:
>
And here's another one. According to the newer RFC (2396), after
"<scheme>:", one can have either a hierarchical or an opaque part.  The
hierarchical part uses forward slashes, and has the ambiguities thatt have
been mentioned.  The opaque part can be anything you like, if it uses legal
characters, but the URL parse does not have to try to understand any
hierarchical parts of hte opaque expression.  This ought to mean that you
could insert literal Windows pathnames as used in WIndows.  But how is the
propgram supposed to know if you are using an opaque format?  The RFC sayeth
not. Also, it you used an opaque path, the URL code shouldn't be able to
understand relative paths relative to the first one.

> - absolute paths on windows can be either drive-based (eg c:\home\foo),
> or UNC (eg \\server\share\a\b\c)
>
> - relative paths on Windows work slightly differently from relative
> URIs: for example, if the current directory is \\server\share\a\b\c then
> a filename \x\y\z is interpreted as \\server\share\x\y\z; however, a
> relative URI /x/y/z relative to a base URI file://server/share/a/b/c/
> resolves to file://server/x/y/x which corresponds to the UNC filename
> \\server\x\y\z.
>
> - Windows filenames can contain Unicode characters, but URIs are only
> ASCII; a file URI handler needs to deal with this by unescaping %s and
> doing a UTF-8 to UTF-16 conversion.
>
> James

Tom Passin


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************