48 Theological librarianship • Vol. 12, No. 1 april 2019

TEI, the need to accommodate the full range of TEI elements when building broadly compliant tools inhibits software development.26 The result is that significant costs, whether in money or in needed volunteer labor, are imposed on projects for custom-building software solutions. This burden is particularly onerous in theological DH, where even projects backed by colleges and universities are often located in chronically under-resourced departments and many projects are driven by the volunteer efforts of professional practitioners, ranging from pulpit ministers with interest in formal theology to missionaries translating texts into indigenous languages.

Lowering the technical bar for participating in encoding was not the only advantage of ThML and OSIS. In many cases, they offered meaningful technical features for which TEI in its standard form does not provide, such as direct representation of verses as distinct from other structures, encoding of recurring dates and non-clock times for lectionaries, semantically accurate synchronization of Strong’s numbers, semantic distinction of the Divine Name, detailed representation of hymns as components of larger textual settings, or close granularity in indexing diverse uses of scripture as distinct from other intertextual features. Twenty years on from Plantinga’s original decision not to use TEI, the now-standard digital humanities markup language continues to miss specifics of theological texts, even for quite common features.

Future Possibilities

The way forward is not clear. Despite the advances made by the OSIS team, overlap of elements remains a serious problem without an elegant solution under existing XML frameworks, and it is only one of many stumbling blocks.27 There are signs that XML itself may be reaching crucial limits in its development. In the meantime, however, it remains ubiquitous, and TEI continues to reign as the markup language of choice for textual encoding. Under these conditions, it would seem that a few useful lessons can be learned from theol-ogy-specific markup experiments.

There is real value to offering a streamlined markup with low technical overhead for learning—at least at its basic levels of execution. Given the nature of its constituencies, theological digital humanities work would likely benefit from a TEI customization scoped down to approximately the size and complexity of OSIS, but this would have to be, like OSIS itself, a coordinated effort. Basic agreement would have to be reached on the representation of verses, the encoding of overlap, and other such issues—agreements for which OSIS can perhaps offer a starting point in discussions. To this point, TEI customizations have largely been themed around the kind of material being represented, and it may be something of a shift to think of customizations in terms of a clientele served, or of the nature of the outputs to be produced. This can have not only technical benefits, however, but also cultural ones. Phrasing a markup language as general purpose can create the impression that it is for technical specialists, who bring that particular expertise to a variety of teams, and that it may largely be set aside by others. The presentation of a specifically theological markup language, however, suggests a disciplinary skill to be acquired by all serious participants in the discipline and may encourage more uptake of technical skills among scholars.

If TEI is to fully capitalize on the lessons of ThML and OSIS, however, it must not only be scaled back in some areas to focus on the particular purposes of theological work, but it must also be expanded in other areas to meet the unique needs of that work. TEI holds as an objective that it should provide modularity and extensibility to cover all kinds of textual encoding work. If that aim is to be realized, it would do well to look at the features that have made ThML and OSIS so stubbornly enduring within their narrow communities, and to take their longevity as proof of the distinctive value of many of their features. Some will be implementable through compliant customizations in the near future; others may await incorporation into a more distant P6 release. In either case, a TEI customization offering a smaller but more precisely defined toolkit for the

26 Schmidt, “The Role of Markup,” 128-129.

27 Schmidt, “The Role of Markup,” 129.