Balisage Paper: Constructive Inconsistency

Validation

When we are using that infrastructure to develop applications, we often seek even more homogeneity. We write applications for single vocabularies or small sets of related vocabularies, and we notice that if the inputs are valid, we don’t need to program so defensively, which makes things faster and simpler. Validation is important because it allows us to work reliably with much larger collections of material than we would otherwise be able to manage. And when the collections get big enough, you will need queries and reports, just to keep track of your validation results. When that happens, you will want a system to collect and publish validation results like the Mirabel system described yesterday by Eliot Kimber [Kimber 2022].

Eliot’s talk also illustrated one of the main arguments Meyer uses to say that we should care about compatibility, which I remind you is the ease of combining software elements with others. Because once they exist, successful programs grow to provide more function. If the program does one thing well with one kind of data, then we will have an opportunity to make it do something else with that data, or make it do that same thing with a broader range of data. And users will want us to seize that opportunity. If you’re publishing validation results, then surely it’s an easy step to publish a progress dashboard as well. If you’re publishing validation data and a dashboard in a way that makes them easy to monitor, why not do the same for other analytic information? And from there, it snowballs.

In contexts like these, consistency seems very much worth striving for. Because it pays off. It simplifies our system building. And it’s often achievable.

Non-XML Data

For many of us, one of the more painful inconsistencies we face in our professional lives is the failure of the world at large to use XML whenever we think it is appropriate. As Tommie Usdin observed on Monday, some of us incline towards the belief that the phrase when XML is appropriate for the representation of information is synonymous with the phrase when information is being represented. Tommie is clear that she doesn’t think those two phrases are really equivalent, and at some purely intellectual level I agree with her. I’m all for self-determination and letting a hundred flowers bloom and people deciding for themselves what’s best for their situation.

But in my heart, I know that if only they knew what was good for them, they would surely choose XML. Primarily, it’s the rest of the world that doesn’t always choose to use XML when I wish they would, but even some of us in this virtual room occasionally flirt with non-XML formats. I name no names. You know who you are.

Given my inclination to believe otherwise, it can be painful for me to concede that by some quantifiable measures, XML may not always be the right choice. It can be less readable, for example, than a non-XML representation of the same information, as Michael Gryk showed us on Wednesday [Gryk 2022]. We can quibble, if we want, over the correct approach to quantifying something as tricky as readability, but that’s just another illustration of the fact that it’s possible for reasonable people to disagree — to be inconsistent with each other — about important and interesting questions.

Given, as a brute fact, that not everyone uses XML, those of us who do use XML a lot, who build systems that are XML-centric, will find it helpful to have ways of getting information from non-XML formats into XML. One way is illustrated by Wendell Piez’s Electronic Verse Engineer, which he told us about at the Balisage dress rehearsal on Sunday [Piez 2022]. (If you didn’t attend the dress rehearsal, you missed two good short talks. Remember that next year — a word to the wise.)

A broader approach, although one that doesn’t usually match Wendell’s snazzy interface, is described by Invisible XML. I hope that some of you are as excited about the prospects of Invisible XML as I am, and that we can build a large body of published grammars that can be used to move non-XML data into XML tool chains [Hillman et al. 2022b].

But interacting well with non-XML formats frequently involves not just reading non-XML data into XML for processing with XML tools, but often also re-serializing the output at the end of the pipeline into the non-XML format it came from. Tomos Hillman and others have often pointed out that the same grammar we use to parse data from format XYZ into XML should in principle be usable to guide us in re-serializing data from that XML form back into format XYZ. For various reasons I won’t go into here, that’s not always possible for an iXML grammar. But working out the conditions under which a single grammar can define the mapping in both directions — and writing software to read that grammar and provide the serialization — remains a open challenge.

Sometimes working with non-XML data and producing non-XML output can conveniently be done by translating to XML and back out, and as Michael Kay pointed out yesterday, in the case of JSON, the 3.0 versions of XSLT and XQuery can do that with their JSON-to-XML and XML-to-JSON functions [Kay 2022]. But as he observed, this process is not always as convenient as we might like, and so he has found it opportune to improve the treatment of maps and arrays in XSLT and XQuery. And for the two sample XSLT transforms he took as examples, the changes he sketched out reduced the size of the transforms by a factor of ten. And if we assume that more lines of code mean more opportunities for errors, then the changes he sketched out are likely to reduce the likelihood of bugs by a similar amount.^[4]

XML Data That’s Not in the Form We Want

