http URIs as names and scalability

I also think there is an architectural issue about
the use of URIs as names that belongs in the W3C
architectural guide. It's a scalability issue:

It would be very bad if the web architecture REQUIRED
or even ENCOURAGED implementors of widely used media
types to actually go off and GET the namespace URI.
So a web design that had browsers actually trying
to connect to and "GET /1999/xhtml" whenever
they tried to open an XHTML document ... well, that would
be a bad design.

We might just wash our hands and say "well, that's a
bad implementation", but the implementation might not
look so bad if you're just testing it out with a couple
of hundred beta-testers. And perhaps there are web designs
where the scalability issues and requirements aren't
quite as easy to analyze. There may be a very good reason
for using namespaces like "" if what
you're really saying is "I don't have the resources to
run a web server with enough bandwidth to handle as
many hits as I expect I'll get from people poking at
this URI.

If someone doesn't have a web site they can guarantee
to be around for more than a few months, can they not
make up namespace names? If I want to buy a 'web hosting'
site to use as my namespace name, how long a contract must
I buy to be able to say that I've "put something at the
URI of the namespace name". Six months? Ten years? Do
I have to buy the contract for as long as the specification
is valid?

If your web site contract depends on bandwidth used,
how much bandwidth should I reserve for my "namespace
name" URI? Should I expect "one hit from every developer
per month while they're developing an implementation"?
Or "one hit at boot time for every user"? Or zero hits?

By making the names look like something that should be
retrievable, it creates an attractive nuisance: something
that you don't really want everyone trying to connect to
all the time, but no way to discourage or prevent it.


Received on Saturday, 12 October 2002 20:13:27 UTC