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

>The "vision" is that everything on the Web, including namespaces,
>is named by URIs, and that the same rules for URI-reference
>interpretation apply to all resources.

The problem is, those rules of interpretation yield the wrong behavior for
namespaces. Consistancy is great -- but can be overdone, and I think this
is such a case.

Element and attribute names aren't URIs, so clearly not every name on the
web need be a URI. Even the "semantic web" concept doesn't change that; it
says only that these names should be _associable_ with a URI. If they're
associated with a namespace, and the namespace is associated with a URI,
the goal is met.

That can be done without breaking namespaces by adding (for example)  an
xmlns-binding:whatever attribute which would associate the namespace (via
its prefix) to a "real" URI/URIReference  with all the standardized
behaviors. Under this scheme, it honestly wouldn't matter whether the
namespace name is a URIRef or not... except that we've already established
that practice, and it does give us the namespace-management benefits which
were the reason URI syntax was adopted for namespace names in the first
place.

>The root of the trouble, IMHO, is that the problem is essentially
>moral/aesthetic, not technical at all.

It's both. On the technical side, we have "does the proposal yield a usable
Namespace system" -- which I don't think Absolutized achieves.. On the
moral side, we have "does the proposal violate consistancy and/or user
expectations," which you suggest can only be met via Absolutized. How do we
reconcile this?

The literal/resolve-if-desired/bind-if-desired solution does seem to meet
all the technical requirements. I grant that it isn't maximally pretty. But
short of discarding the namespace spec and redesigning it from scratch, I
don't think we're going to do better.

______________________________________
Joe Kesselman  / IBM Research

Received on Tuesday, 16 May 2000 17:25:35 UTC