Balisage Paper: The integration of XML databases and content management systems in digital editions

Web application middleware

A common architecture for web interfaces that incorporate a DBMS (relational, XML, or other) is that user requests are mediated by a standard HTTP server, such as Apache running on ports 80 and 443, which delegates the job of processing requests to some middleware, such as PHP scripts, web frameworks like Ruby on Rails or Django, or many other alternatives. Under this approach, the front end is generated by the middleware, which queries the database (commonly via a REST interface) for information to be presented in the view. Views might be created by transforming XML to HTML with XSLT, or by including HTML fragments generated directly from eXist-db using XQuery. This architecture is similar to that of the fundamental open-source LAMP stack: Linux (OS), Apache (HTTP server), MySQL (DBMS), and PHP (middleware language), with the DBMS role replaced by eXist-db. Obviously, PHP is only one option for the middle tier language, and here it should be understood to be replaceable by any language filling a similar niche.^[5]

The strictest implementation of this type of system in an eXist-db context relies on eXist-db only as an XML database, that is, as an alternative to the MySQL component of LAMP. For example, a PHP script running inside an Apache server on port 80, which is the only direct point of access for the end-user, might incorporate user-supplied form values into a constructed XQuery script that is then passed into eXist-db using the eXist-db REST interface. The results of the query are returned to the PHP script, which then shapes them into HTML, associates CSS and JavaScript, and returns a response page to the user. Under this stricter model, any CSS and JavaScript reside on the Apache server because they are part of the front-end functionality, and not of the DBMS services. And the only part of the content of the returned page (the modified View) that is connected to eXist-db is information that depends on XML stored inside eXist-db. The rest of the HTML returned page is a literal part of the PHP script.

Looser implementations of this approach might offload additional Controller functionality onto eXist-db. For example, XML retrieved from inside the database might be transformed to HTML markup inside eXist-db, using the XQuery typeswitch() expression or XSLT by way of the eXist-db transform:transform() function^[6] instead of by the PHP script after the eXist-db query returns. Looser implementations might also store the XQuery script inside eXist-db and pass it user-supplied parameters, instead of integrating the parameters into the query within PHP before passing the entire constructed query into eXist-db. And looser implementations might store some front-end components inside eXist-db, such as CSS and JavaScript, although these might most properly be regarded as aspects of the View, rather than of the Model. What these variations all have in common, though, is that PHP provides all or most or, at least, some of the Controller functionality of the MVC architecture.

One advantage of using eXist-db only as a DBMS, and limiting its role as Controller, is reducing dependency on custom features of eXist-db. To the extent that this separation of concerns allows the use of standard XQuery, with no non-standard, implementation-specific features, users may replace eXist-db with an alternative XML DBMS, such as BaseX [BaseX] or MarkLogic [Marklogic], with minimal adjustment to the Controller. However, insofar as all XML DBMSs rely to some extent on custom functions in custom namespaces^[7], it is unlikely that a useful application of any complexity will be able to avoid proprietary features entirely. It is nonetheless the case that an application that does not rely on application-specific features at the Controller level reduces—even if it does not entirely eliminate—the extent of the lock-in to a specific XML DBMS product.^[8] The use of Free Software products, such as eXist-db and BaseX, reduces it further. For certain types of application, a second advantage may come from limiting the use for dynamic (and therefore slower) querying of the database in the construction of most views. Relatively static outputs can be cached in the middle layer and regenerated only when the sources are changed, with dynamic querying therefore restricted to operations like searching. This kind of strategy can pay great dividends in application performance, although at the cost of having to manage a cache.

The principal disadvantage of using eXist-db only as a DBMS and locating all of the Controller logic in the middleware is an increase in the complexity of the overall architecture. Specifically, in this arrangement the Controller interjects a PHP layer between the View and the core XML DBMS services provided by XQuery within the Model, and the need to communicate between PHP and XQuery introduces an additional potential zone of failure. The separation of concerns (Controller in PHP, which interacts with a Model that understands XQuery) is generally (and not unreasonably) considered a virtue because of its modularity, since the connectivity between the two is mediated through an API. For example, PHP that knows how to communicate between a web form and a relational DBMS can be reused to communicate between the same form and an XML DBMS by adapting only the API-specific parts (for example, by replacing SQL queries with XQuery ones). But this modularity comes at the price of lengthening and complicating the distance between the View and the Model. For example, when a query fails during development under this approach, the failure may reside in the PHP code, in the XQuery code, or in a miscommunication (REST connectivity, API, or other). The PHP layer also complicates deployment because it requires configuration of both eXist-db and PHP resources on the host. With that said, this is an old and very widespread architecture in the relational DBMS world, as in the familiar LAMP architecture.

