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.