Re: use of fragments as names is irresponsible

I totally agree.  I think we got into this mess because people started
to think there was a single mapping function from each URI-syntax
string to the-one-thing-it-identifies.  But people can and do use one
http URI to identify many different things, most crucially including a
web site AND the main thing described on that web site (what I think
you would call the thing whose representation is retreived via the
URI).

Now the W3C wants to use URIs in the place of assigned numbers in
protocols, so that data formats can be more self-describing and less
subject to centrality bottlenecks, but that means that a single URI
*MUST* be used to identify both a web page (so I can say "go read
http://www.w3.org/2000/09/xmldsig/RSA") and an encryption algorithm
(so my packet can have it's "algorithm" field filled in with
"http://www.w3.org/2000/09/xmldsig/RSA").

This dual use is fine (and has wonderful benefits) as long as we don't
get confused and think there is somehow one URI->thing mapping
function.  If there were only one such function (and it was a
"function" in the mathematical sense of being one-to-one or
many-to-one), that would mean the web page was identical to the
encryption algorithm.  And that's just silly.

I think you address this by ignoring the web page in the middle, and
saying the URI identifies the encryption algorithm, and what you see
when you put that address in your browser is a representation of the
algorithm (or maybe a rendering of that representation). 

But that's just not how people think.  People think there is a web
page at http://www.w3.org/.  Every published use of a URI I've seen
(away from W3C) in the past few weeks (since I started watching
carefully) frames the URI like "visit us at <web address>" or "my website
is <web address>" or "I read it at <web address>" or "<web address>
has some great stuff".  All of those forms demonstrate that people use
URIs to denote web pages, web locations, web sites, etc (*information*
resources), not the abstract entities (the weather, some car, some
dog, the moon) which we might learn about from those sites.

So the W3C tried to find a middle ground -- recognizing that web pages
are real, and still identifying things like algorithms with the same
URI -- by using fragment syntax.  This was a big mistake.  The right
thing is to simply distinguish between the-web-page with the URI
"http://www.w3.org/2000/09/xmldsig/RSA" and the-algorithm with the URI
"http://www.w3.org/2000/09/xmldsig/RSA", using whatever mechanisms are
appropriate to the language at hand.   (I've suggested how to do it in
RDF.  In most other situations I've seen, it's fine to let the user
figure out which way it was meant.)

    -- sandro


> This new IETF draft came to my attention today.
> 
>     http://www.ietf.org/internet-drafts/draft-eastlake-xmldsig-uri-03.txt
> 
>     A number of algorithm and keying information identifying URIs
>     intended for use with XML Digital Signatures, Encryption, and
>     Canonnicalization are defined.
> 
> Note that all of the algorithms, methods, and other tokens are named
> within a flat name space rooted at
> 
>     http://www.w3.org/2000/09/xmldsig-more#
> 
> meaning that the only way to obtain information about any one algorithm
> is to examine the entire namespace (including almost all of 
> cryptography)
> and then indirect from there.  That is just plain wrong and contrary to
> every sensible notion of naming on the Web.  Names are intended to be
> hierarchical, and algorithms almost always contain a subset of names
> that should have their own identifiers within the scope of that 
> algorithm.
> 
> Somewhere along the line the W3C got hooked on the notion that URIs
> are opaque and hierarchy is meaningless.  That is bogus, as evidenced
> by every decent information site on the web today.  Well-designed URIs
> reflect a classification system that is understandable by humans, 
> whether
> or not a human ever sees them, and regardless of how many different
> classification systems may apply to a resource.  This is a
> well-researched aspect of hypermedia systems that goes all the way
> back to NLS/Augment.  W3C specifications should not be defining lousy
> information spaces.

Received on Tuesday, 14 January 2003 17:54:20 UTC