Mechanism, not policy [was: Attribute uniqueness...]

keshlam@us.ibm.com wrote:
> 
> >TimBL initiated this whole brouhaha because he was disturbed about the
> >failure of namespace names to identify useful retrievable information.
> 
> I'm not sure that _was_ Tim's intent.
> 
> My understanding is that what he's driving at is more abstract -- the
> concept that a namespace, to have an "identity" in the Web world, should
> have a URI. Whether that URI can be dereferenced, or ever is dereferenced,
> is actually a secondary matter; this is a statement about how the names of
> things are to be managed, and has to do with meta-issues such as
> "ownership" defined by some classes of URIs. Making the namespace's
> identity be a URI taps into that work.

Yes, that's the point exactly, as I see it (and, I expect, as Tim sees
it).

> If we accept that premise, then the assertion that a URI Reference really
> ought to be a reference to a family of URIs (with the specific one selected
> at the time that the reference is examined, in context) makes a bit more
> sense. It explains the fact that ..\light lights a bulb in one case and a
> fuse in another as being an _intentional_ result of the decision to use a
> context-dependent reference in the first place. The answer "if it hurts
> when you do that, don't do that" really is consistant with this model.
> 
> Of course, making sense, being desirable, and being wise may be three very
> different things.

Quite. To say "using a relative URI reference is almost always stupid
and risky, so don't do that" is a fine policy for practitioners
to adopt, if they so choose.

To go further and say "... so let's prohibit it from the syntax"
is to gum up the mechanism with exceptions based on policy.

  "It is important to keep in mind
   that the protocol is intended to provide mechanism, not policy."

	-- Robert W. Scheifler, June 1987
	http://www.ietf.org/rfc/rfc1013.txt


-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Wednesday, 7 June 2000 12:47:26 UTC