Message from Martin Mueller to the TEI-L list, pertinent to our discussion
of Lite 2.
---------- Forwarded message ---------
From: Martin Mueller
Date: Mon, Aug 21, 2023 at 6:44 PM
Subject: More about TEI Lite
To:
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.
--
Elisa Beshero-Bondar, PhD
TEI Technical Council Chair
Program Chair of Digital Media, Arts, and Technology | Professor of Digital
Humanities | Director of the Digital Humanities Lab at Penn State Erie,
The Behrend College
Development site: https://newtfire.org
