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

I said (to Roy, privately)

> The point is, there are a particular set of applications that
> can use relative forms, fragments, and query syntax. Whether or
> not those applications can use a particular naming scheme
> is independent of whether the naming scheme is intended to
> be "location-independent" or "permanent".

to which Roy reiterated (privately):

> There are some applications which do not use relative forms,
> but the ones that do are not limited to hypertext. Regardless,
> the syntax is uniform in order to support those applications
> that do use those forms.  This is not a hardship for any other
> applications, so there is no point in debating it.

I think we have an agreement on the point that "there are some
applications that do not use fragments, relative forms or queries,
and some that do."  There seems to be some agreement (I'm not sure
how much) that the distinction is based on the application class,
and not (necessarily) on whether the identifier is a URL or a URN.

As to whether or not we should "debate" this, I believe this is the 
crux of the issue that is keeping us from progressing, so I think
it's worth getting clear about it. The question isn't about "hardship",
it is about "applicability" or "appropriateness". Unless it is made explicit,
there is a presumption, at least in many situations, that if you
give a general syntax for a protocol element, the components of
that general syntax are appropriate and allowed for all applications
of that protocol element. However, this is not the case: there are
applications for which fragment identifiers are inappropriate.

If we didn't want to restrict applicability of syntactic components
by having explicit syntactic elements, we'd just stick to "scheme:uric*"
and put footnotes for each application. But that's hardly desirable.

The World Wide Web application (and various other applications) need
and want the BNF for "URI-reference". But other applications (e.g.,
digital libraries, for example), might want to disallow fragment identifiers.

If we pursue this line of reasoning, we would want the URI syntax document
to define sufficient non-terminals to be useful for the different
kinds of application classes. For example,

There are a class of applications that use only 'pure absolute
URIs', with no fragment identifiers, relative forms, or query
processing. (For example, I might imagine various digital library
applications wanting to make this restriction.)

There are a class of applications that use only 'absolute URIs,
and query forms', but no relative forms or fragment identifiers.
For example, I might imagine various resource location applications
wanting this restriction.

There are a class of applications that use "recognize URI in
plain text" syntax. This class might use the "www.blah.com/foo"
form, without any scheme, and might want to restrict the URL scheme
to start with a text character.

Perhaps one way to clarify the issues for some would be to note
some of the different application classes, and even to give
different BNF constructions for each. Hiding it behind the
opaque URI syntax doesn't seem to help those who want some of
the syntactic elements but not the rest.

Larry

Received on Sunday, 4 January 1998 14:16:38 UTC