We have applied several varieties of this middleware strategy in production. The most manageable (easiest to develop, debug, maintain) arrangement has involved the following workflow:

XQuery, the server language

collection("/db/apps/punch/data")
/tei:TEI/tei:teiHeader/tei:fileDesc/tei:titleStmt/tei:title

for $issue in collection("/db/apps/punch/data")/tei:TEI
let $title := 
  $issue/tei:teiHeader/tei:fileDesc/tei:titleStmt/tei:title
  order by $title
  return 
    <li>{$title/string()}</li>

let $issue := request:get-parameter("issue", "")
(: We take $issue, e.g. 1914-07-01.xml, and can reconstruct the path 
 : to this document in the database by concatenating the base path 
 : to all Punch data with the $issue parameter. :)
let $doc := doc(concat("/db/apps/punch/data/", $issue))
let $text := $doc//tei:text
(: snip :)

(: continued :)
let $title := 
    $doc/tei:TEI/tei:teiHeader/tei:fileDesc/tei:titleStmt/tei:title/text()
return
    <html xmlns="http://www.w3.org/1999/xhtml">
        <head>
            <title>{$title}</title>
        </head>
        <body>
            <div>
                <h1>{$title}</h1>
                {
                (: The tei-to-html:render() function takes 2 arguments: 
                 : 1. The TEI we want to display
                 : 2. An optional set of parameters.  In this case, we provide
                 :    the "relative-image-path" for all TEI graphic elements;
                 :    and we use "show-page-breaks" to specify that 
                 :    TEI pb elements should be shown.
                 :)
                tei-to-html:render($text, 
                    <parameters xmlns="">
                        <param name="relative-image-path"
                                  value="/exist/apps/punch/data/"/>
                        <param name="show-page-breaks" value="true"/>
                    </parameters>)
                }
            </div>
        </body>
    </html>

import module namespace tei-to-html = 
    "http://history.state.gov/ns/tei-to-html" at 
    "../modules/tei-to-html.xqm";

(: Typeswitch routine: Takes any node in a TEI content and 
 : either dispatches it to a dedicated function that handles that 
 : content (e.g. div), ignores it by passing it to the recurse() 
 : function (e.g. text), or handles it directly (e.g. lb). :)
declare function tei-to-html:dispatch($node as node()*, 
                                      $options) as item()* {
    typeswitch($node)
        case text() 
            return $node
        case element(tei:TEI) 
            return tei-to-html:recurse($node, $options)
        case element(tei:text) 
            return tei-to-html:recurse($node, $options)
        case element(tei:front) 
            return tei-to-html:recurse($node, $options)
        case element(tei:body) 
            return tei-to-html:recurse($node, $options)
        case element(tei:back) 
            return tei-to-html:recurse($node, $options)
        case element(tei:div) 
            return tei-to-html:div($node, $options)
        case element(tei:head) 
            return tei-to-html:head($node, $options)
        case element(tei:p) 
            return tei-to-html:p($node, $options)
        case element(tei:hi) 
            return tei-to-html:hi($node, $options)
        case element(tei:list) 
            return tei-to-html:list($node, $options)
        case element(tei:item) 
            return tei-to-html:item($node, $options)
        case element(tei:label) 
            return tei-to-html:label($node, $options)
        case element(tei:ref) 
            return tei-to-html:ref($node, $options)
        case element(tei:said) 
            return tei-to-html:said($node, $options)
        case element(tei:lb) 
            return <br/>
        case element(tei:figure) 
            return tei-to-html:figure($node, $options)
        case element(tei:graphic) 
            return tei-to-html:graphic($node, $options)
        case element(tei:table) 
            return tei-to-html:table($node, $options)
        case element(tei:row) 
            return tei-to-html:row($node, $options)
        case element(tei:cell) 
            return tei-to-html:cell($node, $options)
        case element(tei:pb) 
            return tei-to-html:pb($node, $options)
        case element(tei:lg) 
            return tei-to-html:lg($node, $options)
        case element(tei:l) 
            return tei-to-html:l($node, $options)
        case element(tei:name) 
            return tei-to-html:name($node, $options)
        case element(tei:milestone) 
            return tei-to-html:milestone($node, $options)
        case element(tei:quote) 
            return tei-to-html:quote($node, $options)
        case element(tei:said) 
            return tei-to-html:said($node, $options)
        default 
            return tei-to-html:recurse($node, $options)
};

