Attributes should only be there if part of the name/address space

Tim Berners-Lee writes:
 > If I understand this correctly (if not correct me), the attributes
 > are not needed in order to identify the services. The services have
 > these attributes just as web documents have titles and expiry
 > dates.  If this is the case, then under no circumstances should any
 > information other than those needed to identify an object be
 > included in the URL.  If the information *is* needed to identify
 > the object, then it must (clearly) be included in the URL.

This is a good policy, but I want to clarify something.  The question
is, what is the "object" that is identified?  Consider that one
identifier might correspond to an object that is an abstract
collection of some sort.  A service is similar to a collection.  Two
kinds of collections often considered are alternative representations
and alternative languages.  But many more are possible: alternative
levels of detail, alternative versions, the stream of issues of a
periodical, etc.

Now, it is possible to identify the collection with one identifier and
also identify each of the individual members of the collection with
their own independent identifiers.  HTTP 1.1 provides a different
alternative, that of entity tags for identifying individual members of
a collection all identified by a single http URL.

Another alternative way to identify the members of a collection is
relative to the identifier of the collection.  Thus, attributes could
be added to the collection identifier to indicate a particular member
of the collection.  In fact, path-based relative URIs can be
considered as one form of this extension of the collection URI, where
each prefix of a path corresponds to a collection.

The suggestion that Erik Guttman makes regarding the SLP URI is that
large numbers of such attributes might be passed not in the URL itself
but along side it, or associated with it.  This is similar to HTTP
headers that contain additional parameters that the server may use to
select a particular, uh, entity.  Thus what identifies the result of a
request is *not just* the URI but *all* the information that is used in
the resolution process.  Some of that information may not even be
visible to the client of the request, in which case the server can
either provide that information in the result of the request or the
client is out-of-luck.

My suggestion is that it is desirable to have a uniform format for
the complete identification of an object, including all the parameters
that were used.  It may not always be possible to create or provide
such an identifier, but when it is, it is useful.  

Thus I worked on a generic "call" URI scheme to allow any URI scheme
to be wrapped with the additional parameters used in resolution. For
each scheme, there could be a different way in which the parameters
map to associated protocols and some schemes might not allow any
parameterization.  A better notation might the ';' separated
name=value,value,value "pairs".

--
Daniel LaLiberte (liberte@ncsa.uiuc.edu)
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/

Received on Thursday, 20 February 1997 10:24:53 UTC