Re: definitions for operations on URIs

At 12:53 PM 2002-07-13, Larry Masinter wrote:

>http://lists.w3.org/Archives/Public/www-tag/2002Jul/0169.html
>
>These look like interesting possible additions to the URI specification.

Interesting, if one could tell what they meant.

>URI Resolution: 
>  The process of determining the access mechanism and 
>  appropriate parameters necessary to dereference a 
>  URI. e.g. in the case of an HTTP URI, this process 
>  resolves the URI into an IP address, a port number, 
>  a host name (possibly optional) and a request URI.
>
>  Resolution may require several iterations.

The access mechanism is not necessarily unique.
[example: HTTP 300 response; html:object element]
Can't tell one is done with this until the intended
query, be it to create, inspect, or modify "the state
of the resource," (actually, some neighborhood in The Web) 
has succeeded or one has exhausted options and none 
has succeeded.

>URI Dereference: 
>  The process of using the access mechanism and 
>  parameters generated by URI resolution to create, 
>  inspect or modify resource state.

The nature of the desired operation may be implied
by the URI itself or may be determined by the context
in which the URI-reference is found.  The action 
described here is the elaboration of a transaction 
for which the URI is part of the initial representation.  
The URI does not always contain all the assertions which 
govern this concretion step.

>URI Retrieval: 
>  The use of URI dereference to retrieve 
>  representations of resource state. 

This language is circular.  Retrieval is to retrieve.
But what is that?

What is actually happening is creating a 'local' resource,
that is to say a resource within an address space decided
by and convenient for the using process, which is a faithful
replica of the state of the resource and meets certain 
concreteness or representation vocabulary constraints of the
using process as well.  [Think endian flips.]

 From the 'defining' language given, it is not clear how
to distinguish this from the previous.

And the 'create' and 'modify' cases would seem to
call for terms parallel to this 'inspect' version.

Of course in the case of web Forms, what one retrieves
is not just resource state but the opportunity including
method handles to change the state.

These are all flavors of elaboration or expansion of
a compact utterance:  migrating an expression in the
specific direction employing through known, applicable 
generic-specific relationship patterns.

A URI-reference constrains, but does not necessarily complete
the constraints on, the fragment of the Web that is being 
elaborated in this line of development.

The whole discussion is unfortunately tainted with network
communication residues.  This is not necessary, and it is
not the Architecture of the Web until this aspect is defined
independently from network and database specifics.

What is happening is that there
is a local web within which a neighborhood (a context+expression
containing a URI-reference) is being expanded, and because
of the embedded URI-reference, the expansion is being done
subject to constraints linking the local expansion with a large, 
persistent web in which URIs are globally non-colliding in their
interpretation (to a sufficient degree).

The URI serves to key the view into the persistent, shared Web with 
which the local-web expansion is to be synchronized.

The 'done-ness' or stopping criteria for when the expansion has 
succeeded are determined by the local transaction, not by the URI.

Al

Received on Sunday, 14 July 2002 11:30:57 UTC