declare function tei-to-html:hi($node as element(tei:hi), 
                                $options) as element()* {
    let $rend := $node/@rend
    return
        if ($rend eq "it") then
            <em>{ 
                tei-to-html:recurse($node, $options)
            }</em>
        else if ($rend eq "sc") then
            <span style="font-variant: small-caps;">{
                tei-to-html:recurse($node, $options)
            }</span>
        else 
            <span class="hi">{
                tei-to-html:recurse($node, $options) 
            }</span>
};

let $issue := request:get-parameter("issue", "")
let $section := request:get-parameter("section", "")
let $doc := doc(concat("/db/apps/punch/data/", $issue))
let $text := $doc/id($section)

Apps with HTML templating

Like most CMS products, eXist-db has a templating functionality, one that is powerful and completely transparent in view components, and that supports annotations. The eXist-db templating functionality uses standard HTML5 @data-* attributes, e.g. @data-template for the template and @data-template-* for optional parameters, and that functionality can be extended with user-specified namespaced templating functions, e.g.:

<div data-template="core:peanut-butter" data-template-coating="chocolate"/>

<div class="core:peanut-butter?coating=chocolate" />

Within templating, the current element is available via the %templates:wrap annotation, and nested template calls have access to application data through the $model variable. Manual processing control is achieved by calling templates:process.

The templating module can be referenced in the XQuery code:

import module namespace templates="http://exist-db.org/xquery/templates";

Of the built-in functions, templates:surround is probably the most powerful one. For example, it can be used with:

templates:surround?with=templates/page.html&at=produce

Thanks to the power of nested template calls, major benefits of the HTML templating approach in eXist-db are 1) a clean separation between HTML and the XQuery code that populates the HTML and 2) the ability produce both mock-ups and production view components with more advanced search forms and result pages without turning to other solutions. The separation of concerns means that, for example, people should be able to look at the HTML view of an application and modify its look and feel without knowing XQuery [HTML templating], addressing one of the limitations identified with the previous architecture.

HTML templating uses parameter injection to identify query parameters automatically, without requiring explicit calls to the request:get-parameter() function, and it also performs automatic type conversion. The logic underlying parameter injection means that the template processing makes best guesses about what the developer intends, which requires the developer to observe certain conventions. This has the virtue of reducing the behaviours that must be described through project-specific code, including annoyingly long and repetitive sequences of assignments from request:get-parameter() calls, but because some aspects of processing are no longer coded explicitly by the developer, it requires that the developer remember how eXist-db prioritizes the steps it takes to resolve a parameter reference. Developers who have tried to fix a misbehaved XSLT template or Schematron rule or CSS specification only to discover that a different rule that applies to the same context is at fault may appreciate that at least when you get a parameter value only by asking for it specifically with request:get-parameter(), you are less likely to become confused about where it comes from.

Beyond the inherent cost (and benefit) of ceding control to implicit behaviours, the principal cost of HTML templating is the possible need to translate idiosyncrasies of the templates as implemented inside eXist-db to a different template language. However, even in that case the initial domain knowledge and modeling remain intact and reusable.

TEI Publisher

