naming and description of TEI Simple Print and TEI Lite #2035
Comments
|
It would be very easy to add processing models to TEI Lite, basically a case of copy and paste. Rather more effort would be to review and extend TEI Lite prose though substantial parts on the TEI Processing Model could be salvaged from https://tei-c.org/release/doc/tei-p5-exemplars/html/tei_simplePrint.doc.html#processingmodel I'm not sure if we know of anyone actually relying on the TEI simplePrint schema? I wouldn't mind to drop it personally. |
|
Qua schema, simplePrint is redundant. I’ll repeat saying that the TEI word would be better off with an updated TEI-Lite—perhaps renamed Vanilla because it really would be a better name and no less silly.
The EarlyPrint project uses simplePrint, but calls it http://schemata.earlyprint.org/schemata/tei_earlyprint.rng. It adds the @orig and @norm attributes recently added. Actually we use @reg at the moment, but will switch to @norm.
You may remember, Magdalena, that the Simple project started out with a census of the half dozen or so schemata that were “Lite” like in some way or another and dropped some Lite elements that had hardly ever been used.
|
|
As far as I recall, simplePrint was precisely intended to be teiLite plus the processing model, with a few other odds and ends changed. The argument then, as now, is that TEI Lite has historical value and should not be changed. By all means, re-run the simplePrint design process, i.e. make a new lightweight schema with whatever components you think would be useful this time round, and call it whatever you like, but please don't confuse things by pretending it is a new version of TEI Lite: the decision was taken to freeze that. |
|
Lou, would adding processing models be changing (for the worse) that historical value or just a development for the better? |
|
Magdalena, I don't think you understand my point. Lite is a document that has not been revised in many many years. Last time Council looked at it, it agreed that so much would need revising to bring it up to date (and this was before the existence of the PM) that it would be better to leave well alone and preserve it as a historical monument. I think that was a wise decision. You can't just "add processing models" without rewriting the document substantially. Moreover, as you seem to have forgotten, the current simplePrint document was largely made by attempting to do precisely that (revising TEI Lite). So if anything is to be modified it should be simplePrint. |
|
p.s. Lite was not named after a beer. |
|
Ah, I see. I have indeed forgotten about this reason for not touching Lite. So, would it be fair to summarise Martin's proposal as (forgive me Martin for (over)simplifying things but this being the issue tracker we should discuss actionable items, I fear):
|
|
No, you didn’t simplify thing, Magdalena. You hit the nail on the head.
|
|
Basically 1 and 2 do not require Council's blessing (or even direct involvement, though I'm sure we are interested) and it might be easier to discuss 3 and 4 having the work on Vanilla completed. |
|
One more point about the name: it should not belittle, but state what you can do. Some snazzy version of TEI-Most-of-what-you-will-ever-need, which would have been a fine, if rather long’ name for what TEI-Lite did.
From: Magdalena Turska <notifications@github.com>
Reply-To: TEIC/TEI <reply@reply.github.com>
Date: Tuesday, September 15, 2020 at 2:36 PM
To: TEIC/TEI <TEI@noreply.github.com>
Cc: Martin Mueller <martinmueller@northwestern.edu>, Author <author@noreply.github.com>
Subject: Re: [TEIC/TEI] naming and description of TEI Simple Print and TEI Lite (#2035)
Ah, I see. I have indeed forgotten about this reason for not touching Lite.
So, would it be fair to summarise Martin's proposal as (forgive me Martin for (over)simplifying things but this being the issue tracker we should discuss actionable items, I fear):
1. finding a sexy name for entry-level, 80-20 TEI customization, e.g. Vanilla TEI
2. effectively repack TEI simplePrint (plus or minus few modification) as Vanilla
3. deprecate TEI simplePrint and possibly TEI Lite
4. actively advertise Vanilla as the recommended way to start with TEI
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/TEIC/TEI/issues/2035*issuecomment-692964427__;Iw!!Dq0X2DkFhyF93HkjWTBQKhk!BywQpY_79Se7AwZLRU78nlXF5XpSR7PWQ3nGYo2QFh1jGXS4Yvi2SFxyABOJzl2rAd_joV728A$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/ABL7UL2DYNVLXWHWCXDRATLSF7FZ7ANCNFSM4RMEBNPQ__;!!Dq0X2DkFhyF93HkjWTBQKhk!BywQpY_79Se7AwZLRU78nlXF5XpSR7PWQ3nGYo2QFh1jGXS4Yvi2SFxyABOJzl2rAd9yumt2oA$>.
|
|
Some specific suggestions for a name might be more helpful, so here are a few: -- simple All prefixed by TEI_ presumably. Another thing which would be helpful would be some specific proposals for change in the current simplePrint text/schema |
|
As discussed in the Council meeting today, we're happy to wait for a PR on Vanilla (or whatever name) exemplar to perhaps supersede teiSimplePrint, meanwhile closing this ticket. |
I recently looked at the TEI Customization page and was taken aback by the description of both TEI simplePrint and TEI Lite. The latter is described as "including basic elements for simple documents". The former is described as an "entry-level customization, focused primarily on the needs of those encoding Western European early modern printed material." Both description are wrong and deeply misleading. The documentation for TEI Lite begins with a passage from Jane Eyre, not a notably simple document, and there is nothing in the TEI simplePrint schema that restricts it use to Western European texts.
I should have paid more attention to the final stages of what came to be known as TEI simplePrint, but Sebastian's final illness and death threw much of the work of the Council in disarray and worrying about a particular customization was understandably not high on the list.
The range of documents that can be and have been encoded under TEI Lite, TEI simplePrint, Stage 4 of the TEI Guidelines for Libraries, the dtd of the German Text archive, the EEBO dtd etc is very large. The documents are not simple, and the encoding choices can be very complex--witness almost any contribution by Paul Schaffner to this or that encoding problem. So it seems to be a misuse of the terms 'simple' or 'basic' to describe the range of encoding activities that can be achieved within the parameters of those schemata. It is also terrible marketing.
The excellent introduction to TEI Lite said that this pure subset of TEI-All was designed to meet 90% of the needs of 90% of the users--a classic 80/20 distribution. A visitor from Mars might ask why the TEI has half a dozen customizations that for all practical purposes do pretty much the same thing. It might make sense for the TEI to spend some time on weeding out what may be unnecessary and confusing duplication.
The major point of what came to be known as simplePrint was actually not the schema, but the Processing Model. I would have happily settled--and I believe at one time proposed--to abandon TEI Simple for TEI Lite with a Processing Model. "Lite" was named after a beer. The "Pizza Chef" is another culinary metaphor. "Vanilla" would be a better name for something that meets 90% of the users 90% of the time. There is nothing particular simple about Vanilla, but it does pretty much everything you want from ice cream.
Almost a decade I wrote a long letter about the TEI in which I expressed concerns about the TEI losing a broad base of members and financial support. I take little pleasure in observing that most of what I then predicted has come about. Shakespeare's first editors addressed "the great variety of readers, from the most learned to him that can but spell (quoting from memory). That's a wonderful marketing tag line, and if the TEI wants to prosper it needs to speak more energetically and sympathetically to a broader audience. Call it Project Vanilla
The text was updated successfully, but these errors were encountered: