Re: Namespace names and URIs

Tim Bray wrote:

> If we decree, now, that namespace names really are URLs, then I argue that
> the simple design goal of dispatching software to markup based on its
> universal name is grievously compromised.  Here's why:

I suppose you mean "dispatching markup to software"?
  
> As we all know, the same URL can return different resources in successive
> microseconds;

It's a deep (3-beer) question whether in that case you are returning a
different resource, or merely a different entity body (= interpreted sequence of
bytes) for the same resource.

> Given this, if a namespace name is really a URL in all its important
> respects, then the actual contents of the string aren't important at all;
> if I want to use it to dispatch to software in the intended way, I'd really
> have to dispatch based on the contents of the resource that is yielded by
> dereferencing it.
> 
> So for the time being, I think we have to, for the purposes of software
> dispatching, treat namespace names in the way the namespace spec specifies,
> namely as literal strings.

I don't see that your argument leads to your conclusion at all.  Since changing
a relative URI reference to absolute form does not involve the state-of-the-Web
but is a purely syntactic action, what is affected is simply a question of
namespace name identity.  Is the namespace name "foo", declared in two
different documents, the same namespace name or different ones?

> Any attempt to be smart about this leads down
> the slippery slope of having to dereference it and dispatching based on the
> contents.

What slippery slope?  Absolutizing no more leads to dereferencing than
marijuana .... (naaah)

> Relative URI references have many virtues; but they do not include either
> uniqueness or persistence.

They do, however, have the "virtue" of actually existing within documents
that are in being and in compliance with the Namespace Rec.

> - say they're OK because namespace names really are URIs, and relative
>   references are well-proven and known to be good practice.  The tactics
>   here also occupy a spectrum, ranging at the weak end from canonicalizing
>   away such usages as foo/././././bar through expanding them by applying
>   the BASE uri (if you happen to know it) to requiring that the resource be
>   retrieved and the dispatching based on it rather than its identifier.
>   For my money only the last of these is consistent.

I think we are talking about RFC 2396, which includes the first and second
tactics but not the third.
 
> But in the here and now, those of us who build software for a living really
> do need cheap, lightweight ways to name markup vocabularies.  If we have to
> dereference them to use them, we can't use them.  Please don't take them
> away from us. -Tim

Dereferencing is a red herring.
 
-- 

Schlingt dreifach einen Kreis um dies! || John Cowan <jcowan@reutershealth.com>
Schliesst euer Aug vor heiliger Schau,  || http://www.reutershealth.com
Denn er genoss vom Honig-Tau,           || http://www.ccil.org/~cowan
Und trank die Milch vom Paradies.            -- Coleridge (tr. Politzer)

Received on Tuesday, 16 May 2000 15:10:50 UTC