TEI Publisher is packaged and distributed as an eXist-db web application that can be installed into any running eXist-db instance. It consists of two main parts. The first is a core library, which implements the TEI Processing Model (PM), introduced above and described in greater detail below. The second is a development environment to create customized standalone web applications with built-in facilities for navigation, pagination, search, facsimile display, faceted browsing, etc. Such applications, like TEI Publisher itself, can be distributed as xar archives and installed into any running eXist-db instance.^[12]

PM is a TEI-native vocabulary for expressing how XML documents should be transformed and rendered into various output formats (HTML, EPUB, PDF, etc.). It builds on the TEI ODD (one document does it all, ODD), a specification originally designed to integrate formalized documentation into customizations and modifications of the TEI. Because no document is likely to make use of the almost six hundred elements provided by the TEI, developers can use the ODD to constrain their project-specific schemas by including, excluding, modifying, or extending TEI components. The ODD can then export schemas in Relax NG, W3Schema, and DTD format, and because the ODD incorporates formalized, machine-actionable documentation, the developer can also generate reference documentation to be consulted during tagging. Although this is not always the way developers operate, the TEI intends that all TEI projects should be customized and documented with ODD.^[13] In its early days the TEI regarded the E part of its name as definitive: the TEI was about text encoding, and not about text processing. PM moves beyond that earlier perspective by incorporating processing information, in a formalized declarative and output-agnostic format, into the ODD alongside the information needed to create schemas and human-readable documentation.

PM lets users map TEI structures onto some two dozen fundamental abstract processing or rendering primitives called behaviours, which can be used to declare abstract rendering information like render <p> elements as blocks, render <hi> elements as inline, render <list> and <item> elements as components of list structures, etc.^[14] The PM thus provides formal, machine-actionable declarative processing instructions, expressed in TEI, that are independent of any specific output format or implementation language. The instructions were conceived with the twofold aim of being simple enough to be used by a human editor who is not an XML-technologies engineer, while also being sufficiently formalized to serve as operable instructions by a machine. Editors record their editorial intentions and expectations about the rendering (in a generic sense) of their elements by adding <model> child elements to the specification of an element in the ODD file, and the <model> elements use attributes to bind these processing expectations for an element (either globally or in a narrower XPath context) to a behaviour. For example, a user could specify how a <hi> element should be rendered along the lines of:

<elementSpec ident="hi" mode="change">
     <model predicate="@rend ='it'" behaviour="inline">
         <param name="content" value="."/>
         <outputRendition>font-style: italic;</outputRendition>
     </model>
</elementSpec>

Three kinds of high level decisions are incorporated into the <model>. The first is the content, expressed through a content parameter, which uses XPath expressions to specify the content to be rendered. The other two pertain to how the content is rendered, one aspect of which is structural (expressed through @behaviour values like block or inline) and the other of which involves appearance values for the <outputRendition> child element, which might specify italics or small caps. As a more complex example, to render related regularization (TEI <reg>) and original (TEI <orig>) values inside a TEI <choice> wrapper, the developer can specify the @behaviour value as alternate. With HTML output, this might put the content of the regularization in the base text and the original source text in a tooltip displayed on mouseover, or vice versa, but because the PM specification is high-level, abstract, and declarative, it can also be used during print output to write one value into the running text and the other after it inside parentheses. The PM specification for these two combines types of behaviour might look like:

<elementSpec ident="choice" mode="change">
    <model output="web" predicate="orig and reg" behaviour="alternate">
        <param name="default" value="reg[1]"/>
        <param name="alternate" value="orig[1]"/>
    </model>
    <modelSequence output="print" predicate="orig and reg">
        <model behaviour="inline">
            <param name="content" value="reg"/>
        </model>
        <model behaviour="inline">
            <param name="content" value="orig"/>
            <outputRendition scope="before">content:" (";</outputRendition>
            <outputRendition scope="after">content:") ";</outputRendition>
        </model>
    </modelSequence>
</elementSpec>
<elementSpec ident="reg" mode="change">
    <model behaviour="inline"/>
</elementSpec>
<elementSpec ident="orig" mode="change">
    <model behaviour="inline"/>
</elementSpec>

The value of @behaviour can be set to omit if the matched element is not to be included in the output. For example, TEI page beginning (<pb>) elements can be omitted during rendering with:

<elementSpec mode="change" ident="pb">
  <model behaviour="omit"/>
