Anchoring in the Dexter model

The Dexter model provides a unique identifier (UID) for each component. But in order to implement links from/to parts of a component it must be possible to also identify substructures within components. In order to preserve the boundary between the hypertext network per se and the content/structure within the components, this mechanism cannot depend in any way on knowledge about the internal structure of (atomic) components. In the Dexter model, this is accomplished by an indirect addressing entity, called the anchor. An anchor has two parts: an anchor id and an anchor value. The anchor value is an arbitrary value that specifies some location, region, item, or substructure within a component. This anchor value can only be interpreted by the applications responsible for handling the content/structure of the component. It is primitive and unrestricted from the viewpoint of the storage layer. The anchor id is an identifier which uniquely identifies the anchor within the scope of its component. Anchors can therefore be uniquely identified across the whole universe by a component UID and an anchor id.

The two part composition of an anchor is designed to provide a fixed point of reference for use by the storage layer, the anchor id, combined with a variable field for use by the within-component layer, the anchor value. As a component changes over time (e.g., when it is edited within the runtime layer), the within-component application will change the anchor value to reflect changes to the internal structure of the component or to reflect a movement within the component of the point, region or items to which the anchor is conceptually attached. The anchor id, however, will remain constant, providing a fixed referent that can be used to specify a given structure within a component.