Overall: excellent. I do not think this should be restricted to your workshop audiences. I very much hope you submit a version to the upcoming TEI conference. (I also hope that you explicit release it under some FLOS license or other, but given that it is already so by virtue of being on GitHub, it's not entirely necessary.) I can imagine this being required reading, e.g., in a DH certificate program. I would certainly use it as reading material in my modeling class (e.g., that James & I put on at DHSI last year). I had to look up what 'rugosities' means. :-) Nit-picks: * "RELAX NG" is spelled with a space. * Typo: "cuustomized" * Might be useful if the list of what a full TEI element specification contains were a labeled (<soCalled>ordered) list so that you could refer to "processing model" as "#7" or "g." or whatever. Issues: * I don't think the discussion of how TEI recently upgraded to Pure ODD is particularly germane. I realize it is important to the TEI, and to you, personally, but I don't think its discussion here adds a lot to the paper. I would relegate it to a footnote. * The idea that constraints are also expressed "in addition to the content model" (e.g., with @restriction or Schematron) is barely touched upon, but (IMHO) is important to the point at hand. * I think it worth noting that the criticism "that their focus on data independence leads to a focus on the platonic essence of the data model" is at other times considered an advantage, not a liability. Either way, like the discussion of Pure ODD, the discussion of the processing model is not directly relevant to conformance, especially since you are not arguing that to be conformant a TEI application must adhere to the processing suggested by <model>s. * "As noted above, a simple TEI customization can be made by selecting": Maybe I just missed it, but where was it noted above? * Why on earth do you say that "new elements should be included in existing content models by making them members of existing TEI classes for example, rather than by explicitly modifying the content model of an existing element"? It strikes me as completely untrue. If you intend your new lb:blort elements to occur inside <item>, and never anywhere else, I would argue it should be added directly to the content model of <item> and not to macro.specialPara. * I will argue that a publication statement or source description that is really "entirely vacuous" (i.e. is empty) does not meet the intent of TEI conformance. Perhaps "so vague as to be useless"? * "TEI Header element cannot ever be validated": While technically true, many people use the term "validated" slightly loosely to mean "attempted to validate against formal declaration" or some such. Those folks will be (mildly) confused. So it might be better to re-word to "cannot ever be considered valid" or "cannot be TEI conformant" or some such. * "following diagram": no diagram in the GitHub view of this document. * "For example, the TEI Guidelines require that a modification ... that ... TEI elements whose definition has been modified in such a way that instances of them would no longer be regarded as valid by tei_all, should not be defined within the TEI namespace". Really? I'm not sure that's true, but seems problematic if it is. I gotta go. I won't be back at a computer for hours ...
In the unlikely event that anyone still does, I have written a brief squib entitled "What is TEI conformance, and why should you care?" Constructive comments ate welcome: readable text is at https://lb42.github.io/W/conformance.html This is destined for presentation at a workshop in Heidelberg later this week, but it's not too late for you to make it better!