</elementSpec>

PM was developed initially in connection with the definition of the TEI Simple schema, a schema offering explicit and standardized options for displaying and querying texts that a developer could make use of to build transformations for a given output format (e.g., web, print, epub, etc.).^[15] TEI Publisher implements PM with a library of built-in behaviours defined as XQuery functions for each output format. This implementation strategy offers sane default mapping from PM’s CSS-based style language to the various output formats. It also supports overriding these defaults with custom, output format-specific affordances, such as LaTeX boilerplate or XSL-FO font definitions, and it exposes extension hooks for XQuery functions for cases where the default PM defined in the TEI Simple schema alone cannot accomplish the desired results. For example, if we look through the lens of TEI Publisher at the tei-to-html:hi() XQuery function in the Punch tutorial described above, we see that it requires mapping a <hi> element with a @rend attribute set to it (<hi[@rend='it']>) in a way that is not served in the list of common behaviours defined by the TEI Guidelines and used mainly in the TEI Simple schema that serves as a default PM specification for TEI Publisher. Earlier versions of TEI Publisher provided a way to extend the behaviours defined in the TEI Guidelines by writing additional XQuery functions. For example, if this new behaviour was to be called emphasis, it could be written as:

declare function pmf:emphasis($config as map(*), $node as node(),
                    $class as xs:string+, $content) {
    <em>{pmf:apply-children($config, $node, $content)}</em>
};

<elementSpec ident="hi" mode="change">
    <model predicate="@rend ='it'" behaviour="emphasis">
        <param name="content" value="."/>                       
    </model>
</elementSpec>

The library part of TEI Publisher (tei-publisher-lib) release 2.5.0 introduced support for templates and user-defined behaviours within the ODD that lets the user write the same new behaviour directly in the ODD. For example, this emphasis behaviour could (= should) now be written as:

<pb:behaviour ident="emphasis">
    <desc xml:lang="en">custom emphasis</desc>
    <pb:template>
        <em xmlns="">[[content]]</em>
    </pb:template>
</pb:behaviour>

TEI Publisher even leverages PM’s potential to support documents encoded in non-TEI vocabularies, which it illustrates by shipping with support for DocBook-encoded documents. The most recent major release, 4.0, was redesigned to use Web Components in its views, allowing users to freely add, remove, and combine panels containing different views, such as facsimile, translations, and maps.^[16]

Web Components are an upcoming W3C standard (or meta-specification) that provides web developers with a means to create reusable UI building blocks that encapsulates all the HTML-, CSS-, and JavaScript-based logic required for rendering. The large number of Web Components already available makes most adaptations possible with just some foundational knowledge of HTML, but users with advanced requirements can implement additional components on the basis of modeling experience and knowledge of the HTML5 specification, and specifically of defining new Web Components. As TEI Publisher 4.0 includes a collection of Web Components targeted at creating digital editions, users are likely to find that without customization it already provides ways to embed texts into an application context, supporting the integration of navigation, pagination, search, facsimile display, and more.

The principal advantage of TEI Publisher, emphasized in the documentation, is that by relying on reusable high-level, generic behaviours, it can substantially reduce the amount of code needed to create transformation, a benefit that inheres both in code creation and in code maintenance. For example, Turska and Cummings write that:

The principal costs of TEI Publisher, as with other web publishing frameworks, are twofold. The first cost lies in the start-up, that is, in the time and resource requirements to perform a technology switch. While TEI Publisher builds on ODD and XQuery, which users may have encountered in other contexts, they are unlikely to have learned and worked with PM previously. The second cost, also shared with any web publishing framework, involves the potential for lock-in, since building a site within a particular framework implicitly discourages migration to a different framework at a later date. TEI Publisher cannot eliminate these costs, but it mitigates both by using Free Software and open formats, and by following both actual (such as HTML5) and de facto (such as TEI) standards, it reduces both the start-up cost and the cost of potential future migration.

