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.