Re: The UR* scheme registry, Citing URL/URI specs

There are two pieces of this question.  One is a question of
nomenclature: how many names, and what name(s) should we use to
refer to things of the UR* class?

The second is a matter of software architecture: what IETF
documents should the W3C documents for HTML etc. cite, and how?

This message talks to the nomenclature question.  

I have thought about this issue for a while.  Let me explain why
I might tilt (say 51%) toward the following position (to 49% for
the existing triad of names and the HTML spec says HREFs are
URIs):

     [Dumb it down.]  Just call me "URL."

I.e. the URL name has a userbase.  If it ain't broke, don't fix it.

The current URL syntax draft makes the point that UR*'s are part
of the consumer interface of the Web.  That's why the napkin
scenario is in there.

Consumers will accept Uniform Resource Locators as the expansion
of URL and pronounce it "Earl" and not care about the expansion.

If we are using terms precisely, "identifier" is not that much
better than "locator" as a generic term for the UR* class of
writings.

I think we should be applying natural-language standards for
the fineness of terms in this matter.  In consumer terms, the
consistency of the UR* class is more significant than the
adminstrative differences between URLs as used now and URNs as
emerging presently.

We can let URL be extended to cover the UR* class for
communicating with consumers.  Let URI be historical.  Let URN
have its own process.  The W3C documents should be clean of
caring about the differences, anyway.

DETAILS:

Consider two locators in street language:

In large organizations, one of the listings that is exported to
the telephone directory is "personnel locator."  If you call this
number with the name of an employee, they can get you
organizational unit and telephone number.

When you buy a car security system, you get a car locator that
you carry on your keyring.  You press the button and the car
barks.  The device has located your car in the parking lot for
you.

These examples from street life share the defining characteristic
of UR* thingies.  This is that they are retrieval keys: they are
the difference between retrieving the resource and not retrieving
it.  Never mind that for a news: URL the strictly-location part
of the information is usually defaulted to "somewhere on your
local News server."  Whatever it takes to bring the resource to
the foreground of your browse session is there.  In natural
English, "locator" is a perfectly good epithet for that meaning.

I tend to believe that an "education" program to reform consumers
and get them to convert from talking about URLs to talking about
URIs will face the same fate as the prohibition of alcoholic
beverages met in the U.S.

The difference between "identifier" and "locator" is
insignificant when compared to the more important shared nature
of all these things.  They can all be distinguished from one
another because they have been harmonized into one syntax.  The
syntax is not uniform; it is modal (casewise).  But in terms of
the consumer it is a uniform super-scheme because you can always
tell them apart and apply the modal rules right.  The are all
locators in the sense defined above.  The customer is right.
Keep it simple.  Just "Call me 'URL.'"

It is not the process nor registry which qualifies a UR* scheme
to merit the 'U' for Uniform.  It is the fact that they can all
be distinguished one from another.  So long as one can
distinguish URNs from URLs syntactically, we can say they are a
subcategory of URLs and we don't need the URI name for a spanning
class.

The URI name should be headed the way of the nntp: scheme.

When we got it working, we found we didn't need it.

-- Al Gilman

Received on Friday, 24 October 1997 14:27:03 UTC