Sometimes the complexity of a process doesn’t result from mismatches in the data formats. Even if there are standardized conventions for inter-program communication, as Meyer describes them, — for example, XML — it’s not necessarily easy to move information from one form to another, or to construct a pipeline that takes the information where you want it to go. Consider, for example, the workflows that Gayanthika Udeshani showed us on Tuesday, for extracting useful XML from Excel [Udeshani 2022]. They showed just how complex such a task can be (and just how complex an XML format for a mature and sophisticated product like Excel can be). I find myself divided equally between shock at the complexity of the XML format she is working from and awe at the sophistication and power of the workflows she showed. And add to that a sense of wonder at how that thin layer of homogeneity provided by XML manages to make such workflows feasible.

Earlier today, Geert Bormans showed us another project that uses a generic XML tool chain to work with Excel data [Bormans 2022b]. There were, again, plenty of complications in the file format, but because of the XML tool chain, his presentation of the project was able to focus on the complications arising from the intrinsic complexity of the information and the administrative procedures involved, and not just on the complexity of the format-to-format translations. He characterized his paper as involving nothing really, really exciting, but with all due respect, I beg to differ. I found it really, really exciting.

As Geert Bormans pointed out, all those who work with other people who sometimes use Office formats have a deep debt to those who did whatever organization-internal work was necessary in order to persuade the Office product teams to use an XML-based format. (Thank you, Jean Paoli.) It may be complicated to get useful XML out of Office formats today, but if Excel did not use an XML-based format, I’m pretty sure it would be a lot more complicated.^[5]

In some cases, complexities inhere in the data formats we are working with; in others, those complexities are accompanied — and sometimes dwarfed — by those growing out of the organizational situation. Some of the difficulties encountered by Evan Lenz in his adventures in an AsciiDoc world come, doubtless, from AsciiDoc, but in some respects it was the organizational situation and its complexity that made the thicket of complications he described so difficult to get through [Lenz 2022].

And speaking of organizational complexities, who can match those encountered by Ari Nordström and Jean Kaplansky in their work with what looked at first like a simple Docbook conversion [Nordström / Kaplansky 2022]? I am grateful to them for pausing to extract a list of lessons to be learned from that project, not least because they look like lessons that it is much less painful to learn from their slides than by experiencing those situations on one’s own hide, as one sails in treacherous, uncharted waters.

Things Change Over Time

Thickets of complexity like those described by Evan Lenz and by Ari Nordström and Jean Kaplansky don’t usually grow overnight. Usually, I think, a thicket of that kind grows up over time. Changes over time often bring inconsistency.

Can we avoid such thickets? Can we at least minimize the chance that thickets of complexity and inconsistency will grow up in and surrounding the systems we build? And if so, how? Because things do change over time. Circumstances change, so requirements change. We learn, so our understanding changes, and maybe we figure out ways to do things we didn’t know how to do before, so our ambitions change. Our new understanding of things may well be inconsistent with the old understanding. New requirements will frequently be inconsistent with the old ones. Can we find a way to allow change and development while retaining enough consistency or homogeneity to be useful?

Jeff Beck outlined one approach: minimize backward incompatibility, signal a clear direction while retaining backward compatibility by deprecating features rather than removing them, keep them around as long as possible, and make breaking changes only when it becomes necessary. And counterbalance those breaking changes with desirable new functionality [Beck 2022]. Will it work? Time will tell. If the experience of the earlier breaking changes in the JATS vocabulary is any guide, the answer will be: partly. For some people, the transition will be eased, and they’ll make it successfully. And other users may balk.

In DTDs and other schemas, we usually assign names and numbers to different stages of development (versions of the schema), and the document type declaration or any similar association between a document and a schema can show us and our software which version of the vocabulary is in use. That works quite well for schema validators which typically use a standard, constant schema validation engine to perform validation using a schema which is loaded dynamically. It doesn’t work quite so smoothly for processing software where knowledge of the specifics of the version supported and their operational semantics is more or less built in.

The pragmas proposal described by Bethan Tovey-Walsh, Norm Tovey-Walsh, and their co-authors illustrates an attempt to ease the difficulties attendant on that situation, by marking not the entire input — here the entire iXML grammar — with a version identifier, but individual parts of the input which involve this or that non-standard feature [Hillman et al. 2022a]. The pragmas proposal they describe hopes to allow controlled experimentation with new features while still preserving interoperability for processing which uses the standard semantics, so that users can use particular pragmas when they are supported and the user finds them useful, without falling unawares into lock-in or dependency on any one particular processor. Will that proposal succeed? Here, too, time will tell.

