- From: Larry Masinter <LMM@acm.org>
- Date: Sat, 12 Oct 2002 17:13:57 -0700
- To: <www-tag@w3.org>
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 www.w3.org 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 "urn:company.com:blah" 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. Larry
Received on Saturday, 12 October 2002 20:13:27 UTC