The Runtime Layer

A fundamental concept in the runtime layer is the instantiation of a component. This is a presentation of the component to the user. Operationally, an instantiation should be thought of as a kind of runtime cache for the component. A "copy" of the component is cached in the instantiation, the user views and/or edits this instantiation, and the altered cache is then "written" back into the storage layer. Note that there can be more than one simultaneous instantiation for any given component. Each instantiation is assigned a unique (within a session) instantiation identifier (IID).

Instantiation of a component also results in instantiation of its anchors. An instantiated anchor is called a link marker. To fit instantiation of anchors into the Dexter model the instantiation is actually a complex entity containing a base instantiation together with a sequence of link markers and a function mapping link markers to the anchors they instantiate. A base instantiation is a primitive in the model that represents some sort of presentation of the component to the user.

At any given moment, the user of a hypertext can be viewing and/or editing any number of component instantiations. The runtime layer includes an entity called a session which serves to keep track of the moment-by-moment mapping between components and their instantiations. Specifically, when you want to access a hypertext, you open a session on a hyperdocument. You can then create instantiations of components in the hyperdocument (an action known as "presenting" the component). You can edit these instantiations, modify the component based on the accumulated edits to the instantiations (an action known as "realizing" the edits), and finally destroy the instantiation (an action known as "unpresenting" a component. When you are finished interacting with the hypertext, you close the session.

In the Dexter model, the session entity contains the hyperdocument being accessed, a mapping from the IIDs of the session's current instantiations to their corresponding components in the hyperdocument, a history, a runtime resolver function, an instantiator function, and a realizer function. At any given moment, the history is a sequence of all operations performed since the last "open session" operation. It is (in the present version of the Dexter model) used only in defining the notion of a read-only session. It is intended to be available to any operation that needs to be conditionalized on preceding operations.

The session's runtime resolver function is the runtime version of the storage layer's resolver function. Like the resolver, it maps specifiers into component UIDs. The runtime resolver, however, can use information about the current session, including its history, in the resolution process. The storage layer has no access to such runtime information. For example, a specifier may refer to "the most recently accessed component named 'xyzzy'". The runtime resolver is responsible for mapping this specifier into the UID matching this specification. The runtime resolver is restricted to be a superset of the storage layer resolver function; any specifier that the storage layer resolver can resolve to a UID must be resolved to the same UID by the runtime resolver.

At the heart of the runtime model is the session's instantiator function. Input to the instantiator consists of a component UID and a presentation specification. The instantiator returns an instantiation of the component as part of the session. The presentation specification is primitive in the Dexter model, but is intended to contain information specifying how the component being instantiated is to be "presented" by the system during this instantiation. Note that the component itself has a presentation specification from the storage layer of the model. This presentation specification is meant to contain information about the component's own notion of how it should be presented. It is the responsibility of the instantiator function to adjudicate (by selection or combination or otherwise) among the presentation specification passed to the instantiator and the presentation specification attached to the component being instantiated. The Dexter model does not make this adjudication explicit.

The instantiator function is the core of the present component operation, which takes a component specifier (together with a session and a presentation specification) and calls the instantiator using the component UID derived from resolving the specifier. Present component in turn is the core of the follow link operation, which take (the IID of) an instantiation together with a link marker contained within that instantiation and then presents the component(s) that are at the destination endpoints.

The instantiator function also has an "inverse" function called the realizer function which takes an instantiation and returns a (new) component that "reflects" the current state of the instantiation (i.e., including recent edits to the instantiation). This is the basic mechanism for "writing back the cache" after an instantiation has been edited. Therefore the function that performs this operation is called the realize edits function.