With regard to the question of potential future migration, it is illuminating to reverse the perspective and see it throught the implementation of the TEI Processing Model as documentation driven. If one accepts the possibility that in the long term HTML and Web Components might become outdated and replaced by other technologies, the technology-agnostic aspect of the formal documentation within PM will nonetheless continue to provide consistent and sufficient information about the logic of the intended processing and rendering of the elements. Eventual transformation to new output code may be inevitable, but the output-independent aspects of PM can at least shorten the portion of the pipeline that will need to be rewritten. It is also likely that instead of migration from a translation of Web Components into a new technology it will prove more efficient to start anew at the source of the intention, that is, the formal TEI expression of user output expectations or instructions. From that perspective, within PM the publication framework is documentation driven. By this we mean that because PM forces the user to define these instructions in a declarative manner, it can be said that it enforces format- and software-agnostic documentation, which may provide the best guarantee we can have for a long term transmission if not of the result, at least of the scholarly editorial intention.

The TEI Publisher implementation of PM acts, then, in a controller context, establishing an efficient binding from model to view that is also largely independent of the latter. Using the technology of Web Components, the views may be seen as modeling streams of documents as autonomous APIs, which can be fitted together like assemblable modular blocks, and which will constitute a collection of standardized base units that are highly reusable. To illustrate this design orientation towards web standards and the reusability principle, the blog post written by TEI Publisher's principal developer, Wolfgang Maier, employs the metaphor of Lego blocks:

The TEI Publisher documentation states that: You do not need to know much about Web Components to use them in TEI Publisher. In fact, users need to understand only how the web components they want to use can be connected to the corresponding PM specification in an associated ODD, a connection that is implemented by setting the Components properties via attributes. As the Web Components shipped in the TEI Publisher are presented in the form of API documentation, users will be able to understand which attributes they will need to use. When setting themselves the task of designing a new template page for an edition, they will then have to specify the interface Components they wish to use either from among the TEI Publisher built-in Web Components or from external libraries, such as Polyfills. But insofar as the user will have mastered the data model of the corpus of XML encoded files—the model—they will be able to establish that connection successfully and in a way that is appropriate for their editorial purposes. Doing that within the framework of TEI Publisher, they will then produce new template designs—or views—that could potentially be shared by pushing them to the Open Source code repository of TEI Publisher.

To be sure, what is at stake here is not only, or even primarily, the technical reusability of the UI web blocks; it is also the underlying theoretical approach supporting the design of the interface template. For that reason, the theoretical potential of TEI Publisher will be for fully attained when collections of built-in Web Components will be grounded in a robust editorial theory or a series of editorial theories, each potentially populated by a subcollection of Web Components, all supported by communities of users commited to sharing them through an Open Source digital ecosystem. Insofar as the design of the view is a legitimate part of the scholarship, it, too, requires an open infrastructure for peer review and reuse. In this way it could be possible that the Lego blocks interface design approach implemented by TEI Publisher could play a major role in simplifying the design tasks of the digital scholarly editor, thus realizing not only a toolbox to build interfaces, but also a toolbox to elaborate proposals of scholarly editorial models that are theoretically and editorially based, offering a stable infrastructure for digital editions and allowing a community of academic users to reflect on the features that the scholarly community will consider essential to a particular type of text or scholarly problem and to agree on some essential models which take into account the new affordances offered by the digital.. [Pierazzo 2019] In other word, the architecture underlying TEI Publisher may be regarded not only a new flavor accidentally brought to the market, but as a laboratory of taste, helping users to collectively invent, experiment, compare, and refine the new flavors and meals adapted to their lifestyles and aspirations.

The interface and the scholarship

Two presentations at the 2016 University of Graz DiXiT conference Digital scholarly editions as interfaces offered compelling arguments for regarding the vehicle for presenting edition data, that is, the interface, as a scholarly product. This means that researchers who develop digital editions not only have a legitimate interest in the interface, but may also regard themselves as under a scholarly obligation to consider its meaning, because with or without their active intellectual engagement, the way a digital edition communicates with its readers is part of how it expresses and argues for a theory of the text. And this, in turn, means, among other things, that the way TEI XML is rendered in an edition is not a neutral presentation of a scholarly argument that inheres entirely in the TEI XML markup, but an inalienable part of that argument. Tara Andrews and Joris van Zundert write that:

Wout Dillen advocates for a similar perspective:

To the extent that the presentation of the edition data, then, is a scholarly product, it is the proper business of scholars.^[19] The TEI XML alone is not the full or only scholarly product, and neither is its transformation with a generic presentation script, such as those provided by uncustomized use of TEI Boilerplate or the TEI Stylesheets. [TEI Boilerplate, TEI Stylesheets] If it is to fulfill its scholarly potential, then, a digital edition publishing framework, such as the four explored in this study, should be 1) maximally configurable and 2) usable by digitally capable and digitally willing textual scholars. Each of the four frameworks is fully configurable, although they differ in their ease of use, perhaps in general, and certainly according to an individual researcher’s technical expertise. Those differences are explored below.

In his 2019 consideration of, among other things, the extent to which the data and the presentation contribute to constituting the digital edition, James Cummings acknowledges the fundamental role of the data; the analytical, interpretive, and communicative scholarly importance of the interface; and the unique value of API-mediated access in supporting reuse, that is, scholarship that the original editor may not have envisioned. About the centrality of the data Cummings writes that The encoded data is a good representation of the scholarly edition and one I care about deeply. That is, the data are essential. This echoes Dillen’s Without […] data, there are no editions–be they digital or in print. The same cannot be said about interfaces. [Dillen 2018 36] Turning to interface, Cummings then adds that [i]f part of the point of editing a work is to make it more accessible, in all senses of that word, then usually some presentation view of the edition is required. That is, the presentation is a way of facilitating scholarship by communicating scholarly interpretation. In part this echoes Andrews and van Zundert, cited above: The interface is thus an integral part of the argument that an edition makes about a text. Dillen writes, similarly: […] it is exactly by reconfiguring our materials in new ways, by constructing an interface around those materials, by interacting with other people, and by seeing how the interface shapes their interpretation of the data, that we keep developing our own interpretations of those materials. [Dillen 2018 36]

Cummings, however, concentrates on the communicative potential of the interface in a way that seems to downplay what Andrews, van Zundert, and Dillen see as its added value as scholarly analysis and interpretation, and not merely the communication of scholarly analysis and interpretation that happens elsewhere. We thus disagree with the implicitly invidious rhetorical use of merely in Cummings’s the presentation layer is merely one or more additional views on the data. But insofar as a view on the data is analytical and interpretive, and therefore informational, Cummings’s position may be understood as valorizing the scholarly value of the presentation while emphasizing that no interpretation should be regarded as exhaustive or definitive, and that edition data can and should be made reusable for alternative analyses and interpretations.

Cummings advocates for the importance of this reuse when he writes that a truly conceptual editorial object is malleable and recombinable, and an encoded edition, by itself, is not […] the true form of a scholarly digital edition would be better expressed as a well-documented API for the manipulation and description of editorial objects following an open international standard for the representation of digital text. We disagree with the rhetorical use of the true form, where the definite article invidiously implies that there is only one, and true invidiously implies that others are false. But insofar as presentations may be limited by what the editor has anticipated, envisioned, recognized, understood, and facilitated, we agree completely that TEI XML plus specific presentational decisions do not exhaust the potential information value of an edition.

Cummings focuses on the primacy—at least in some cases—of reuse of the editorial objects underlying an edition by others when he writes the following:

General

Each of the four architectures outlined above is capable of generating a digital edition from TEI XML source using eXist-db, and the differences among them may be understood as including, among other things, the extent to which they rely on eXist-db-specific functionality. Increasing reliance on eXist-db for executing the transformation from model to view typically conveys an increasing advantage of lessening the extent to which the developer is required to write and maintain bespoke code for the edition, since the developer instead takes advantage, to varying extents, of what eXist-db (or eXist-db enhanced with PM support) already knows how to do. But with this reliance comes a greater dependence on functionality implemented in a specific way in (or perhaps available only within) eXist-db. That eXist-db HTML templating and TEI Publisher are implemented entirely with standardized technologies like XQuery and Web Components mitigates the lock-in effect because it means that the implementations could be ported to a different DBMS/CMS environment. But that transparency may be of limited immediate value to a user who is comfortable at the application level with XQuery, but not at the higher level required for migrating from the eXist-db infrastructure to that of BaseX or MarkLogic. On the other hand, the extent to which a commitment to one of the four methods described above entails a commitment to a specific platform, such as eXist-db, may be less important when we consider the lock-in aspects of the eXist-db URL rewriting facility, its Lucene-based full text index and query functions, and its newest feature in the forthcoming eXist-db 5, faceted browsing (which also uses Lucene). A project concerned about lock-in might be advised to worry more about those layers than about HTML templating or TEI Publisher per se.

