> > The reason that we have <hi> in the TEI scheme is because there will > always be cases where deciding which of the possible semantics applies > is hard or impossible or just too expensive to do accurately and > consistently. This applies to modern material just as much as it does > to early print. So use it in good health. It's up to you to decide which > "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 "it's > in Italic" we're usually confounding several different font variants. > 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. --> </s> 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.