What is identified?

Separate to the issues of naming is the issue of what is the unit of identification in the system. Currently, in 1995, URIs (Uniform Resource Idenifiers) are well deployed and understood and all thoise used are URLs (Locators) in that there has not yet been any gobal naming system deployed which is more satifactory than http server naming. The confusion addresses here has to do with the relationship between a URI and

Search/query information currently after the "?" in a URL
Parameter information for "applets" (executable embedded objects)
Fragment identifier, following the hash.

Summary of existing 1995 situation

The current model is as follows. Let us take as reference a URI of the form


	http://s/p?q#f

where s is the server domain name, p is an opaque string passed to the server, q is a string representing parameters to a query of http://s/p, and f is a fragment identifier.

Let us use the smalltalk object notation in which [ob meth:param] indicates the result of applying the method "meth" with parameter "param" to object "ob".

The HTTP protocol treats p?q opaquely. It provides a retrieval method GET which returns a whole object


	ob = [HTTP  method:GET  uri:"//s/p?q" ]

or more concisely, assuming HTTP to be simply part of the infrastructure of invokation,


	ob = [s  GET:"p/q"]

This then returns an object in some mutually understood syntax, which is then available on the client side. The client then activates the object in some way passing the object the string f:


	[ob  view:"f"]

The result of this is the rendition of the object in a given view.

Crucial assumptions of this model are:

The server is only passed p/q, it does not know s
The server is only passed p?q and not f
The client does not interpret p, q, or f. However, the client does know how to build q.
The object once instanciated on the client does not need to know s, p, or q: it only needs to know f

It hardly needs to be stated that it is a very good principle of system design to hide information from parts of the system which do not need it. Whenever a parameter such as p, q or f is declared to be "opaque" to some part of the system, then great flexibility results, and also, typically, easier system development and enhancement, and fewer bugs. The number of fascinating systems which have been built by using interestingly structured encodings for p demonstrates the poverty if for example p had been declared to be a filename.

Server name

The first assumption above was unfortunate, I believe, as it prevents one machine from emulating any servers. The assumption that servers would always know s, or that they would never need to know s, were both false. The attempt to fix this using an "original-uri" header which contains s as well as p and q is a hard sell, as no old browsers will work with servers which require it.

Fragment Identifier

The second assumption above is that the unit of retrieval is the object and so the server does not need to know the fragment identifier. This corresponds to the use in HTML: the whole document is retrieved, then a particular piece of it, identified by f, is highlighted or scrolled to the top of the screen.

The phrase "fragment identifier" is perhaps unfortunate. It allows to misunderstandings to crop up. One is that f should always be used as in HTML to indicate a fragment. We should interpret f as any set of parameters to be passed to the object to define the rendition, or view, required. For text, the only variables are the selected area and the scroll position, so this is what is effectively communicated in f. For a three dimensional view, a viewpoint would be quite appropraiate. "View identifier" would have been better perhaps, but it is too late now.

The other misunderstanding is that f should be used to indicate part of an object's state to be transferred by the server It cannot be empahsised too strongly that f is not used for this purpose. If there is a requirement to fetch a "slice" of an object for efficiency reasons, then that is a seperate function which we do not consider here.

A problem with the assumption that f is only seen by the object arises immediately with format conversion. the syntax of f has to be such that it will be understood by all objects which are valid representations of ob.

Path

The p part of the string is often called the path. It has an option hierarchical structure which si only used for shortened "realtive URIs" which typically make document management easier. It is completely opaque to the client, apart from the relative URI transformations. Any attempt to impose suggest require or sneak in any orm of convention for the contents of p would be a serious breach of an important architectural principle.

Query string

The so-called query string is an encoding of parameters to be applied to an object. It started being used to encode a string query to an indexing or search engine, or soon afterward, any processing object. It later was used with forms which allowed users to create suitable query strings in a friendly way. The ISMAP convention provided a way of creating a query string from the coordinates of a mouse click. Other systems have built complex virtual document webs from interlinked query results, a query result containing links to other queries.

The client is aware of a limited syntax for q in the cases in which it has to build the query string. In these cases the string is either a random text string (in the case of a general searchable index) or it is a attribute/value pair list, in the case of encoded form data or ISMAP data.

So what is identified?

The system needs a good solid notion of an identifier. An identifier is currently used to identify the destinations of links, and the contents of embedded images. The URI without the q is an identifier corresponding to an object.

We have the useful but strange situation that what to the client is an identifier is to the server a function. We have two levels of application of paremeters/methods/operations/qualifirs to a basic object, one of which (q) takes place on the server and one (f) on the client. However, we are interested in systems in which the server and client distinctions blurr. Maybe we want to give the server the option of doing the application of f to the object on the sevrer side, or re-expressing f when converting the format of p?q.

A basic challenge here is how we can use the power of combination of typical programming languages with the information-hiding properties of the web. Let's look at some of the principles we need to maintain

Information hiding

The information hiding referred to above, in which parts of the URL string are opaque to most parts of the system, is part of the information hiding in the web. Another form of information hiding is that information in different places and contexts is represented in different data formats, and that there is a certan amount of interdependence between them but in general new formats can be added quite easily. Example of these formats are the URI syntax, the HTTP message format, the HTML format, the GIF format.

There is a clash of principle between the markup world and the Object oriented world. The markup world maintains the feature that an object is stored in a cannonical form so that its stored state may be interpreted by any conforming implementation. Therefore, the internal syntax is exposed, but the implementation hidden. The OO world does not generally move objects around between heterogeneous systems, it more naturally invoked methods on them remotely. OO systems pride thmselves on hiding from the user the details of the storage format. The semantics of the object can be defined in specifications, but as they are inherited by subclassses, few systems dare to mix different implementations of the same object. Typically, the implementation code will be common, and the data hidden. Ideally, the specification of an object will inlcude both a cannonical storage/transfer format, and the API (interface) for its implementation,

