A tower object is an object with a tower value. A tower value is a mapping from a set of labels to a set of objects. Each label is a description level, corresponding to a separate level of the hyperdocument functionality. The domain for the function is fixed for each class of tower objects. If the levels are always given in a specific order, one may represent a tower as a tuple of objects.
All kinds of objects are modeled by towers. Thus, a link tower might consist of a structural level maintaining the link's set of anchors and an indication of its direction, a presentation level indicating that it will be drawn as an arrow on the screen with a particular color and appearance, and a semantic level indicating the meaning of the relationship between the source tower and the destination tower.
An anchor tower would include a description of its location in the node(s) to which it is attached and its graphical rendering on the screen. An anchor for an N-ary relationship link would also include a semantic level giving the role of the attached node in the relationship.
The number and nature of the levels of different kinds of towers is completely arbitrary (unlike the fixed levels in other reference models). Thus, one can have towers with only a graphical rendering level. These may be useful to describe graphical overviews of documents where the contents of individual nodes are not part of the overview. Such tailorability of the tower structure permits the integration of information from outside the hypermedia system. Thus, an object-oriented database management system might provide to the hypermedia system only a structural description of an interlinked collection of information. This information is modeled by a rather simple tower to which a a presentation level might be added later by means of a user interface toolkit.
A tower of a composite object, called a composite tower, packages together the multiple levels of description of a composite object. As a composite object is a collection of objects which would be themselves towers, a level of the composite tower is built from the corresponding levels of the elements of the composite. We have previously motivated the need for composite objects of all kinds and of a variety of structures but our discussion was purposely not targeted to any particular level.
Now, that we have introduced the tower construct, it is natural to apply it to composite objects. One can observe that corresponding to composite structures arising at the structural level of a composite object, there are composite descriptions at the other levels, which are just as varied as its structural level. Accordingly, we would need presentation constructors (e.g. menu constructors) that build a composite presentation from given elements, besides the structural constructors (e.g. tables) that build a composite data structure from its elements. Levels of a tower of composites are defined in terms of the appropriate constructors for objects of that level. Having these constructors on all levels is the way the visualizations would be tied to the actual information.
A composite tower constructor is a mapping from a set of labels to a set of composite object constructors. Each label is a description level, corresponding to a separate level of the composite object functionality. A composite constructor builds a composite object of the type of its level from a set of elements (coming from the corresponding level in the towers of the elements of the composite object).