OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: file: URIs and MS Windows

[ Lists Home | Date Index | Thread Index ]
  • From: tpassin@home.com
  • To: <xml-dev@xml.org>
  • Date: Tue, 2 May 2000 09:16:32 -0400

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
> > >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,
> > 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/


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS