Re: URL semantics

[Fisher Mark <[e-mail]>]

> > At 11:27 am 09-01-97 -0600, Daniel LaLiberte wrote:
>[I wrote this, in case anyone missed it]
> > >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.
>
>Tim Berners-Lee writes:
> > I  completely disagree.  The URL identifies the object.  That is
> > fundamental to the concept of the web. The web is a web of
> > quasi static resources, not a set of operations, as base.  This
> > is essential architecturally and from the UI point of view.
>
>OK, I think it works both ways.  But if you say a mailto URL
>identifies an object, and that object is a conceptual entity upon
>which you can do many operations (such as send a message to the
>address, or lookup previous sent or received messages associated with
>the address), and there is no particular one place that the conceptual
>object resides, or one service that you interact with, then we
>essentially have a collection of possible operations (and associated
>data) packaged up as an "object".  In fact, one way of defining an
>object is as a set of allowed operations on the object.  To the client
>of an object, the object is *nothing but* the allowed operations on it.

I would rephrase this as, "To the client of an object, the object is 
*nothing but* the _opaque object identifier_ and the allowed operations on 
_that class of object_".  Without a "magic cookie" (opaque object 
identifier) specifying a particular object, you can't talk about that 
particular object.

Different schemes (URL object classes) support different operations, where 
"mailto:" supports just the electronic mail of some data to the specified 
email address.  IMHO, it just happens that most UAs allow the user to 
specify something beyond what is in the "mailto:" URL.  (I suspect there are 
applications where a cybernetic (non-humaniform) agent could make use of a 
"mailto:" URL without needing to add any data (headers or message body) to 
what is contained in the "mailto:" URL.)  In essence, a "mailto:" URL has as 
its one operation, "send email to the address", where the address is the 
opaque object ID (at least possibly opaque at the UA level), and the 
operation data is the additional headers in the URL (and any additional 
headers and message body the UA permits to be sent).

>So I should have been a bit more specific and said the URL identifies
>(by way of an abstract object) a set of *possible* interactions.  And
>the possibilities are, as you say, controlled by the user (and any
>server that must cooperate).
>
> > If you wanted to make something which contains an interaction, some
> > operation, then you would need a language in which resource identifiers
> > were a part.  But there are many languages for that, and there can be
>many
> > more.  (A frameset is one, a form is another, Java is another.)
>
>A complex language is not needed in order to express operations.  An
>http URL essentially expresses that the client should lookup the
>domain name, send an HTTP request to the server, etc.  Alternatively,
>a client could interpret the same URL differently and lookup the URL
>in a set of caches, or lookup the URL in a content rating service.
>The language of http URLs is very declarative.
>
>In general, any identifier is an expression in that the user of the
>identifier interprets it.  If the identifier is completely opaque,
>then there is nothing to interpret.  But all the URI schemes define
>visible structure down to a certain level of granularity.  The visible
>part lets the client partially interpret it to pull out the
>components.  The remaining opaque parts and components are interpreted
>by other services (e.g. dns and http servers).

For example, it could eventually be possible within TCE to specify 
"mailto:MSMAIL/INDY/TCEIS3/FISHERM" as my valid internal Microsoft Mail 
address.  (Not that I recommend specifying MS Mail in an RFC, mind you...)

> > PS: Above I use "object" to be consistent with the thread, I should
> > use "resource".
>
>I'm fine with "object", but analogously, "GET" could mean "do the
>intended interaction".  But people have a habit of jumping to
>conclusions.
>
>dan
>

I find GET to be pretty HTTP-specific.  I do not have better wording on 
hand, though.
======================================================================
Mark Leighton Fisher                   Thomson Consumer Electronics
[e-mail]                   Indianapolis, IN