Re: The lost meaning of the HTTP protocol in URIs

On Saturday, Sep 13, 2003, at 21:56 Europe/Rome, Stefano Mazzocchi 
wrote:

> why in hell a namespace URI such as
>
>  http://www.w3.org/1999/xslt
>
> is not
>
>  uri://w3.org/xslt/1.0

I've been privately pointed (thanks Ian) to the past discussion on

  http://www.w3.org/2001/tag/ilist.html#httpRange-14

and it strikes me that everything has been revolving on the definition 
on what an HTTP URI really is, when, IMVHO, the simple solution to the 
impasse would be to just suggest to stop using the HTTP scheme for URI 
that cannot be directly referenced.

Yeah, that would basically equate URL and URI for the HTTP protocol, 
but isn't this what 99.99999% of the web users (and 80% of web 
developers) have in mind anyway? [and this would solve the issue on 
"what the hell is a HTTP URI anyway?" that not even the web architects 
can agree upon!]

Besides, let me play Forrest Gump for a second: but what does it mean 
to have a "transfer protocol" associated to something that cannot be 
transferred? yeah yeah, it's just a string, I know, but while machines 
are pretty dumb as semantic analysis, humans have the annoying tendency 
to "analyze" what they read in order to understand it and

  http://www.w3.org/1999/xslt

looks waaaaay too much like a URL not to be one.

This has generated the recurring waves of disagreement between the 
"what should be on that URL" camp and "that is not a URL, dumbhead" one.

For past things, well, URI are contracts and contracts shouldn't 
change, so we are stuck with those http-based namespace URIs that 
confuse humans, but, for the future and before it's too late (Read: 
before RDF starts catching up and every person that has a blog comes up 
with his own namespaced taxonomy using HTTP URI because that's what the 
W3C does), the TAG should do something.

My humble proposal is to come up with a best practice that, basically, 
stops using HTTP for URI that are not meant to be dereferenced. TimBL's 
Car, for example. I proposed the simple "uri:" scheme, but I'm happy 
with anything, rdf: res: abs: or even urn:

It would:

  1) solve the "URI vs URL" neverending debate for HTTP
  2) solve the #httpRange-14 issue, since Tim would not use HTTP URI to 
indicate his car, but would use it to indicate the web page that talks 
about that car.
  3) solve the "what's on that namespace URL" issue (related to #1, but 
slightly different)
  4) solve the "# in HTTP namespaces suck" problem that so many XML 
developers hate so much about the RDF/XML syntax [myself included]

at the expense of some step back from the original architectural 
intentions of abstractness of the URI spec referred to HTTP (which, as 
the Forrest Gump in me mentioned above, sounds rather counterintuitive 
anyway).

Now, since this is obviously too simple for me being the first one to 
propose this, what am I missing?

--
Stefano.

Received on Sunday, 14 September 2003 12:13:46 UTC