Re: Hypertext::non-Hypertext not URL::URN

[Al Gilman <[e-mail]>]

to follow up on what Larry Masinter said:

> 
> I think you've made an important point that I don't want to
> get lost. The syntax forms that are controversial
> (fragment identifiers, relative forms, query syntax)
> are part of the application of HYPERTEXT.
> 
> In fact, whether or not you want those forms seems to depend
> entirely on whether or not you think you're doing hypertext.
> 

This is an interesting idea to pursue, but not credible in
the strong form you stated.

If I were on the road wanting to find the nearest IPP accessible
Braille embosser with a courier delivery option, I believe this
could well wind up as a resource-discovery query involving
something much like the ?parm-list familiar in URLs.

Not all of the functions you reference are limited to HyperText
applications.  But one can, for the purpose of analysis and
understanding, break out a lattice of classes of [names or
identifiers] with longer and shorter sets of "what you can
do with it" attached to the class.

>From the naming perspective, the paramount characteristic
is that the identifier contains a sufficient key (attribute
cluster).  The ability to abbreviate [for relative forms]
in selected contexts [where a document context or other basis
for establishing a BASE environment characteristic exists]
and to parse by certain methods are introduced lower down
in the class web, in more concrete "derived" classes. 

["lower" here is dependent on having adopted a "naming
perspective."]

The difference between an URL view and an URN view of URIs could
be summarized in terms of which of the following failure modes
you are more concerned to avoid:

	- The identified resource exists, but you don't get it.
		-- URL cares first to avoid this
	- You get a resource, but it is not what you intended.
		-- URN cares first to avoid this

-- Al Gilman