Fix normative defects in tool registration, notification, and observation

[emecii]

Three normative fixes, each a case where the algorithm text does not do what the surrounding spec says it does, plus one editorial nit in the same area.

registerTool() writes to the struct instead of its tool map

Fixes #213

A [=model context=] struct has exactly one item, tool map, so indexing the struct itself by tool name is not well-defined. Every other algorithm reads through internal context's tool map — see unregister a tool, getTools(), and perform an observation.

perform an observation has an inverted assertion

Fixes #214

It asserts the traversable's active document is not fully active. A top-level traversable's active document is always fully active, and the algorithm then goes on to read that document's descendants, which only makes sense when it is. registerTool(), getTools(), and executeTool() all reject when a document is not fully active.

notify documents of a tool change skips the registering document

Fixes #215

Using descendant navigables excludes the tool owner's own navigable, so the document that registered the tool never receives toolchange. This contradicts the worked example immediately below the algorithm, which asserts that Parent toolchange always logs before Child toolchange for a registerTool() call on the top-level document. The two comparable algorithms — in getTools() and perform an observation — both use inclusive descendant navigables.

Editorial

Removes a stray possessive in perform an observation (|descendant|'s active document's.), matching the identical assignments in notify documents of a tool change and getTools().

---

All three normative issues were filed by @Aravindargutus. No new link targets are introduced — every construct used already appears elsewhere in index.bs.

---

Preview | Diff

[domfarolino]

Thanks for catching these tricky issues, much appreciated!