Upon reading Michael's excellent post, three items jump to mind.
First, a quotation:
The philosophy of the Guidelines is "if you want to encode
this feature, do it this way" -- but very few features are
mandatory. -- P3, sect 1.2.1
> students hired in by the hour to get those tags into place don't
> want to be fussed about all the intricate possibilities ...
At least some of our students *love* getting into deep discussions
about these various possibilities. In many ways that's a good thing,
although it does have its downside, too.
This does not at all invalidate Michael's point about having a
"how to apply the Guidelines" handbook. In fact ...
... lastly, advice from the trenches:
> ... local handbook (even if it's only in the solitary encoder's
> head) ...
It's been my experience that even for relatively small projects I can
never keep the various decisions about how to encode (or how I have
encoded) the various features of a text in my head. Write them down,
even if on (gasp!) paper.
If recollection serves the Guidelines do not say much about how to
document such details, although it is possible that the auxillary tag
set for tag set documentation could be used. (As Julia and others can
atest, I have been whining about wanting to try to encode our local
"handbook" using this auxillary DTD for years.) Either way (i.e.,
whether that auxillary DTD is useful for this purpose or not), I
think the Guidelines should address such a handbook directly. Work
for P5 ...