Hi Martin, and thanks for quick reply. On 29/06/16 14:56, Martin Mueller wrote:

Lou,

I cc Hugh Cayless, because I’m not sure that I can write to the Council list

The only use case envisaged in Simple for facsimile was a basic “digital combo” that lets you go from text to image. Do we need more than ‘facsimile’ for that? It seems to me that ‘surface’, ‘surfaceGrp’ and ‘zone’ take us into concerns with the “materiality” of the text that I explicitly marked as out of scope for the Simple project.

You need surface and surfaceGrp to cope with the not uncommon situation where your page images don't correspond tidily with the structure of your text e.g. you have images of a double page spread. Adding zone is very little extra overhead for quite a lot of benefit (e.g. aligning image and transcription)

We purposely included “rhyme” the schema in September 2014, and I remember Martin Holmes writing at the time that this was a useful element for tagging a very primitive but important component of poetry.

OK, no problem to put it back, though I cannot say that I agree with Martin H. on this one.

“desc” is used all the time in Sebastian’s P5 version of the EEBO texts, and it was a basic design decision that Simple needed to do EEBO, whatever else it did.

Agreed, but where is <desc> used in the EEBO texts? (as opposed to EEBO headers)?

Is ‘c’ in the element list? It seems to be commented out, but it should be in.

I have put it back now.

What are the current header elements that you’d like to throw out rather than restrict just to the header? Is particDesc one of them?

The list of elements rejected from the header module is in my mail below. particDesc is not included partly because its provided by the corpus module, but mainly because it is pointless having it unless you also provide <listPerson>, and <person>, and all (or at least some of) the many many possible children of <person> . Which I think is overkill for a simple schema.

There is a larger issue here about the place of TEI Simple in the TEI ecosystem.

To my mind, the larger issue is the lack of clarity as to what the design goals of Simple actually are.

I recently went through the Council minutes and came across the first discussion of TEI Simple. Sebastian at the time said “If all this goes forward, we would eventually end up with something like TEI Tite or Lite, and Council would inherit it; we might then decide to retire Lite and use this instead. One of the work packages is to extend ODD anyway, so there would be a lot of input by Council.”

As indeed there was. And that is why the Procmod is now in the TEI.

The main point of that project was always the Processing Model. If we now end up with something called ‘Simple’ and something called ‘Lite’ we just add confusion and force newbies to ponder when they should use Lite and when Simple. Ditto for Best Practices in Libraries Level 4.

I disagree. The whole point of the TEI is that it offers multiple entry points. And long may it continue to do so.

What we need is a single point of entry into the TEI ecosystem. It is in many ways misleading to call it either ‘lite’ or ‘simple’. It would be better to choose a name that articulates the goal admirably stated in the introduction to Lite: “meet 90 percent of the needs of 90 percent of the users.” And that single point of entry should be readily accessible to a person who knows next to nothing about XML.

You cannot use Simple or any other TEI schema without some knowledge of XML. Sorry, but that's life. You need to know how to operate a keyboard too.

MM

On 6/29/16, 5:25 AM, "Lou Burnard" wrote:

Here's what I have so far done to the tei_simple.odd document so far, and why. Sadly this is not the end of the story, but I will send another message about that anon.

1. The original draft contained large amounts of promotional material about the Simple project, and some tutorial material about XML and about the processing model. I removed all of it, on the grounds that it was either inappropriate or unnecessary in a tutorial introduction to the Simple schema.

2. The schema included a large number of elements which seemed quite inappropriate for something called "simple" -- notably elements relating to detailed genetic transcription, or manuscript description. I removed these: if you want to make a detailed transcript of a manuscript, you need more than TEI Simple, but your task isn't simple either.

3. The schema originally included "all" of the TEI Header (in practice this seems to have meant "all of the TEI Header when only some modules are included", as opposed to "the TEI Header as defined by TEI All"). I can see no good reason for this, so I have defined a subset of the Header, excluding some dozen or so highly specialised elements (specifically: appInfo application cRefPattern calendar calendarDesc correction correspAction correspContext correspDesc geoDecl hyphenation interpretation normalization punctuation quotation refState refsDecl samplingDecl scriptNote segmentation styleDefDecl stdVals typeNote). Simple should make it easier to create a new header; if you want to import an arbitrary header created by someone else, use TEI All.

4. As a consequence of (3) above, the schema originally specified by schematron rule that several elements were permitted only in the header and not in the text. I have simplified these rules considerably; what would be more useful in my view would be to add rules reducing the number of elements permitted in the Header.

6. I removed a few elements which did not seem to me to be either necessary or simple (addSpan, desc, handShift, rhyme, spGrp); I added a few elements which were needed to cope with the presence of bibl in the body of a document (biblScope, editor, email, relatedItem); I added facsimile, surface, surfaceGrp, and zone since the text seemed to imply that there was a Simple use case for digital facsimiles.

5. I systematically checked that every element defined by the schema was at least referenced by a specDesc in the body of the doc, and where possible accompanied by some minimal explanation or exemplification. This turned out to be a lot of work, since the original document was extremely detailed in some cases and entirely silent in others. I also took the opportunity to bring some of the prose up to date and to simplify some of its language, though undoubtedly there is more to be done there.

You can see the current state of the draft in the dev repo, at P5/Exemplars/tei_simple.odd