Mikael Tillenius wrote:
> Thomas Lord escribi?:
>> No. The authority field may contain essentially anything. See
>> RFC3986 <http://tools.ietf.org/html/rfc3986#section-3.2.2>.
>
> Ok, thanks. Then there isn't much structure left in URIs. The first
> part is called a scheme, then comes the authority and then a path but
> there is no interpretation of any of those parts.
>
> And presto! We either have a central authority who decide what the
> parts mean and who gets to use different URIs or we risk name
> collisions. Back where we started.
I have to be a little bit abrupt because of some real world work to
finish but:
In the URI-oriented view of the universe, there are lots of classes of
applications, all of which should interpret URIs similarly. No two
classes have to interpret URIs the same way but what defines each class
of application is that it interprets URIs the same way as all the other
members of the same class.
We could speculate, for example, that perhaps all "conforming" Scheme
language implementations should form an application class -- all
interpret URIs (when used as library names) in "the same way" for some
sense of "the same".
In the URI view, the next distinction is between application classes
which simply "pass thru" URIs vs. application classes that try to
"resolve" those URIs -- to interpret them as names and retrieve some
data or perform some function or ....
"Pass thru" applications don't need to agree about much more than what
characters a URI can contain and that two URIs are equal if and only if
they are character-wise equal.
"Resolving" applications need to parse URIs, in some sense. For
starters, they need to agree about the meanings of URI scheme fields.
In that very, very limited sense, there is a need for a central
authority -- to manage scheme names for a given class of URI-resolving
applications.
But that's all the authority that's needed, if that authority is wielded
well. In particular, one can define uri scheme's to have a meaning in
which an "authority" is something that anyone can create, on their own,
with no external authority. And then, as a consequence, anyone can
allocate names within that authority.
For example, an "authority" could be a standard UUID, or it could be a
cryptographic signature. It could be the name of a hash function that
explains how later parts of the URI should be interpreted. There are
lots of ways to make naming authority non-rival.
So, compare and contrast:
Perl-like names for modules costs 10s to 100s of thousands of dollars
per year (including unaccounted costs) to manage something like CPAN.
The resulting authority service is monopolistic and imposes heavy
transaction costs on allocating new names.
URI-like names for Scheme modules would have a one-time cost of agreeing
on the semantics of one or more URI scheme names in such a way as to
permitted distributed, decentralized allocation of authority.
> No, the main reason for using s-exps is that Scheme usually represents
> things by s-exps.
You mean like complex number constants, rational number constants,
string constants, and other examples of compound values not written as
parenthesized trees of more atomic values? What do you mean by
"represents things by s-exps", exactly?
-t
Received on Thu Jun 28 2007 - 18:17:28 UTC