Balisage Paper: Scholia 2026: DIY study aids with TEI, XProc, browser and printer

Hitting the wall in 2002

In 2002, at a memorable ACH/ALLC 2002 conference in Tübingen, Germany, I presented a poster on a project I named Scholia.^[2] That summer I was lucky to be in Germany for several reasons; as far as the demonstration was concerned, its purpose was to find for myself, and show to colleagues in the Digital Humanities community (still known at the time as Humanities Computing), some of the potentials and practical limits of technologies that were then in their infancy or early childhood, namely TEI XML^[3] for data description, the web browser for display (hence, HTML), and XSLT 1.0.

Figure 2: ACH/ALLC 2002 conference poster

The images in the poster were created with SVG, semi-automated where possible. One of them is given for illustration.

How far could I go? What practical limitations could I find for a solo operator (myself) to acquire a text, mark it up using TEI (slightly extended), and display it in a useful way that specifically explored, and exploited, the affordances of the electronic interface, specifically the screen coupled with pointer and mouse, running a commodity web browser? Within this reduced environment, basic primitives of typography and color (offered by HTML and CSS) were enhanced with a small amount of scripting logic (Javascript manipulating the DOM), in order to realize, using the smallest possible technical pallet, the greatest possible useful effect. Greatest possible in this case keeps in mind that the basic architecture – XML source data, XSLT transformation for logical and presentational projection, and HTML/CSS/JS at the display layer – provides leverage in its layering. In this case, elements kept as siblings in the source code could be placed far apart in the display, while retaining (and enacting) their relations in their scripted behavior. More simply put: the data in source and result were organized differently, but a single transformation could provide for all the necessary sorting and sifting, linking and tracking.

The application itself (as should be readily apparent on inspection) is a variant of what educators and publishers call a graded reader or assisted reader, that is to say (and as described above), a text that is provided with apparatus and commentary designed to help the language learner, or anyone who finds such an apparatus more helpful than not.^[4]

So far this is a description of something that seems unremarkable, when viewed in 2026 (now it has been done many times over), but keep in mind this was 2002, when almost all web pages were either crafted by hand, or scripted database reports.

And the demonstration holds up relatively well - it can still be seen today at https:://pellucidlliterature.org.

Figure 3: Die Amsel demonstration 2002

One screenshot shows the text (with a couple of bespoke element types) being edited using XMetaL Editor in 2002, supporting standard XML tagging validated with a TEI DTD. Another shows the presentation view in 2002 using a browser current at the time, Internet Explorer. (Compatibility across browsers was also a requirement met by the demonstration); while the last image shows the same view of the document in July 2026, using today's browser. See the demonstration on line at https://pellucidliterature.org/

What it really taught me, however, was how far we still had to go. Having built the technology prototype and worked up a plausible example to demonstrate the principles, I then set the project aside. The main reason was that however successful it was on its own terms, there were a number of key features missing in the design, which I was not (or not then) in a position to implement. And these were features more or less impossible to address using only the web and XML technologies of that time:

In other words – and in 2002 this was already clearly apparent, even obvious, as we had already written papers on the topic – I had an overlap problem.

What a difference a decade makes

In 2025 I was looking at an altogether changed set of circumstances. By then, my effort of 2002 with XSLT 1.0 had been far outstripped by electronic tools, systems and services, both on line and off, that serve language and literature students. To be sure, comparisons are at risk of forgetting that the Amsel project was the initiative of one solo developer working in spare time on a deadline, for experimental purposes, deliberately using only commodity, standards-based technologies. Nonetheless it needs to be acknowledged that the 2002 demonstration today appears rather quaint, if not crude, in both design and realization, and not only due to its amateur typography (hitting the limits of the CSS of the day). At the same time this crudeness is possibly a reflection of its strength, as well, namely its relative simplicity even while, to be anything at all, it relies on a complex assemblage of inventions of others: TEI, HTML, XSLT etc., to say nothing of the computer and the network itself.

Since that time, however, for practical purposes the overlap problem as we fondly called it, gradually disappeared – or more accurately, the pains related to it subsided as we benefited from better tools and techniques in the XML technology stack. Just the most important:

During this same period, along with much else, I continued to work intently, if sporadically, on developing a more comprehensive approach to the overlap problem that would be simple enough (or so it was hoped) to support new forms of complexity. With Jeni Tennison, starting at Extreme Markup Technologies 2001 (the predecessor conference to Balisage, the Markup Conference), I developed a proposal we called LMNL, the Layered Markup and Annotation Language. In subsequent years Jeni, myself, and a gratifying number of other developers had opportunities to show meaningful outcomes, based on both our ideas and on proposed alternatives. Implementations and later demonstrations (such as Frankenstein Trans formed) were received and generously entertained at this conference and elsewhere, even while the larger conversations increasingly, and inevitably, moved on.^[5]

