Re: URL semantics

If I may (from an observers perspective) offer:

Daniel LaLiberte (liberte@ncsa.uiuc.edu) writes:

> Larry Masinter writes:
>  > I agree it's a little awkward, but I strugged to get the current
>  > wording. The point is that the 'mailto:' URL is not the name of the
>  > data object you get. It's the name of the interaction.

The URL is intended to identify a 'resource.'  Thus the items: 'url 
addressed data object,'  'mailto: invoked interaction,' 'telnet: 
invoked session,' and so on, all each to be considered 'resources.

If one GETs the resource 'telnet: invoked session' it results in a 
session - no problem.  If one 'GETs a 'mailto: invoked interaction' one
achieves the result that an interaction occurs (one gets an interaction) -
no problem.

> But for all URLs (and URNs, if they may be distinguished), the URL
> identifies the interaction.  In the case of *some* URLs, the
> interaction results in a data object, so it only *seems* that the URL
> identifies the data object, but that is an indirect effect.

The intention seems to be that a URL or URN identify some
'resource.'  In some cases the identified resource is in fact a data
(bearing) object.  In these cases, the semantics of HTTP method
application on the URI should equate to those of application of this
method to the identified data object.  To implement these semantics
includes necessarily that an interaction occurs.  That this interaction 
occurs is a necessary implementation detail.

> Furthermore, given a URL, many things may be done with it other than
> the implied GET, open, or whatever.  For example, in addition to
> GETting a resource, one could also get associated annotations.  To say
> that a URL means only one thing (e.g. GET it) when it can, in fact,
> may also mean many other things only confuses the issue.

I fully agree.  The URL (or URI) identifies a resource onto which
application of a certain set of methods will make sense.

>  > I'm willing to change the URL scheme suggestion to talk about "open"
>  > instead of "GET", but most documents currently talk about "GET".
> 
> I think those documents should be changed, if possible, or whatever it
> takes to get this terminology changed.  But I don't know that "open"
> is the best term either.   [...]

GET works for me if we view identified resources as such.  In this
fashion it currently acts as a sort of universally applicable method.
Should there be a set of universally applicable methods?  Yes, if only
to retrieve info on the set of methods applicable to an identified 
resource.  That is, as we increasingly see a unique set of methods 
applicable for any given URI identified resource, we should introduce 
means of learning the nature of these sets.

Still, we don't need to specialize method names where GET suffices - that
is when we fully label the identified resource ('email interaction','telnet
session').  It's ok to get an interaction or to get a session (just don't
try to 'save to disk').

> [...] For each URL scheme, there might be a
> different implied operation, but there also might be a different
> implied operation for each context in which the URL appears, or an
> explicit operation could be named. For example, the ACTION (a URL) and
> METHOD (e.g. POST) of an HTML form together say what to do when the
> submit button is clicked.  So it is the context of the use of a URL
> that determines what a URL means.

This example, a URL appearing in context of "value of an 'action' attribute
of a 'form' tag," does illustrate that semantics of a particular method 
application on a particular URI is likely broader than what might be the 
stated semantics of application of a universal method (GET or POST) 
on generic URIs.  In certain context the semantics are extended, overloaded,
or (yuk) overridden.   This doesn't appear to me to warrant throwing out
the notion of universal method but does suggest documenting both the
intended semantics as well as nature of process by which they may be 
modified in context.  Perhaps in response to a query for the methods
applicable to a resource, the nature of alteration of default semantics of
universal methods (well known methods) should be returned.

Dave Lewis
Sr. Systems Analyst
Pacific Bell

Received on Thursday, 9 January 1997 15:03:45 UTC