Re: Relative URLs and URNs

At 11:12 am 29-01-97 -0500, Keith Moore wrote:
>> If all URNs are syntactically opaque URLs, are we not imposing a
>> restriction on all URNs that they cannot use the relative URL mechanism?
>
>Yes, but this is a feature.  Relative URLs wire relationships between
>resources into the resource name itself, which hurts long-term persistence.

Keith, you make a good point that relative URIs are limited in persistence to
the persistence of the two URIs.   But Dan La L was right too in pointing
out that 
the relative URI may in fact be longer lived than the absolute. So it is
not a clear case.
So one should not forbid them.  Disabling a consistent function in a special
case is normally a kludge, not a feature.  In general, specs which tell
people what to do against their better judgement are typically suspect too.
This would be something to put in a usage document: "When relative
URIs are considered harmful and when not"

[...]

(Dan L:)
>> Another advantage of relative identifiers is that they are shorter
>> than their equivalent full identifiers.  

Yes.

>It's not necessarily true that a URN is shorter than a relative URL.

(That wasn't what Dan said (that relative URIs in general are shorter than
absolute URIs) , I  assume it's the reverse of what you meant
to say, that "It's not necessarily true that a relative URL is shorter than
a URN" )

>Since URNs don't need to be human-meaningful, they can be allocated
>from a denser space than is typical for URLs.

There is nothing to *stop* URLs being allocated extremely densely.
Following my comment in Leslie's message, it is a social issue that
URLs are typically not dense and not always persistently maintained.

Since HTTP URLs don't need to be human-meaningful, they can be
allocated from a denser space than may equally become typical for URNs.

>Keith

Tim