As the headaches were alleviated and the problems gave way, it made sense for the community's attention to shift. To my mind then and now, the test always had to be the actual needs of actual users, presented to developers as functional requirements. To the extent that there were needs unmet, we could tell, if we kept listening for the stories not being told. In other words, which research agendas were we not exploring, because we have no good way to deal with what we see (whether overlap or anything else)? While I welcomed and used all the new tools and solutions, I was always interested to see where and when things did not improve, and in the background I remained mindful of applications that continued to resist automation – like drawing diagrams of structures implicit in literary works such as sonnets, where overlap is interesting.

Thus the technologies improved at the same time as my early efforts were being overtaken and outflanked. What came as a surprise to me in 2025 was that this did not, in fact, make the unfinished Amsel demonstration less interesting: on the contrary, relieved of any need to be what it was not, this demonstration was showing me what it really was – not necessarily or not only a graded or assisted reader – an electronic version of the kind of helper text I had used in school – but a kind of digital learning platform of its own distinctive type, in a nascent or inchoate form.

Figure 4: Chicago Homer (published 2000)

Digital classicists have been not less innovative than their analog professors, in developing better ways to present to scholars and students what we need to know, when we need to know it. The screenshot shows the Chicago Homer, a Java application built in 2000 by Craig Berry, Bill Parod (technical editors), Ahuvia Kahane and Martin Mueller (editors).

Scholia 2026

This did not happen all at once. In 2026 I was turning my attention, after a long hiatus, back to studying Ancient Greek, and specifically (this time) to the works of Lucian of Samosata, a satirist of the 2nd Century CE who wrote in Athens. After browsing fairly widely I settled on his Life of Demonax for close scrutiny.

If I had found a graded reader or school edition already published for this text, I would have acquired it.^[6] As it was, I did have access to more than one excellent electronic reading interface, with helper apparatus (some listed in the bibliography). Despite their own (typically) experimental status, these were all better than anything I could build myself: they were already baked and available, and I availed myself accordingly (like the philosopher Demonax, plied with honeycakes by the women of Athens). Yet paradoxically, these estimable tools also fell short, as I discovered by contrast how effective it was not only to use such a reader, but to build one.

And I was now in the fortunate place where I did not have to show anything or convince myself or anyone that it was possible: I had only to start working at it.

