> The reason that we have <hi> in the TEI scheme is  because there will

> always be cases where deciding which of the possible semantics
> is hard or impossible or just too expensive to do accurately and 
> consistently. This applies to modern material  just as much as it
> to early print. So use it in good health. It's up to you to decide
> "semantic" decisions are useful to you. And, by the way, doesn't the

> same set of issues apply to "non-semantic" markup -- when we say
> in Italic" we're usually confounding several different font
Exactly.  It is an exaggeration to say that every encoding is an
interpretation, but with strictly semantic markup one can come
perilously close.  Take the following half-sentence from Calamy, which
with visual markup would look like this:
<s>Mr. <hi rend="it">Martin Johnson</hi>, a Neighbouring Minister at
<hi rend="it">Womborne</hi>, who tho' <hi rend="it">high</hi> in his
Principles, was yet a Lover of all honest peaceable Men, <!-- etc. -->

The first instance of italics is certainly <persName>, the second
<placeName>, but what is the third?  Is it right, in such a case, to
commit an encoding to a semantic which other users may not agree with,
or is it preferable to use markup which effectively says "this feature
occurs but you have to make up your own mind why (if you feel it
necessary to make a decision at all)?"  The answer will probably vary
according to the purpose and persons for whom the encoding is being
made, but I would not like to be denied the latter choice.

Another example would be Lafcadio Hearn's inconsistent use of italics
for Japanese words in his writings.  One needs to be able to distinguish
between <foreign rend="it">oshidori</foreign> and <foreign
rend="rom">oshidori</foreign>, or, if you prefer, between <foreign><hi
rend="it">oshidori</hi></foreign> and <foreign>oshidori</foreign>.

In other words, purely semantic markup is possible only when you KNOW
all the semantic distinctions that are being made in a text, and the TEI
must make provision for those cases when you don't. In practical terms,
this probably means that most projects will require a mixture; that it
will be different according to the nature of the project; and that you
should be you should be consistent (and explicit) within a project.