Re: Sticking another fork in the URI issue

Simon, I'm not clear that you and Roy have a substantive disagreement.

  * You both agree that HTTP URIs (e.g. namespace URIs) that are 404s 
are bad. In other words, URIs SHOULD be dereferencable.

  * You both agree that XML parsers should not dereference namespace 
URIs at runtime. In other words, URIs SHOULD be usable as identifiers 
where that makes sense. (I'm pretty sure you aren't against cache keys!)

I think that you do not agree that HTTP URIs can represent "anything in 
the world." But as Tim has pointed out, agreement on that is probably 
irrelevant. It is doubly irrelevant for you, since you do not like RDF 
and probably do not care if RDF engines get confused about the 
distinction between cars and documents about cars.

Therefore, I think that the thing you disagree about is entirely in the 
realm of theory and terminology. The systems you and Roy would build 
based upon your two theories are probably identical. They would make 
heavy use of HTTP listeners. Those listeners would describe real-world 
objects in HTML and XML. You would say that the identifier identifies 
the description. He would say that it identifies the real-world object.

As an analogy, I might say that the bits in a purchase order numbers 
represent real-world purchase orders and someone else would say: "the 
computer has no knowledge of real-world purchase orders. All you are 
doing is identifying the database record." Okay, you're both right. What 
practical difference does it make?

Let's save our wrath for those who would make identifiers that lack 
listeners and thus cannot answer even the most basic questions: "Who are 
you and what do you know about yourself." That's an architectural 
disagreement that has implications in actual code.

  Paul Prescod

Received on Friday, 11 October 2002 20:02:47 UTC