Using Demonax as my example, the results can now be seen on a demonstration web site, Raven Tracks (https://raventracks.org). As I was completing it, the project grew: in addition to the reader a PDF version of the translation in English is offered (for the reader who wants no Greek), produced again from XProc (using XSL-FO this time).

In building this, the work we had done with the LMNL model proved to be crucial, since among other features of Scholia 2026 is its support for the third level of annotation it needed (as described above). Additionally to the editorial layers provided in Scholia 2002 (given to word- and phrase-level translations), arbitrary ranges or spans of text can now be annotated, and these annotations too (called gloss in the Scholia model) can be managed and maintained with the rest. Thick markup.

At the same time the basic Scholia architecture remains what it was: XML (TEI) source data (model), HTML/JS/CSS (view) and XML-based processing (controller) - now no longer a single XSLT transformation, but an XProc pipeline as long and complex as necessary to do the job. The job itself is more complex, but this complexity is effectively screened from the user.

Figure 5: Scholia 2026 - Life of Demonax

Depicted here are the editorial platform for Scholia 2026 (no longer XMetaL, but oXygen XML Editor) and the same passage in the rendered view. The model still aims for simplicity and usability, but a third layer is added. Readers are invited to refer to a live copy at https://raventracks.org/Demonax/Demonax_scholia-EDITIO.html, since a screenshot does no justice to the interactivity of the interface.

Scriptorium Technique

As it happens, this is a serious approach to language learning developed and recommended by professional polyglots: the Scriptorium Technique. Of course, the method of learning by transcription is as old as writing, but this modern formalization of the approach is noteworthy for a number of reasons.^[7] First, it is approachable, even for challenging languages – easy to start, easy to continue. It can be practiced solo – this is important. Since it focuses on writing, it is especially good for literary languages, literature and poetry. It works by creating opportunities for the fun part (which indeed may prove to be different for different learners), which in turn creates opportunities for the learning feedback loop.

My efforts to support the Scriptorium technique by means of a web-based apparatus, specifically as applied to Homer's Iliad, can also be seen on the Raventracks web site, https://raventracks.org. They take several different forms. What they have in common is that they are focused on enabling transcription. But transcription in this context implies something more than a simple copy. It is possible to make a copy, even by hand, without transcribing. A copy qualifies as a transcription only if as one copies, one is conscious and intentional with respect to the meaning of the writing. Simply: Are you able to mean it? which generally entails knowing – actively – what it means. Without transcription, copying can still be an art, and a beautiful one – whose form transcription takes. Beyond making the copy, according the Scriptorium method, a passage is considered complete when the student can write it and pronounce it, aloud, with comprehension. Not recite it (or not only), but speak it, first with the hand, then with the voice, engaging the entire attention. At the same time, every student gets to decide what this means and what degree of comprehension and fidelity is required to meet the other important (in some ways overriding) goal^[8]: to write another passage the next day. Accordingly the system is adaptable to both the limiting factors, and the goals.

Figure 6: Raventracks pages for Scriptorium (Homer's Iliad)

Two pages on the Raventracks web site show two different aids to practicing reading and transcribing Homer's Iliad. On the first page, an excerpt is shown with an English translation (in the public domain) aligned. The page can be printed to serve as a blank for the student to annotate and transcribe. (In my practice I annotate on the page and then make a fair copy onto another.) The excerpts for printing – excerpta scribenda or squibs – vary in length following the translator's editorial decisions (in producing paragraphs). Along with each squib is a corresponding crib which presents a running vocabulary, that is a page of vocabulary and grammar notes that can be consulted and quizzed. Squibs and cribs are available covering all 24 books of the epic (1137 squibs in all, averaging between 10 and 15 lines each).

These are two of a growing number of learning aids I am making – for the Iliad, enabled by the combination of publicly-available texts (in many cases funded by NEH or other US Government entities) with open-source power tools such as XSLT and XProc. Readers are invited to look at the site for more – at time of writing, an easy reader is under development that combines lightweight glossing (morphology and short definitions acquired from the sources) with concordancing of verbs, nouns and adjectives.

Figure 7: Scriptorium workflow

The author's Scriptorium workflow starts with printing the squib (each day brings a new one) and marking up the passage under study with a pencil. The markup activity is supported with the crib for the passage (for easy vocabulary lookup) along with any and all reference materials and commentaries I have to hand. Once I feel I comprehend the passage sufficiently well, I write it out on a yellow pad, trying to be legible enough to read it back again.

Exploratory markup - towards an illuminated Iliad

This much can be done with XML, TEI, XSLT and XProc. Add iXML and we can also include LMNL (or to be more precise, the MNML LMNL subset variant, defined for the Laminator).^[9] At least in this, LMNL already works; it is not tomorrow's technology. A LMNL Iliad is an easy and obvious next step to take. See some examples here: https://github.com/wendellpiez/EpicMarkup/tree/main/data/Iliad/lmnl

[div [type}book{][n}1{]}
[para}[prayer [by}{][to}Muse{]}
[l [n}1{]}μῆνιν ἄειδε θεὰ Πηληϊάδεω Ἀχιλῆος{l]
[l [n}2{]}οὐλομένην, ἣ μυρίʼ Ἀχαιοῖς ἄλγεʼ ἔθηκε,{l]
[l [n}3{]}πολλὰς δʼ ἰφθίμους ψυχὰς Ἄϊδι προΐαψεν{l]
[l [n}4{]}ἡρώων, αὐτοὺς δὲ ἑλώρια τεῦχε κύνεσσιν{l]
[l [n}5{]}οἰωνοῖσί τε πᾶσι, Διὸς δʼ ἐτελείετο βουλή,{l]
[l [n}6{]}ἐξ οὗ δὴ τὰ πρῶτα διαστήτην ἐρίσαντε{l]
[l [n}7{]}Ἀτρεΐδης τε ἄναξ ἀνδρῶν καὶ δῖος Ἀχιλλεύς.{l]{prayer]{para]
[para}
[l [n}8{]}τίς τʼ ἄρ σφωε θεῶν ἔριδι ξυνέηκε μάχεσθαι;{l]
[l [n}9{]}Λητοῦς καὶ Διὸς υἱός· ὃ γὰρ βασιλῆϊ χολωθεὶς{l]
[l [n}10{]}νοῦσον ἀνὰ στρατὸν ὄρσε κακήν, ὀλέκοντο δὲ λαοί,{l]
[l [n}11{]}οὕνεκα τὸν Χρύσην ἠτίμασεν ἀρητῆρα{l]
[l [n}12{]}Ἀτρεΐδης· [scene [set}Achaian ships{]}ὃ γὰρ ἦλθε θοὰς ἐπὶ νῆας Ἀχαιῶν{l]
[l [n}13{]}λυσόμενός τε θύγατρα φέρων τʼ ἀπερείσιʼ ἄποινα,{l]
[l [n}14{]}στέμματʼ ἔχων ἐν χερσὶν ἑκηβόλου Ἀπόλλωνος{l]
[l [n}15{]}χρυσέῳ ἀνὰ σκήπτρῳ, καὶ λίσσετο πάντας Ἀχαιούς,{l]
[l [n}16{]}Ἀτρεΐδα δὲ μάλιστα δύω, κοσμήτορε λαῶν·{l]
[speech [by}Chryses{][to}Agamemnon, Menelaus, Achaians{]}
[l [n}17{]}Ἀτρεΐδαι τε καὶ ἄλλοι ἐϋκνήμιδες Ἀχαιοί,{l]
[l [n}18{]}ὑμῖν μὲν θεοὶ δοῖεν Ὀλύμπια δώματʼ ἔχοντες{l]
[l [n}19{]}ἐκπέρσαι Πριάμοιο πόλιν, εὖ δʼ οἴκαδʼ ἱκέσθαι·{l]
[l [n}20{]}παῖδα δʼ ἐμοὶ λύσαιτε φίλην, τὰ δʼ ἄποινα δέχεσθαι,{l]
[l [n}21{]}ἁζόμενοι Διὸς υἱὸν ἑκηβόλον Ἀπόλλωνα.{l]{speech]
{para] ...

It might be argued that we hardly need such a rewrite today; and in any case, producing LMNL from XML can be done with a simple syntactic mapping. But overlap has always confronted us with a paradox: because it is tricky to deal with in XML, we have learned tricky ways of dealing with it. Does this make it any less tricky? LMNL might be said to isolate and hide the tricky part, making it simple and more straightforward as syntax, allowing operations (such as building a tree) to happen down the line and out of sight. Parsing and handling a bespoke format such as LMNL can be challenging, but tools available today including the Laminator (with its iXML component) do more than show it can be feasible: once the data can be parsed into a structured representation, we are off and running.^[10] There is less urgency to the project, but the limits have not really been found either. Thus it remains enticing.

In particular, since LMNL works without a schema and the model (and syntax) permits tagged ranges to overlap, it is an especially good tool for adding meaningful markup to a text even before that markup is regimented and regulated.

Even prior to LMNL, this has been part of the project. In a paper I gave many years ago at Extreme Markup Languages I called this approach to markup exploratory markup.^[11] Unlike its forerunner technology SGML, XML provided for documents that could be parsed without a schema defined ahead of time – simply following the rules of its syntax and the important end-tag matching rule. Effectively, this meant that XML could be used without a schema – arguably an essential feature of the language, whether the schema done without was simply unavailable, or had never been written. LMNL was designed to be similar to XML in this way, only more so, as we had even relaxed the end-tag matching rule (a match must occur, but any range can be closed by and end tag, not only the most recently opened), so overlap – whether accidental and temporary, or logical and necessary – does not inhibit modeling, instead becoming a feature.

Exploratory markup frames the task as an improvisation, not an enforcement action. Instead of following rules for what to tag, we can tag anything or everything. We aim for consistency, but seek for a consistency that reflects and expresses the phenomena at hand, not a paradigm imposed from outside. When we do this comprehensively, the schema that emerges describes the text itself, without reference to abstracted sets of rules. The relation of this implicit and emergent schema to related schemas, including paradigmatic ones, would be a topic of research.

Back to editing markup in a text editor, the idea that the LMNL model (and syntax) could be enabling in a very practical hands-on way, was hard to shake. Even in contrast to now-familiar XML workarounds (and even in combination with them) this would be instructive, and in the best way. It would teach us not only about XML, but about markup and about our texts.

Since we have good TEI data, making a LMNL Iliad is fairly trivial, and even in a different syntax this will still be TEI in essence, at least arguably or in some sense. And once it is tagged with the barest LMNL markup, the imperative becomes clear: use LMNL to mark up the Iliad, overlap and all.

And there is overlap. In addition to its lines and reference structures, the Iliad has grammar, rhetoric (extended similes) and narrative structures, at least. These many questions - the application of markup to narrative and rhetorical structures, irrespective of the requirements of hierarchies – belong on yet another Github repository: https://github.com/wendellpiez/EpicMarkup. Here the goals, although open-ended, include a number of interrelated objectives:

Winged words

What are the lessons? At least –

Figure 9: Range maps of Homer's Iliad

A range map depicts the extent of ranges (character subsequences) within a LMNL document such those under development in the EpicMarkup repository. These images show the first two books of the Iliad, out of 24 total. The shapes indicate the location and extent of scenes, speeches and rhetorical tropes within the text, as well as its normal division into paragraphs (which are editorial, in this case) and lines. As the original (not this copy) is encoded in SVG (Scalable Vector Graphics), the text can be magnified (or reduced) to see component structures at any level. See the repository at https://github.com/wendellpiez/EpicMarkup/ for more information.