A general word carries its object
A rule names the concrete thing it means rather than a general word for it: not “a limit on how many records a listing shows”, which also let an export drop records, but “a limit on how many records a user interface shows”. Where a general word cannot be avoided — a model, a structure, a check — it carries its object in the same phrase: the structure of which record, the check at which moment comparing what with what, the model of what. A name the specification defines — a term, a data record, a field — is never a general word alone, such as type, action or item, but carries its object: userAction, not action.
A rule has no conversation around it to supply a missing object, and a general rule has the least context of all, so every reader supplies an object of their own and the rule binds whatever each of them chose. Nothing about the word itself looks wrong, which is why the ambiguity survives every reading. A defined name is read in every rule that uses it, far from its definition, and a general one there means whatever each rule's context suggests: a field called type held a kind of request in one log, a user's action in another and a kind of error in a third.
The decisions taken on it
- Problem
Its examples were drawn from one project a reader of the method does not know.
- Ruling
The owner: the examples name what any system has — a user, an operator, a data record, a request — and nothing of one implementation; the worked example's subject stays in the example.
- Problem
The schema of a node names several of its fields type and one kind, general words this rule keeps a name the specification defines from being.
- Ruling
The owner: a field of the node schema is read within the object holding it, which carries its object, so the schema keeps type and kind.