Re: Are *relative* URIs as namespace nemes considered harmful?

> I meant that the document creator has the choice as to whether to use
> a relative URI and will do it rarely (I imagine) and then
> only when it provides a benefit.

I hope the same thing. Unfortunately, in your scheme the only benefit they
can gain is one unrelated to Namespaces -- and it comes at the expense of
making the document unstable as viewed by Namespace-aware code. This seems
to me to be too high a cost.

>It is inconsistent.  What do you do with documents on different http
servers
>which each refer to "foo"?

If both references are to namespace names, they were intended to be the
same namespace ... as they have to be if a program which is searching for a
particular namespace is to recognize them both, which is FAR more likely to
be the user's intent.

Nobody has yet told me how to perform namespace-aware document processing
if the namespace "foo" means "http://a/foo" for one document and
"http://b/foo" for another.

> What do you do with a documents
> which refers to "foo" and "./foo" in the same document?

If both references are to namespace names, they were intended to be
different namespaces. This is no worse than the fact that
http://foo/bar/./bletch is a different URI from http://foo/bar/bletch. Note
that absolutization does _NOT_ reconcile that difference, even though both
will (usually) point to the same entity if you attempt to dereference them.



> Here treating them as URIs and as strings give opposite results.
> You just can't do that.

That last assertion is precisely what we're failing to agree about.

I don't see us making much progress toward reconciling this. Different base
assumptions plus same data yields different conclusions...



>You either have to ban relative URis or absolutize them.

You're assuming that these names are URIs. If they aren't -- if they're
strings which _may_ contain a URI -- then the other option is still
available.

Received on Monday, 22 May 2000 13:03:34 UTC