Dear Council, Here is a 1st crack at my submission for the TEI conference, due tomorrow. I've listed all fields, but am only asking y'all to review and edit the abstract (which has to be <= 300 words -- it currently has 329), and to suggest a better title if one jumps to mind. ################################## Title ----- tei_customization: A TEI customization for writing TEI customizations Abstract -------- The TEI ODD language (and the more modern version thereof, Pure ODD) can be used for two related, but distinctly different purposes: 1) to *create* a markup language, including documentation and schemas; and 2) to *customize* a markup language that was already written in ODD. There are several examples of (1), including the TEI Guidelines, the Music Encoding Initiative, the ISO Feature Structure encoding system, the W3C Internationalization Tag Set, and a version of the Itsy Bitsy Teeny Weeny Simple Hypertext DTD. And there are several well known examples of (2), including TEI Lite, TEI Tite, TEI Simple Print, CBML, DALF, DHQ, jTEI, and the TEI in Libraries Best Practice Guidelines. But the TEI Guidelines are not meant to be used out of the box -- *every* TEI project is expected to customize the TEI, thus they are all expected to create a customization in ODD. The 'tei_odds' customization provided by the TEI is, understandably, a schema intended to check conformance with the rules for using ODD. Because ODD is used for two different things, and for both TEI and non-TEI languages, those rules are necessarily much more broad than those for writing TEI customizations. E.g., the value of the @key attribute of <moduleRef> can be any XML name. But when used to write a TEI customization, the only valid values are the actual names of TEI modules (e.g., "core", "textstructure", "header", "namesdates"). The tei_customization customization is not intended to produce a schema that can tell you what is "correct" or "incorrect", but rather to *help* you write a TEI customization. So, e.g., only the names of TEI modules are allowed as values of moduleRef/@key, and thus your editor can give you a pop-up box of those values. This paper will describe (and the talk will demonstrate use of) tei_customization, and discuss the interesting twist that this is not a schema whose rules must be obeyed, but rather an editing assistant. Keywords -------- TEI, Customization, ODD Bibliography ------------ 2016-08: “The Hard Edges of Soft Hyphens.” Presented at Balisage: The Markup Conference 2016, Washington, DC, August 2–5, 2016. In Proceedings of Balisage: The Markup Conference 2016. Balisage Series on Markup Technologies, vol. 17 (2016). DOI: 10.4242/BalisageVol17.Bauman01. 2013-10: “TAPAS and the TEI: An Update and Open Discussion” with Julia Flanders and Elena Pierazzo. Presented at The Linked TEI: Text Encoding in the Web: the TEI Conference, 2013, Rome, Italy, October 2–5, 2013 2013-06: “Encoding Historical Financial Records” with Kathryn Tomasek. Presented at Digital Humanities 2013, Lincoln, NE, July 17, 2013. 2012-11: “Encoding Financial Records for Historical Research” with Kathryn Tomasek. Presented at TEI and the C{rl}O{wu}D: the Text Encoding Initiative Conference, 2012, College Station, TX, November 8–10, 2012. In _Journal of the Text Encoding Initiative_, Issue 6 | December 2013. URL: http://jtei.revues.org/895; DOI: 10.4000/jtei.895 2011-08: “Interchange vs. Interoperability.” Presented at Balisage: The Markup Conference 2011, Montréal, Canada, August 2–5, 2011. In Proceedings of Balisage: The Markup Conference 2011. Balisage Series on Markup Technologies, vol. 7 (2011). doi:10.4242/BalisageVol7.Bauman01. Remark / Message to the Program Committee and Chairs ------ - ------- -- --- ------- --------- --- ------ Although I am indeed affiliated with Northeastern University (and that institution must be listed), I am also affiliated with the TEI Council, who charged me with writing this paper.