The Dexter Hypertext Reference Model. Presented at the NIST Hypertext Standardization Workshop,
Gaithersburg, MD, January 16-18, 1990. pdf 
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 Dexter model divides a hypertext system into three layers, the runtime layer, the storage layer and the within-component layer.
The model is formalized in the specification language Z, a specification language based on set theory. The paper briefly discusses the issues involved in comparing the characteristics of existing systems against the model.
The term "node" turned out to be especially difficult given the extreme variation in the use of the term across the various systems. By providing a well-defined set of named abstractions, the Dexter model provides a solution to the hypertext terminology problem. It does so, however, at some cost.
An extremely critical piece of the Dexter model, however, is the interface between the hypertext network and the within-component content and structure. The hypertext system requires a mechanism for addressing (refering to) locations or items within the content of an individual component. In the Dexter model, this mechanism is know as anchoring.
.
I'm told that hypertext researchers were twisted in a knot about Dangling Links, a situation that Marc Andreessen famously blew off with, just click another one of the million links you have available.
quote
When creating a link the model requires that all of its specifiers resolve to existing components. This restriction prevents the creation of links that are ‘dangling’ from the outset. The model does not, however, include any restrictions that prevent the creation of dangling links via the deletion of linked-to components.
This restriction adequately represents the consistency guarantee of KMS. But its is overly restrictive for Augment, which allows creation of initially dangling links. In contrast, its is not restrictive enough for NoteCards and HAM which prevent dangling links at all times.
As in the case of mechanisms, restrictions of this sort will have to be made optional in the model. Conformance to the model can then be conditionalized on appropriate choices of restrictions. As in the case for mechanisms, systems can compared on the basis of the set of restrictions that they enforce.
.
If I read this correctly, it says that a hypertext system that can't do something about dangling links can't be called a hypertext system. Excuse me.
Wiki did do something about them. It turned them into editing prompts. Although I'm pretty sure that's not what they had in mind.