I read through the minutes of the Technical Council that discussed my proposal to phase out simplePrint and merge it into a new version of TEI Lite that includes the Processing Model.   I was pleased by the thoughtfulness of the discussion. Much of it was given over to naming the child, and I have a half-serious suggestion about that. Why not rechristen Lite and All TEI200 and TEI600?  TEI-All has not quite 600 elements, and a revised TEI Lite falls short of 200.  But the names give you a good sense of scale. TEI600 has a lot of elements, and TEI 200 has quite a few.  The names get you out of implicit and confusing value judgements about what is ‘lite’ or ‘simple’.  It may sound too much like F150 or C300, but that’s another matter, and some might like it for that reason.

I disagree a little with the comment that “the phrasing of 90% of the needs of 90% of the community” is “outdated”. Pareto distributions and other power laws are pretty universal in their application. “90 % of the needs of 90% of the users” is an excellent version of the 80/20 rule.  If anything,  progress over the past quarter century may mean that the rule applies even more now than it did when it was used in the preface to the first version of TEI Lite.

I remember working on a moderately complex project some twenty years ago. It was SGML rather than XML, and validation told you that things didn’t work without telling you much about the where or what of the errors. It’s a mystery to me now how I got it to work, though I did. Since then, the access costs to working with any kind of XML have dropped sharply, and folks with very little previous experience can “ramp up” quickly to doing useful work.  If you belong to that category of users, it’s probably a good idea to ask yourself whether you can solve your encoding problem within a space of 200 elements rather than 600, not to speak of adding your own customization.

That takes us back to the Nobel Prize behavioural economist Richard Thayer, who argued that in most walks of life people make better decisions if given a limited number of standard choices, as long as they can opt out.  We all like to think that our projects are special, but typically they are not that special. A friend of mine told me that in Medical School he learned that “when you hear hooves behind you think horses not zebras”.  Physicians like “interesting cases”. Patients not so much.

This is good advice much of the time, and especially for groups like the Technical Council.  Any such group is likely to have a preponderance of geeks, and geeks are more interested in exciting, new, and technically challenging things. Steven Pinker in his recent book on writing has a whole chapter on the problem that the hardest thing for a writer is to imagine what the reader does not know.  Geeks share this problem, and groups like the Technical Council need to remind themselves constantly about the need to countersteer and focus on what most users do or need most of the time.

Ben Shneiderman observed that good software should have “low thresholds and high ceilings”.  From the bread-and-butter perspective of a thriving TEI enterprise, lowering the threshold should remain a key goal. I’m not much of a TEI expert, but I am an expert on the attitudes and anxieties of the key user community of people in English departments and their neighbours.   Quite a few years Jerry McGann equipped about TEI as an acronym for terra incognita. Alas, the quip may still apply.  The TEI has man virtues, but preaching beyond the choir is not one of them.

It would be a good idea for the Technical Council to apply the 80/20 rule in such a way that 80% of the work is done on lowering the thresholds.  TEI-Publisher, the happy child of the TEI Simple project, has done a lot of good work on that front. But even there much of the documentation is not as  successful as it might be in keeping mind what the reader does not know.

I have on occasions argued for the need of a “Small Catechism”  to accompany the “Grand Catechism” of the TEI Guidelines—a magnificent document in some ways but not reader-friendly in others. The most useful part of the Guidelines is Appendix C1—the easiest and quickest way to figure  out where an element may or may not occur. Since Appendix must be based on a program, it should be possible and not very expensive to create a version that Is populated only by the most frequently used elements (TEI 200 or whatever you call it.

From one perspective you don’t this: it doesn’t tell you what you can’t get from the full version. On the other hand, a TEI200  catalogue of elements and their behaviours would give novice users a much better sense of the TEI architecture.