"4.5 Good Practice A: Define an error handling mechanism" -- another
useful technique that could be mentioned here is designing the spec so
that there are few ways to get into an error case (for example,
defining the meaning of every combination of language construct).

Also, this section should spend more time on the concepts of
mustIgnore and mustUnderstand (and why the camelCase?). Both have
their places: mustUnderstand is important when data corruption could
end up having critical consequences (e.g. a corrupted credit card
transaction could be costly), whereas mustIgnore is important when the
worst effect data corruption could have is a slightly degraded
rendering (e.g. a corrupted stylesheet).