Now, it’s one thing to be designing easy transitions from one state of things — one version — to the next, or easy co-habitation between multiple versions of things. It’s a different challenge entirely to find a way to ensure the longevity of data or a system after you have turned out the lights and everyone has gone home. Joey Takeda and Martin Holmes showed us one approach to this problem: to increase the preservability of a web site by reducing its administrative footprint and making it take as little maintenance effort as possible, so as to increase the likelihood that libraries or archives will be able to keep the site alive as time goes on when none of the original developers are around [Takeda / Holmes 2022]. One key point in their work is that they were able to identify common functionality (consistency!) to support the range of digital editions that they were trying to handle.

Different Languages

This leads me to Hugh Cayless’ talk yesterday about translating the TEI Guidelines into other languages. For any tag set intended for international use, this is or should be a topic of concern, and I think Hugh set a very high bar for infrastructure that makes it possible to apply crowd-sourcing techniques to make progress on the problem while retaining relevant quality controls [Cayless 2022].

Different Points of View

I like it that people speak different languages.

I like the fact that people don’t always think alike. For example, if everyone thought like me, we would never have learned how to exploit the template call stack as a dynamic substitute for the static containment hierarchy in the data, the way Michael Kay laid it out in discussing how to get around the absence of the ancestor axis in XDM maps [Kay 2022].

And if everyone had the same point of view, we would never have gotten the insights into metadata by and for authors and process control that Mary Holstege shared yesterday [Holstege 2022] (not to mention the pretty pictures). And if everyone thought and spoke alike — and if that didn’t change over time — we would never have needed Allen Renear and Steve DeRose to examine the history of terminology for markup categories over the years [Renear / DeRose 2022]. And the world would be a less interesting place.

I think the kind of in-the-source internationalization and localization that the TEI manages by using the @xml:lang attribute speaks well for the particular brand of homogeneity provided by XML. Maybe it’s just me, but I don’t see a good way to do that in markdown.

In general, I think the relatively rich structures provided by XML seem to me to make it easier to accommodate growth and change in XML than in some other formats. Mary Holstege is able to extend her XML formats to include the metadata she needs [Holstege 2022]. Robin La Fontaine and John Francis can add Delta attributes to table elements in order to annotate a row or cell with information on the comparison [La Fontaine / Francis 2022]. So when we seek to design systems to accommodate differences in point of view, or differences in application domain, or in institutional practice, XML does seem to have some advantages.

When an XML vocabulary is well designed, sometimes it can be used in a wide variety of different flavors reflecting very different local practice. Geert Bormans showed, in the dress rehearsal on Sunday, how it’s possible to customize Akoma Ntoso without ever touching the base schema [Bormans 2022a]. (Look ma! No hands!)

Ravit David showed us on Tuesday that with judicious customization a vocabulary like BITS can in fact be applied well outside the domain for which it is nominally intended [David 2022].

Differences in Data / Versions

There is one kind of inconsistency that I have not yet touched on, one that can drive us wild: inconsistency among multiple representations of the same thing. I mean, having two copies of something that do not agree in places where we think they should agree. It happens. And the first thing we have to do, quite often, is ask: Exactly where? Exactly how?

That’s what diff is for. But off-the-shelf diff doesn’t do very well on marked-up data. That’s what Delta XML and other XML-oriented comparison tools are for.

But some XML formats, like CALS tables, pose particular challenges. They are perhaps not quite as complex as Excel — if only we could agree on a quantitative measure of markup-language complexity! — but they’re complicated enough. Robin La Fontaine and John Francis showed us earlier today how a sufficiently determined team can address those challenges. First, make the problem simpler, and then reintroduce the complications [La Fontaine / Francis 2022].

There are some domains where even the thought that there might be inconsistency, or variation, is enough to make some people very unhappy. They do not want to think about the implications of such variations. Prominent among those domains is the domain of sacred texts.^[7] But as Jonathan Robie illustrated, those who engage most intimately and directly with the Judeo-Christian Bible know full well that they must engage with inconsistency and variation [Robie 2022]. The text is available in many languages, and to improve our understanding of the text, it’s useful to compare the different language versions, which will unavoidably have different structures at the sentence, phrase, and word levels. And the text is sometimes obscure so that our grammatical analysis may vary, and even where the text isn’t obscure, our habits of grammatical analysis may vary. And the ancient sources of the text vary among themselves.

Now, for Biblical texts, the importance of the book means that the major witnesses to the text have long since been collated by hand, and in modern times often collated again by machine, and the variants have been published many times in many ways.

For other texts that are not sacred, the collation of multiple witnesses often remains to be done, and the development and exploitation of collation tools is one of the perpetually active subfields of digital humanities. It’s in this context that I think the contribution made by Joel Kalvesmaki’s extension of his Text Alignment Network tools to perform multiple string collation is most directly visible [Kalvesmaki 2022]. As he explained, one of the trickiest problems in collating multiple witnesses is avoiding unintentional bias towards one witness or another. If we wish to approach the textual tradition with an open mind, we want to avoid all kinds of bias, including the unconscious bias that will result if we organize the apparatus one way around one witness rather than another way. And that his tools are so fast and so capable, and they produce such easily understood results also makes them special in my experience.

