Design Log
(Historical Decision Record)

This document describes the thinking behind some of the KRNL's major design decisons.

Use "hard-coded" addNode operations in StructureNode

Don't Distinguish Original Parent from Other Parents

When a node is created, its parent is set. When a StructureLink is created, a ReferenceList (rather than parent list) could be created.

Every StructureNode is embedded in a StructureLink

No AttributeNodes or AttributeLists defined in the kernel

It seemed to make sense to have them, at first. The idea was to have a (display)LIST type, with attributes to specify it as ORDERED or UNORDERED. The idea would be that "attributes" are context-dependent features (what kind of ordering to use), while nodes are more fundamental, logical entities. Changing one would therefore be an add and a remove, instead of an attribute change. However, it appears to make more sense to define ORDERED_LIST and UNORDERED_LIST, rather than having attributes to do the job.