The Dexter model is an attempt to capture, both formally and informally, the important abstractions found in a wide range of existing and future hypertext systems. The goal of the model is to provide a principled basis for comparing systems as well as for developing interchange and interoperability standards. The model is divided in three layers, with glue in between, as shown in the figure below:
(You may click in any of the five regions to get an explanation of the corresponding levels, except in the static or off-line versions of this course.)
The focus of the Dexter model is on the storage layer, which models the basic node/link network structure that is the essence of hypertext. The storage layer describes a "database" that is composed of a hierarchy of data-containing "components" (normally called "nodes") which are interconnected by relational "links". The storage layer focuses on the mechanisms by which the components and links are "glued together" to form hypertext networks. The components are treated in this layer as generic containers of data.
In the within component layer the model is concerned with the contents and structure within the components of the hypertext network. This layer is purposefully not elaborated within the Dexter model. The range of possible content/structure that can be included in a component is open-ended. It would be folly to attempt a generic model explicitly covering all possible data types for components. Instead, the Dexter model treats within-component structure as being outside of the hypertext model per se. It only treats the glue between the storage layer and the within-component layer, a mechanism for addressing (or referring to) locations or items within the content of an individual component. This mechanism is called anchoring in the Dexter model.
The storage and within-component layers treat hypertext as an essentially passive data structure. Hypertext systems, however, provide tools for the user to access, view and manipulate the network structure. This functionality is captured by the runtime layer of the model. The Dexter model provides only a bare-bones model of the mechanism for presenting a hypertext to the user for viewing and editing. The range of possible tools is too broad and too diverse to allow a simple, generic model.
As in the case of anchoring, a critical aspect of the Dexter model is the interface between the storage layer and the runtime layer. In the Dexter model this is accomplished using the notion of presentation specifications. They are a mechanism by which information about how a component/network is to be presented to the user can be encoded into the hypertext network at the storage layer. Hence the way in which a component is presented to the user can be a function not only of the specific hypertext tool that is doing the presentation (i.e. the specific runtime layer) but can also be a property of the component itself and/or of the access path (link) taken to that component.
Apart from an informal discussion of the different layers in the Dexter model, the reference model is also defined exactly in the specification language Z [Spivey-89]. Because of the numerous people who worked on the Dexter model, and because a precise specification exists, some people have attempted to implement hypertext systems that capture all features defined in the model [GT92].