Hi Martin Thanks for your quick reaction. I hope you'll find time to re-read and nitpick the text of the document in the near future: there are undoubtedly passages that need some further work. Just a few comments on your more general comments below: On 29/07/16 14:53, Martin Mueller wrote:

From the perspective of the newcomer it may be confusing that there is something called TEI Lite and TEI Simple. The newcomer, however, may not discover either because on the TEI Web site they are squirreled away under the subheading "Customization."

That's a fair point, which I hope the designers of the new Website will take on board. In French, rather than "customization", we tend to say "personnalisation" which sounds more, um, personal. But clearly the website ought to alert the first time reader to the fact that (a) the DTD is not a single monolithic entity (b) amongst its many incarnations, Simple is a good starting point for a range of applications.

Assuming newcomers discover both Lite and Simple they may ask "Which should I use?"

Indeed. They may also ask wonder whether maybe TEI_bare would be suitable. Or Epidoc, or any of a number of other possibilities.

And if they look at the documentation they may be confused by the fact that, leaving aside the Processing Model, the documentation for the two customizations is virtually the same.

Much of it is the same. But there is also quite a lot that's different. Lite represents the state of the TEI of about 10 years ago, when we deliberately decided not to adapt it further, but move it to a "bugfix only" state of support. Simple has some (though not all) of what we've learned in the last decade.

So for most practical purposes TEI Simple is TEI Lite with a Processing Model, a few elements removed on the basis of usage figure, and a few elements added.

I think that's an oversimplification. There are a few policy-like decisions reflected in Simple which are not in Lite: e.g. use of @ref rather than @key, use of @rendition rather than @rend.

From which I draw the conclusion that Lite and Simple should be merged, given a name that more accurately describes what either of them can do, and put very prominently as the recommended point of entry into the TEI world.

I couldn't agree less. They are different documents, representing a consensus as to what's a useful minimal subset at different times in different situations. You could argue that Simple should *replace* Lite possibly, but "merging" makes no sense at all.

I have spent a fair amount of time with versions of the Best Practices in Libraries document.By far the most important section of that document has always been "Level 4". Much can be said in favour of merging Level 4 with that general introduction. Time and energy are in short supply, and maintaining one entry-level version with really good documentation is a lot better than sort of supporting three. Besides, "TEI in Libraries" is a very different thing from what it was twenty years ago. The modal library TEI project may no longer be something like "Wright American fiction." It's more likely to be some project where a faculty member or student goes to the Library for some help because the Library is the go to place for DH stuff. That's the case at Northwestern, and it's the case in many other places.

I have no views on BPL. Though it would obviously be nice to know what that group thinks of Simple's header section.