TEI Publisher, by any fair measure, exemplifies an integrated and well-developed, whole-cloth conception of a starter system for publishing editions. The philosophy underlying TEI Publisher prioritizes exposing more control over the output specification while requiring less programming expertise. With that said, each project needs to evaluate which model serves it best, assessing the importance of each of the following considerations in the context of the project:

Different projects might reasonably make different choices from this menu.

Sustainability

All methods described above except the middleware one can use eXist-db’s xar packaging for one-step replication, distribution, and deployment. In contrast, porting a middleware implementation means configuring PHP and eXist-db to communicate, which is much more complicated to set up, to troubleshoot, and to maintain. A researcher end-user can more easily install eXist-db on a laptop and deploy an edition as a drop-in xar file than install eXist-db, load data and XQuery into it, and also install and configure Apache, install and configure PHP scripts, and ensure that the pieces all communicate effectively.

Ease of use

Cummings argues that as much as possible editors of scholarly digital editions should not be distracted from editorial tasks by technological concerns if these technological concerns do not affect their edition. [Cummings 2019, emphasis added] This idea, and the way it is worded, strikes a wise middle ground between two extremes. One extreme is the largely unrealistic requirement, implicit in the complexity of some infrastructure and application architectures, that the scholar will have highly developed programming skills. This is true of some digital scholarly editors, but not of all. The other extreme is the naive assumption, implicit in tools that wholly isolate the researcher from the methods implemented in the software, that if the researcher focuses on the content, the technology can be left in the hands of programmers. Among other things, software may embed scholarly assumptions that researchers need to understand if they are to accept responsibility for adopting the decisions the software makes on their behalf.^[20] Ease of use may thus be understood as not requiring unnecessary technological expertise from the researcher, while also recognizing that some technological concerns affect the edition, and thus must be made accessible to the researcher.

Ease of use may be measured in different ways. On the one hand, the four methods described above, in order from first to last, increasingly simplify configuration and customization within anticipated, supported parameters, requiring less—and often much less—custom code than a traditional LAMP architecture. On the other hand, in distributing responsibilities these more CMS-like methods may require increasingly greater coordination across parts of the CMS. For example, all of the code for the middleware approach, as the developer sees it, it located in just two places: the scripting language (such as PHP), which processes user input and creates output views, and the XQuery inside eXist-db, which retrieves information from the model. At the other extreme, TEI Publisher information may be distributed over multiple files in multiple libraries, and while in many cases the user may not have to interact explicitly with most of them, customization (such as the incorporation of a new behaviour written in XQuery) requires the ability to navigate a more complex resource structure. It may be helpful in this context to think of different roles in the development process. From this perspective, the greater complexity of the TEI Publisher model may fall only to a professional developer, who can reasonably be expected to have or to acquire the necessary skill. Meanwhile, the scholar-editor may need only to choose among supported behaviours and CSS-like rendering instructions, which is a low requirement for technical expertise. In comparison, the middleware organization, while architecturally simpler overall than TEI Publisher, requires much more advanced programming skills from the user because it does not aim to distinguish clearly a scholar-editor role and a developer role.

So what about those peanut butter cups?

If we return to our analogy of eXist-db’s XML DBMS services as the peanut butter core of a Reese’s Peanut Butter Cup and other eXist-db services (not only Jetty HTTPS services, but now also app processing, HTML templating, and PM) as the chocolate around that core, we might say that the researcher has a choice. With any of the frameworks described above the developer has control over the selection, arrangement, and presentation of the information. But to what extent do you want to combine your own peanut butter with your own chocolate and to what extent do you feel that the combination offered by Reese’s is superior to what you might produce yourself?