Vision&Reality
     of Hypertext and Graphical User Interfaces

2.2.2 The Dexter Hypertext Reference Model

in Vision and Reality of Hypertext and Graphical User Interfaces

Frank Halasz and Mayer Schwartz present the model in The Dexter Hypertext Reference Model [Halasz/Schwartz 94]. The model aims to deliver a common terminology that covers existing and future hypertext systems. The abstraction leads to a model with three layers. The storage layer describes the network of nodes and links. The run-time layer covers the interaction of the user with the system. The third layer is the within-component layer. It describes the internal structure of hypertext nodes.

Dexter’s response to the variety of different names for nodes and links is the introduction of a new term.

The basic entity of the storage layer is a base component. (1)

A node in the Dexter model is an atomic component. But the internal structure of components is purposefully not specified. This allows the forming of composite components, that can recursively contain other components. Composite components can be used to describe for example the writing spaces of Storyspace or the documents of Symbolics’ hypertext system.

Every component has a globally unique identifier (UID). (2)

This means that a component can be unambiguously addressed not only from the hypertext where the component belongs to, but from any other hypertext. Some hypertext systems provide indirect specification of link destinations. NLS for example can jump to «the statement containing the word ‘pollywog’» [Ibid., p. 33]. The storage layer is responsible to resolve such component specifications into UIDs.

The mechanism to address content within components is called anchoring.

An anchor is a pair of anchor ID and anchor value. (3)

The anchor ID is valid within the scope of a component and is used to identify a position within the component. The anchor value can be any arbitrary value and has only meaning to the owning application program of the component. It is used to specify the position within the component. If the content of the component is edited the application has to update the anchor values for the component accordingly. The anchor IDs stay fixed to provide a reliable address for incoming links. This distinction between anchor ID and anchor value is necessary to integrate diverse data files as nodes for the hypertext.

A globally unique component specifier together with an anchor ID forms one side of a hyperlink. Two more fields are added for the definition of a specifier in the Dexter model.

A specifier is a tuple of UID, anchor ID, direction and presentation (4)

specification.

The direction value can be FROM, TO, BIDIRECT, or NONE. The common case of uni-directional text links is modeled in the way that the first specifier has the direction value set to FROM and the second specifier the direction value set to TO.
The purpose of the presentation specification is to store data about how to display the link marker for the user interface.

Now it is possible to define the link for the Dexter model.

A link is a component that contains a sequence of at least 2 specifiers. (5)

Concepts like trails, paths, tours or sequences can be represented by Dexter links with more than 2 specifiers.

Now the suite of components is complete.

A component is a pair of base component and component information. (6)

A base component is either atomic, composite or a link component. (7)

The component information stores the sequence of anchors for the related base component. Further on the component information contains attribute-value pairs that can be used to describe the base part of the component. For example meta-data like keywords for hyperlinks can be attached as special attributes of the component information section for link components.

Fig. 2.15 This diagram shows the relations between 5 components. An atomic component to the left. The composite component to the right contains 2 atomic components. The link in the middle is the fifth component. (The component info block for the link component is omitted.)

Third, data stored in the component information is a presentation specification that contains instructions for the run-time layer how to display the content of the component in the user interface.

The run-time layer manages the presentation of the hypertext structure for the user interface.

An instantiation is the activation of a component for the run-time layer. (8)

A link marker is an instantiated anchor. (9)

Halasz and Schwarz continue their tour through the Dexter Model with the presentation of general functions that are necessary to operate the hypertext model. They will not be presented here.

In order to conclude the Dexter Hypertext Reference Model two qualities shall be highlighted. The model is capable to represent higher order aggregations of nodes, as has been demanded by Frank Halasz in his “7 Issues” [Halasz 87], [Halasz 88]. And second, it is possible to specify links to links. The model is therefore powerful enough to describe a hypertext that refers to itself.



 For a free PDF version of Vision and Reality of Hypertext and Graphical User Interfaces (122 pages), send an e-mail to:
mprove@acm.org   I’ll usually respond within a day. [privacy policy]