Re: URI reference to a directory (what do you want to do?)

> As I understand it, any URL ending with a slash identifies a directory,
> while any other identifies either a file or a directory.

>That would be true for file: URIs.

So I see (from previous answers) that at least in the file: scheme a
trailing slash is the convention to identify a folder URI.
Am I wrong ?

> What is it that you are trying to do?
I'm participating in writing application note on file URLs for JDF in
cip4.org.
The JDF is XML instance that describes printing workflow of a print job.
One of the attributes there serves as the Base URI of the document that
relative URIs reference to.
It is according to RFC2396bis-03 section 5.1.1.

I'm just trying to understand how should one resolve a relative URI
reference according to a Base URI.

If I have a Base URI
"file://e:/f/g"

and a Relative URI
"../h"

It can influence the resolving URI in case the 'g' above is a file or a
directory. (Lets assume 'g' file and 'g' directory exist in "file://e:/f").

In case g is a directory : Resolved URI would be "file://e:/f/h"
In case g is a file          : Resolved URI would be "file://e:/h"

I think the same question regards other schemes as well.

Israel




----- Original Message -----
From: "Al Gilman" <asgilman@iamdigex.net>
To: "Israel Viente" <israel_viente@il.vio.com>; <uri@w3.org>
Sent: Friday, August 29, 2003 4:35 PM
Subject: Re: URI reference to a directory (what do you want to do?)


> At 02:30 PM 2003-08-27, Israel Viente wrote:
> >Can a URI reference to a folder and not a file ?
> >How can you distinguish between a file URI and a folder one ?
>
> So far, we have reiterated that there is no 'folder' concept in the
> top-level URI specification for all schemes.
>
> On the other hand, many HTTP servers offer a function resembling the
directory
> listing which is accessible by the URI
>
>
> ftp://rtfm.mit.edu/
>
> What is it that you are trying to do?
>
> True, for the most-hit URIs of the form
>
>    http://www.example.com/partial/path/
>
> one can request
>
>    http://www.example.com/partial/path
>
> and get the same results.  True, this may take more net traffic and
> wall-clock time for the user, so that when you mean the former, it is
better
> to put it (complete with slash character) as the value of the the
> html:a.href attribute.
>
> But yet you can't do URI-munging transforms to bash
>
>    scheme://node.example.tld/partial/path
>
> to
>
>    scheme://node.example.tld/partial/path/
>
> with certainty that this is equivalent on the server side, if what you
want
> is to offer directory services from your site there are multiple competing
> implementations that will make this available from *your site*.
>
> Current HTTP practice runs against offering directory [a.k.a. folder]
> listings as a matter of site policy.  The data persistence service that
the
> server uses in its computing platform often contains a mix of things like
> HTML files that are wished to be visitable by the public and supporting
data
> that is not wished to be shared in its persistent form.
>
> Current best practice would be to offer somewhere obvious on the site a
> hierarchical catalog of the site contents that works much like a digital
> talking book Table of Navigation[1].
>
> Al
>
> [1]  ANSI/NISO Z39.86, Supporting Documents Index Page
>   http://www.loc.gov/nls/niso/

Received on Sunday, 31 August 2003 05:27:38 UTC