Re: [URN] Re: Relative URLs and URNs

 > Thus spoke Omar Syed:
 > > 2. clients must treat <NSS> as an opaque string (i.e. do not interperet)
 > 
Ron Daniel, Jr. writes:
 > I think assumption 2 is in error. Clients that know the structure of
 > a name in a particular namespace are likely to manipulate it.

I agree.  Clients, of course, can do whatever they want (whatever they
can get away with) anyway, but they have to be able to interpret the
structure of an identifier in order to do as much processing of it on
their own as they can.  Forcing clients (if that were possible) to
always consult a remote server to process the whole identifier is a
sure way to make the system unscalable.

Ron Daniel, Jr. writes:
 > This is the sort of problem I am running into now in our tests, where
 > we have a bunch of HTML pages we are retroactively assigning URNs to.
 > Since those pages have lots of relative links in them, we can either:
 >   1) Make sure our new URNs reflect the same filesystem arrangement
 >      as the pages do.
 >   2) Modify the pages to make all the references absolute.
 > Alternative 1 certainly is unattractive, since a major point of URNs is
 > to provide independence from the filesystem organization du jour.

First, identifiers (relative or not) may *reflect* a filesystem
structure, but it is up to the server whether to look up an identifier
in a filesystem, database, or pass it to a CGI program, for
example.  So it is incorrect to assume filesystems specifically.

But going beyond that, the identier may reflect a hierarchical
structure (filesystem or not) and if you want that structure to be
persistent, you have to arrange that old identifiers are redirected
to the new identifiers, and the old identifiers are not reused for
other purposes.

Redirecting is supported by NCSA httpd, and I assume many other servers.
Instead of sending a redirection back to the client, the server could
handle it itself, especially if the new place is within the same server.

--
Daniel LaLiberte ([email protected])
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/