W3C home > Mailing lists > Public > xml-uri@w3.org > May 2000

Re: A little courtesy, please

From: Dan Connolly <connolly@w3.org>
Date: Tue, 23 May 2000 03:05:49 -0500
Message-ID: <392A3BDD.2ACCACAB@w3.org>
To: Tim Bray <tbray@textuality.com>
CC: xml-uri@w3.org
Tim Bray wrote:
> I am growing increasingly short-tempered at some of the shabby rhetoric
> being used in this debate.  For those to whom this is not completely obvious,
> it is possible to be very nervous about applying full URI semantics to
> namespace names without:
> - being against URIs
> - being against relative URIs
> - being against having dictionaries in libraries
> - being against RDF [* see below]
> - being against the Web Architecture

It is not at all completely obvious how you can say that while
also saying:


4. It is wrong to compromise the basic utility of namespaces by imposing
   strict URI-ness on them 

5. The use of relative URI references as namespace names is wrong and
   dangerous and should be, at the least, deprecated"

	-- Tim Bray
	Tue, 16 May 2000 01:57:40 -0400 (EDT)

Either namespaces are web resources in every sense of the word,
and hence any sort of URI reference the author chooses
may be used to point to them, or not. And if not, the design
of XML namespaces doesn't agree with web architecture, which
is that important things should be treated as web resources
with all the rights and obligations thereof.

Your point #4 seems to say quite clearly that you don't believe
dictionaries (namespaces) belong in the library (the web of

I prefer to discuss these issues in black and white terms
using test cases ala the two bats, but your points 4 and 5
are rhetorical, not black and white, and I could not
disagree with them more strongly, and evidently TimBL
felt similarly. I don't know why you expected other than
a rhetorical response. You can call it shabby if you
like, but it struck a chord with at least a few people,
and I think it made certain things more clear.

> This kind of argument is unworthy of those advancing it and might tend
> (dangerously) to cause the short-tempered to blow off the rest of the
> points they are trying to make.  Hard though this may be to believe, it
> is possible to be worried, as stated above, about forcing full URI
> semantics on these things, and at the same time, to be worried about
> Dan's two-bats conundrum or about the fact that the following, as namespace
> names, are not equivalent per the namespace rec.
>  http://foo.bar/a/b
>  HTTP://foo.bar/a/./b
> So, like, guys, we understand what you're saying.

That's not at all clear. The above are distinct per the
URI spec too, so I don't see what there is to worry about.
Once a URI is in absolute form, it's perfectly reasonable
to use strcmp() to distinguish them.

> The fact that any of us are still reading this river of tears, 383 messages
> in, should serve as evidence enough that we care a lot about figuring out
> what the right thing to do is and how to do it.   -Tim

I'm glad you agree this is an important issue.

> [* re RDF] - the notion that sticking to what the namespace rec says
> tends to destroy RDF is just totally 100% incontrovertably vacuous.
> RDF has chosen to say that when you're in RDF space, namespace names
> have to be used in a particular way.  Some of us may have trouble with
> the syntax engineering (#, feh) and some of us may worry that the RDF
> way doesn't provide enough indirection, but nothing they do contravenes
> the namespace spec in spirit or in letter.

I largely agree with this, but I cannot agree that treating relative
URI references as namespace names without absolutizing them is in
the spirit of RDF.

>  And just to be consistent: I
> think that anyone who's using RDF and starts using relative namespace
> names is just asking for trouble.  Because, among other reasons, RDF is
> (I hope) going to end up embedded in lots of other XML vocabularies and
> shipped around the Web in unpredictable ways. -T.

Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Tuesday, 23 May 2000 04:06:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:58 UTC