Collation illustrates an important principle relating to consistency and inconsistency. To detect textual variations, we need to align the texts. To detect inconsistency or disagreement, we must also detect consistency and agreement. As Allen Renear once said, Can we disagree about everything? Or would that be like having an airline so small that it has no non-stop flights?^[8]

It’s difficult to disagree on everything because disagreement requires a framework. The sentences P and not P are inconsistent. But the sentence P, expressed in one language, and the sentence Q, formulated in a different language that cannot express P, are neither consistent nor inconsistent. They are perhaps better described as incommensurable.

In the context of textual criticism, the required common frame of reference is a work. But if you push hard enough, you’ll end up discovering that by work we mean a set of texts that are similar enough to each other that we can place them into a common frame of reference.

For any work, text critics historically have viewed their task as identifying, in the textual tradition of a work, the correct version of the work — the one we should read. As Elisa Beshero-Bondar pointed out the other day, through the nineteenth and the first half of the twentieth century, the default assumption among textual critics was that their job is to represent the final intentions of an author, which generally led them to take as their authority the last edition published in which the author had any input [Beshero-Bondar 2022]. But since that time, there has been a reaction, and nowadays people tend to favor the original (as we like to say), uncensored version. This shift is particularly visible in editions of authors of the nineteenth century who frequently wrote politically radical works in their youth and toned them down later on as they aged.

But both of these schools of editorial practice — violently though they may disagree and vigorously though they may be at each other’s throats — agree on the assumption that the editor’s job is to find one version of the text. It is very rare to find any other approach. Folklorists have sometimes managed to achieve the mental attitude of thinking about multiple variant forms of a song without succumbing to the desire to choose one of them or to anoint one version as the best and implicitly or explicitly to devalue the others. But very few others have followed the folklorists in that regard. Very few people have been willing to take the step that Elisa Beshero-Bondar is taking: to view the work as a complex, cultural object not defined by or limited to a single text, a single form of words, or a single witness or a single document, but potentially subsuming multiple versions, whose interrelations are themselves an interesting object of study.

Machines make that feasible in ways that it was not feasible before. Variorum editions take more space. But pixels and bytes are cheaper than ink and paper. So variorum editions are possible now and economically feasible in a way that they haven’t always been. They make it easier to look at the differences among versions of a text.

A long time ago I knew an artist, who once gave his landlord a picture in lieu of rent, when he was broke. And when he was no longer broke, he offered to pay the rent in order to get the picture back. But the landlord liked the picture and didn’t want to part with it. So the artist painted the same picture over again. It wasn’t exactly the same, but it was clearly the same subject, a similar treatment, very similar composition. The differences, I seem to remember, were mostly in the color palette.

The existence of that second picture did not affect the landlord’s enjoyment of the first picture; the subject and composition and color palette were still the same as they always had been. And the second picture similarly could be appreciated on its own; indeed, some theories of the organic unity and independence of the artwork would say it must be appreciated on its own, without reference to any back story about the landlord who didn’t want to give the first picture back or anything of that kind.

But when we do look at those two pictures together, the way they resemble each other and the way they differ throw a new and rather interesting light on each picture. Different people will have different experiences, but I found it hard not to think that I saw each of those pictures in a new way, when I looked at them together and compared them. Different versions of artworks seem to show us the artists in conversation with themselves, and it’s interesting to eavesdrop and listen to what they are saying.

A variorum edition of a textual work similarly gives us a chance to eavesdrop on the conversation between different versions of the author and different versions of the work. Mary Shelley, we may say, was inconsistent in her choices of how to word certain passages of the novel. But we are under no compulsion to force the work, or the author, to be consistent. The work is more than any single text of the work. As Elisa Beshero-Bondar said, the things that change in the work — and the things that remain the same — themselves tell a story. And some of us may think that that story is worth listening to.

One of the consequences of diversity is that one person can know something that other people don’t know. One of the nice consequences of that fact is that, if the people involved all agree that it’s a good thing to do, that person can tell other people what they’ve learned. Balisage is a place where some of us who agree that markup is interesting (and possibly not on much else) can get together and tell each other what we’ve learned.

We don’t always need to agree on the right answer. We don’t always need to agree on what the question is. We don’t always need to choose. Sometimes the right thing to do about inconsistency is to stop, and contemplate it, and learn from it.

Thank you all for attending Balisage and teaching me so much.