Declarative property of the web

In all the object-oriented discussion, we may be trapped into overlooking the important lessons from applicative languages. There is an important rule that the http GET must not have side-effects. As a result of this rule, the result of GET may be cached. The architecture of the link is essentailly declarative rather than procedural.

<a href="foo">More information</a>

is interprested to mean

"A link exists starting at the phrase more information and ending at the object with URL foo".

It is not interpreeted as

"Underline the phrase more information and when a mouse click occurs, then present the object with URL foo"

The advantages of the declarative approach are that

As the data is a form of declaration, a statement, the client is free to interpret that information in a great variety of ways.
Statements may be changed and modified, often using the same interface that is used to deisplay them. Procedures can't.

An advantage of the procedural system is that a pocedure can be invoked to do a wide range of things whose results would be difficult to express in fucntional terms. For example,a procedural link could allow one to turn the user's heating off, their screemn pink, and sing a song. The disadvantage is that once that is allowed, the model has gone. Users are no longer aware of information objects, and are emerged in an interactive environment with no rules. The user can no longer make reference to objects, and weave parts of that web into his or her own.

In this impoverished era of hypertext, the only creative action the average user has is to add an item to his or her hotlist. This simple action relies on a solid concept of an object (or more specifically, a view of an object) and of a solid notion of an identifier. The hotlist contains the value of the URI, and the guarantee is that when it is activated later, the the same view will be presented again.

There is also something important psycologically about the declarative nature of the web. It can be argued that the web took off and appeals to people because the have a sense of its existence. This may be because people have the ability to handle maps of quasi-static systems of objects and links. This is acontrast to the procedural interfaces, for example of FTP, in which the language is of "setting mode", and "transfering". he emphasis on verbs leaves the user with a need to model the protocol state of a remote peer entity, and deduce, from the conversation, a model of the actual inormation at the far end. There may be psycological as well as computer science reasons for thinking hard before beaking the declarative nature of the web.

Sameness, genericity, and specialization

A difference betwene the web and most object systems is the notion that the same object can be represented in many forms.

These forms typically differ in machine representation (content-type), human language, resolution, and version.

The current model is that an object may have different URIs, for example one for the specific oject, and one for a more generic one. The method of handling this hich has been proposed is

You label the URL with its genecity properties
You give links between the specific and the generic versions

For example the headers on an HTTP object might be


	Content-type: image/png
	Content-language: en_us
	URI: "http://foo.com/bar"; vary=language,content-type,version
	URI: "http://foo.com/bar.en_us"; vary=content_type, version
	URI: "http://foo.com/bar.en_us.png"; vary=version
	URI: "http://foo.com/bar.en_us.png.v10"; vary=none

indicating that the document may be refered to in a number of ways, as a gneric document, as specifically the english translation, as specifically the PNG format of that, and specifically as the current bitstream version of the PNG format english translation.

Jumping ahaead a bit, one can see a need for giving more information about these specific encodings:

	
	    ( url "http://foo.com/bar.fr" (vary (langauge content-type)))
	    ( specialization-by "content-language" "http://foo.com/bar" )
	    ( content-langauge: "fr" )

This is one richness which has give the web flexibility, in that it has allowed one to separate the concept of an object from that of a bit pattern, and so allow migration of storage and transmission formats as technology evolves.

The client server model

Do we want to keep the inherent client-server model of HTTP? The thing to which the example link above refers is in the syntax above

	[ [s get:"p?q"] view:"f"]

in which the client-server architecturally embedded. If we looked at it without the client-server distinction then we would just see

	[ ob view:f]

where the implementation of ob could be anywhere. In this model if the object is determined (by some name service) to happen to be on a remote server s, then we have to ask s the whole question:

	[ s view:"ob#f"]

This allows s to return the object ob and view identifier f, or to return an object which encompasses only the view but not all of "ob", or to return an object ob2 which is equivalent in some way to ob, with a view specifier f2 which is the equiavlent (for ob2) of f (for ob). This gets us around the problems such as conversion of an id in an SGML document into a byte rnge in the equivalent text file, or of conversion of a byte range in an original text version to a byte range in an updated version of a living document.

What to save

An essential requirement for system integrity should be repeatability of dereferencing operation. For a user, that means that if he or she is looking at an upside down slowly rotating penguin, and makes a link to it, following that link later will lead to a slowly rotating penguin: not a fixed penguin, or a penguin which can't be displayed until one has input a rotation speed.

This means that the "identifier" for this must contain all the function parameters if the penguin is a function. The problem with that is that these things are very cumbersome in URL-encoded form. Hence Larry Masinter's proposal for multipart/form encoding of form parameters. Another more compact proposal is LISP-like syntax.

A sensible proposal then might be to have two alternative syntaxes for which url encodeing would be the defualt for transmission in an HTTP GET, and where the other syntax is usable where readability is desired.

	(query "http://www.w3.org/foo" "something on animals" )
	http://www.w3.org/foo?something+on+animals

	(map "http://s/map" ( 23 48 ) )
	http://s/map?x=23;y=48

	(form "http://s/foo"  (
	    ( name "John Doe" )
	    ( address "1, ridgewater street" )
	    ( state "TX" )
	))
	http://s/foo?name=John+doe;address=1%2c+ridgewater+street;state=TX

	(view "http://www.w3.org/" "Software" )
	http://www.w3.org/#Software

	(view "http://s/foo" ( (r 30.0) (theta 30) (phi 0)) )

This is simply for convenience. It gets over the inconvenience of URL encoding.