How to cite this paper
Sperberg-McQueen, C. M. “Constructive Inconsistency.” Presented at Balisage: The Markup Conference 2022, Washington, DC, August 1 - 5, 2022. In Proceedings of Balisage: The Markup Conference 2022. Balisage Series on Markup Technologies, vol. 27 (2022). https://doi.org/10.4242/BalisageVol27.Sperberg-McQueen02.
Balisage: The Markup Conference 2022
August 1 - 5, 2022
Balisage Paper: Constructive Inconsistency
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
C. M. Sperberg-McQueen is the founder of Black Mesa Technologies LLC,
a consultancy specializing in the use of descriptive markup to help
memory institutions preserve cultural heritage information. He co-edited
the XML 1.0 specification, the Guidelines of the Text Encoding Initiative,
and the XML Schema Definition Language (XSDL) 1.1 specification.
Copyright ©2022 by the author.
Abstract
A foolish consistency,
said Emerson,
is the hobgoblin of little minds.
But how
can we know when consistency is foolish and when it is
wise?
Table of Contents
- Meyer
-
- Validation
- Kant
-
- Non-XML Data
- XML Data That’s Not in the Form We Want
- Things Change Over Time
- Plato
-
- Different Languages
- Different Points of View
- Differences in Data / Versions
In the program this session is headed Constructive
Inconsistency.
What exactly do I mean by
consistency, I wonder, and you may be wondering
too.
Etymologically, consistency and its related
words come ultimately from the Latin verb consisto,
consistere
: to stand still (and thus metaphorically to take a
stand), to become solid or freeze, to be firm or stand unshaken, and
eventually, to agree [Lewis 1890]. And in ordinary English usage, we
say that things are consistent if they agree, if
we can find a common pattern in them. A design
or technical specification is consistent if it handles similar cases
in similar ways.
Now, since pattern and
similarity are themselves not easy to define,
this isn’t exactly a definition from the ground up. It would not help
if you didn’t already have some notion of what these words mean, but I
hope it’s clear enough to go on with. This is, I think, at any rate
the kind of consistency that Tommie Usdin was talking about on Monday
when she observed that an over-zealous pursuit of consistency can put
a harmful strait-jacket on a design [Usdin 2022].
A foolish consistency,
as Emerson said, is a
hobgoblin of little minds
[Emerson 1841].
In logic, of course, consistency and
inconsistency have a more precise and technical
meaning. If you take what I believe is called the model-theoretic
view, two propositions are inconsistent if they can never both be true
at the same time in the same possible world or the same model of the
theory. And if you take what I believe is called the proof-theoretic
view, a formal system is consistent if there is no sentence
P
such that P
and not P
are
both derivable from the system’s axioms by the system’s rules of
inference. So, in the proof-theoretic view
consistency is the absence of logical
contradiction.
I mention this, in part, so that I can say that for the most
part in these remarks I will be appealing to the first, informal
notion of consistency and
inconsistency. But since I do have a certain
weakness for thinking about markup problems in the context of formal
logic, and vice versa, it’s not at all unlikely that at some point I
will hop the rails and start using the terms in their formal sense.
Bear with me when that happens. In sum, I hope that you will not mind
if I am slightly inconsistent in my usage of the term
inconsistency.
Meyer
One of the reasons that we’re all unavoidably interested in
consistency is that is makes some of our technical work simpler. By
and large, it is easier to learn and use systems that have consistent
design; that applies both to our tools and to the tools we make for
users. In his book Object-oriented Software
Construction [Meyer 1997], the computer
scientist Bertrand Meyer discusses a number of desirable properties
software can have: correctness, robustness, extendibility, etc. In
his discussion of compatibility which he defines
as the ease of combining software elements with others,
he emphasizes what I think of as a form of consistency; he writes:
The key to compatibility lies in homogeneity of
the design and in agreeing on standardized conventions for
inter-program communication. Approaches include:
-
Standardized file formats, as in the Unix system, where
every text file is simply a sequence of characters.
-
Standardized data structures, as in Lisp systems, where
all data, and programs as well, are represented by binary trees
…
-
Standardized user interfaces, … where all tools rely on
a single paradigm for communication with the user, based on
standard components such as windows, icons, menus, etc.
It’s hard for me not to see XML as fitting both into Meyer’s
description of standard file formats and into his description of
standard data structures.
Now, it does not, strictly speaking, tell us very much about the
information in a file or a data structure to say that it’s a sequence
of characters, or that it has a tree structure or a table structure,
or that it forms a directed graph. But even the relatively shallow
degree of commonality provided by these descriptions provides serious
advantages. It enabled the development of the culture of Unix
pipeline tools. It enabled a very rich collection of standard
functionality in Lisp. It underlies the power of the relational
database model. And, of course, it forms the foundation of the XML
infrastructure and the XML stack of technologies like XSLT and XPath
and XQuery and XForms and XProc and all the rest, and all the tools
the vendors have shown us this week. It has always surprised me —
and continues to surprise me when I think about it — that such a
relatively thin layer of description can serve as the foundation for
such a rich and useful infrastructure.
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.
Kant
But in other contexts, it’s not quite so clear to me that
consistency is achievable. Sometimes inconsistency seems to be a
brute fact that we cannot avoid. And that fact is, I think, at the
root of one of the reasons I’ve always been slightly uneasy about the
German philosopher Immanuel Kant.
As many of you are doubtless recalling, Kant formulated an
ethical principle known as the Categorical Imperative [Kant 1785], which gets various formulations in his work, one of
which is:
Handle nur nach derjenigen Maxime, durch die du zugleich wollen
kannst, dass sie ein allgemeines Gesetz werde.
Act only in accordance with that maxim through which you can at
the same time will that it become a universal law.
Or, as many of our mothers doubtless formulated the same
principle: how would you like it if everyone behaved that way?
Now, in a way, this strikes me as a counsel of consistency: the
more exceptions there are to any rule, the less suited it is to become
a universal law, and vice versa. Kant’s principle thus seems to me to
urge us towards a set of ethical rules which promote maximal
consistency. And that is what makes it troubling, especially in my
mother’s formulation, because no matter whether I act one way or the
other, there is essentially zero probability that
everyone is going to act that way. Or as Tommie
eloquently pointed out on Monday, the world we live in is not
consistent, nor are the people who live in it. Inconsistency is a
brute fact. If we try to eliminate it completely, we are on a fool’s
errand.
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.
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.
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.
Plato
Now, we can regret, if we wish, the fact that some people are
benighted enough not to use the data formats or software or practices
that we think would be best for them. We can regret that as
requirements and understandings change, things in our systems will
acquire polymorphism through age, as Michael Kay put it yesterday
[Kay 2022]. But inconsistency in the sense of
diversity is not just a brute fact that we can’t avoid even though we
would like to. In some contexts, at least, it also seems to me to be
a positive good.
If, in a given ecosystem, one species dominates so strongly as
to reduce the diversity of the system, either naturally or through the
introduction of monoculture in farming, then any disease or pest to
which that dominant species is vulnerable can devastate the entire
system. There are plenty of examples. I won’t go through them all;
I’ll just mention that the popularity of elms as shade trees in North
America was so great and elm trees were so universally used to shade
streets that when Dutch elm disease appeared in the U.S., tree
populations all across the country were decimated, and there were
towns that had no shade trees at all anymore. If their tree
populations had been more diverse, that would not have happened. So,
I think of diversity as often being a positive good.
Not everyone agrees. In The Republic
[Plato], for example, Plato has Socrates ask the
question:
Doesn’t the worst evil for a state arise from anything that
tends to rend it asunder and destroy its unity, while nothing does it
more good than whatever tends to bind it together and make it one?
And later speaking of the guardians of the state:
… they will all, as far as may be, feel together and aim at
the same ends, because they are convinced that their interests are
identical.
And much, much later:
The constitution cannot be upset so long as the ruling class is
of one mind.
Two things strike me when I read these passages. First, he
seems to be describing as ideal a world in which everyone is alike and
there is remarkably little diversity of values or opinions or even
taste. And second, Plato’s educational program,
which is carefully constructed to make all the guardians think alike,
seems to me to amount to a recipe for a groupthink.
These reactions may not be universal. I was brought up in a
society that in many ways values individualism over conformity and in
which freedom of thought and expression have higher status than the
values of social cohesion. It is possible — it is likely — that
someone brought up in a different culture will read those bits of
Plato differently.
But, well, for what it’s worth, I like
living in a world where not everyone is alike, where not everyone
thinks the same way, where people are interested in different things,
and where people speak different languages. I like living in one of
the few states of the U.S. where the state constitution explicitly
recognizes the right to speak Spanish when discharging your civic
duties.
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. 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?
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.
References
[Beck 2022] Beck, Jeffrey.
JATS Superhighway: Onramp to a Backward-incompatible
Version.
Presented at Balisage: The Markup Conference 2022,
Washington, DC, August 1 - 5, 2022. In
Proceedings of Balisage:
The Markup Conference 2022.
Balisage Series on Markup Technologies, vol. 27 (2022).
https://doi.org/10.4242/BalisageVol27.Beck01.
[Beshero-Bondar 2022] Beshero-Bondar, Elisa E. Adventures in Correcting XML
Collation Problems with Python and XSLT: Untangling the Frankenstein
Variorum.
Presented at Balisage: The Markup Conference 2022,
Washington, DC, August 1 - 5, 2022. In Proceedings of Balisage: The Markup Conference
2022. Balisage Series on Markup Technologies, vol. 27
(2022). https://doi.org/10.4242/BalisageVol27.Beshero-Bondar01.
[Bormans 2022a] Bormans,
Geert. Customisation of Akoma Ntoso using Schematron.
Presented at Balisage: The Markup Conference 2022, Washington, DC,
August 1 - 5, 2022. In Proceedings of Balisage:
The Markup Conference 2022. Balisage Series on Markup
Technologies, vol. 27 (2022). https://doi.org/10.4242/BalisageVol27.Bormans01.
[Bormans 2022b] Bormans,
Geert. Excel to Excel using XML, really?
Presented at
Balisage: The Markup Conference 2022, Washington, DC, August 1 - 5,
2022. In Proceedings of Balisage: The Markup
Conference 2022. Balisage Series on Markup Technologies,
vol. 27 (2022). https://doi.org/10.4242/BalisageVol27.Bormans02.
[Cayless 2022] Cayless,
Hugh. On Translating the TEI.
Presented at Balisage:
The Markup Conference 2022, Washington, DC, August 1 - 5, 2022. In
Proceedings of Balisage: The Markup Conference
2022. Balisage Series on Markup Technologies, vol. 27
(2022). https://doi.org/10.4242/BalisageVol27.Cayless01.
[David 2022] David, Ravit
H. BITS for Government Information?
Presented at
Balisage: The Markup Conference 2022, Washington, DC, August 1 - 5,
2022. In Proceedings of Balisage: The Markup
Conference 2022. Balisage Series on Markup Technologies,
vol. 27 (2022). https://doi.org/10.4242/BalisageVol27.David01.
[Emerson 1841] Emerson, Ralph
Waldo. Self-Reliance.
1841. In The Norton Anthology of American
Literature (vol. 1), eds. Ronald Gottesman, Laurence
B. Holland, David Kalstone, Francis Murphy, Hershel Parker, and
William H. Pritchard. New York: W.W. Norton & Co.,
1979.
[Gryk 2022] Gryk, Michael
Robert. Human Readability of Data Files.
Presented at
Balisage: The Markup Conference 2022, Washington, DC, August 1 - 5,
2022. In Proceedings of Balisage: The Markup
Conference 2022. Balisage Series on Markup Technologies,
vol. 27 (2022). https://doi.org/10.4242/BalisageVol27.Gryk01.
[Hillman et al. 2022a] Hillman, Tomos, C. M. Sperberg-McQueen, Bethan Tovey-Walsh
and Norm Tovey-Walsh. Designing for change: Pragmas in
Invisible XML as an extensibility mechanism.
Presented at
Balisage: The Markup Conference 2022, Washington, DC, August 1 - 5,
2022. In Proceedings of Balisage: The Markup
Conference 2022. Balisage Series on Markup Technologies,
vol. 27 (2022). https://doi.org/10.4242/BalisageVol27.Sperberg-McQueen01.
[Hillman et al. 2022b] Hillman,
Tomos, John Lumley, Steven Pemberton, C. M. Sperberg-McQueen, Bethan
Tovey-Walsh and Norm Tovey-Walsh. Invisible XML coming into
focus: Status report from the community group.
Presented at
Balisage: The Markup Conference 2022, Washington, DC, August 1 - 5,
2022. In Proceedings of Balisage: The Markup
Conference 2022. Balisage Series on Markup Technologies,
vol. 27 (2022). https://doi.org/10.4242/BalisageVol27.Eccl01.
[Holstege 2022] Holstege,
Mary. Metadata for Creators.
Presented at Balisage: The
Markup Conference 2022, Washington, DC, August 1 - 5, 2022. In
Proceedings of Balisage: The Markup Conference
2022. Balisage Series on Markup Technologies, vol. 27
(2022). https://doi.org/10.4242/BalisageVol27.Holstege01.
[Johnson / Cureton 2022]
Johnson, Robert, and Adam Cureton. Kant’s Moral Philosophy.
The Stanford Encyclopedia of Philosophy
(Fall 2022 Edition), ed. Edward N. Zalta. On the web
at https://plato.stanford.edu/archives/fall2022/entries/kant-moral/.
[Kalvesmaki 2022] Kalvesmaki, Joel. Multiple String Comparison in XSLT with
tan:collate().
Presented at Balisage: The Markup Conference
2022, Washington, DC, August 1 - 5, 2022. In Proceedings of Balisage: The Markup Conference
2022. Balisage Series on Markup Technologies, vol. 27
(2022). https://doi.org/10.4242/BalisageVol27.Kalvesmaki01.
[Kant 1785] Kant,
Immanuel. Grounding for the Metaphysics of
Morals. 1785. 3rd ed. Translated by
J.W. Ellington. Indianapolis: Hackett Pub., 1993.
[Kay 2022] Kay,
Michael. XSLT Extensions for JSON Processing.
Presented
at Balisage: The Markup Conference 2022, Washington, DC, August 1 - 5,
2022. In Proceedings of Balisage: The Markup
Conference 2022. Balisage Series on Markup Technologies,
vol. 27 (2022). https://doi.org/10.4242/BalisageVol27.Kay01.
[Kimber 2022] Kimber,
Eliot. Project Mirabel: XQuery-Based Documentation Reporting
and Exploration System.
Presented at Balisage: The Markup
Conference 2022, Washington, DC, August 1 - 5, 2022. In Proceedings of Balisage: The Markup Conference
2022. Balisage Series on Markup Technologies, vol. 27
(2022). https://doi.org/10.4242/BalisageVol27.Kimber01.
[La Fontaine / Francis 2022] La Fontaine, Robin, and John Francis. The Impossible Task
of Comparing CALS Tables.
Presented at Balisage: The Markup
Conference 2022, Washington, DC, August 1 - 5, 2022. In Proceedings of Balisage: The Markup Conference
2022. Balisage Series on Markup Technologies, vol. 27
(2022). https://doi.org/10.4242/BalisageVol27.LaFontaine01.
[Lenz 2022] Lenz,
Evan. XML in an AsciiDoc World: SaxonJS to the Rescue.
Presented at Balisage: The Markup Conference 2022, Washington, DC,
August 1 - 5, 2022. In Proceedings of Balisage:
The Markup Conference 2022. Balisage Series on Markup
Technologies, vol. 27 (2022). https://doi.org/10.4242/BalisageVol27.Lenz01.
[Lewis 1890] Lewis, Charlton
T. An Elementary Latin Dictionary. New York,
Cincinnati, and Chicago: American Book Company, 1890. Available online
via the Perseus Digital Library, Tufts University: https://www.perseus.tufts.edu/hopper/text?doc=Perseus%3Atext%3A1999.04.0060%3Aentry%3Dconsisto.
[Meyer 1997] Meyer,
Bertrand. Object-oriented Software
Construction. 2nd ed. Upper Saddle River, NJ: Prentice
Hall PTR, 1997.
[Nordström / Kaplansky 2022] Nordström, Ari, and Jean
Kaplansky. Migrating DocBook to Uncharted Waters.
Presented at Balisage: The Markup Conference 2022, Washington, DC,
August 1 - 5, 2022. In Proceedings of Balisage:
The Markup Conference 2022. Balisage Series on Markup
Technologies, vol. 27 (2022). https://doi.org/10.4242/BalisageVol27.Nordstrom01.
[Piez 2022] Piez,
Wendell. Electronic Verse Engineer.
Presented at
Balisage: The Markup Conference 2022, Washington, DC, August 1 - 5,
2022. In Proceedings of Balisage: The Markup
Conference 2022. Balisage Series on Markup Technologies,
vol. 27 (2022). https://doi.org/10.4242/BalisageVol27.Piez01.
[Plato] Plato. The Republic of Plato. Translated with
introduction and notes by Francis MacDonald Cornford. London: Oxford
University Press, 1941; 57th printing, 1975.
[Renear / DeRose 2022] Renear, Allen H., and Steven J. DeRose. Markup Category
Terminology over the Years: a First Look.
Presented at
Balisage: The Markup Conference 2022, Washington, DC, August 1 - 5,
2022. In Proceedings of Balisage: The Markup
Conference 2022. Balisage Series on Markup Technologies,
vol. 27 (2022). https://doi.org/10.4242/BalisageVol27.Renear01.
[Robie 2022] Robie,
Jonathan. Biblical Scholarship in the GitHub Jungle.
Presented at Balisage: The Markup Conference 2022, Washington, DC,
August 1 - 5, 2022. In Proceedings of Balisage:
The Markup Conference 2022. Balisage Series on Markup
Technologies, vol. 27 (2022). https://doi.org/10.4242/BalisageVol27.Robie01.
[Takeda / Holmes 2022] Takeda, Joey, and Martin Holmes. Serverless Searching
with XSLT and JavaScript: Introducing staticSearch.
Presented
at Balisage: The Markup Conference 2022, Washington, DC, August 1 - 5,
2022. In Proceedings of Balisage: The Markup
Conference 2022. Balisage Series on Markup Technologies,
vol. 27 (2022). https://doi.org/10.4242/BalisageVol27.Takeda01.
[Udeshani 2022] Udeshani,
Gayanthika. Getting Useful XML out of Microsoft Excel.
Presented at Balisage: The Markup Conference 2022, Washington, DC,
August 1 - 5, 2022. In Proceedings of Balisage:
The Markup Conference 2022. Balisage Series on Markup
Technologies, vol. 27 (2022). https://doi.org/10.4242/BalisageVol27.Udeshani01.
[Usdin 2022] Usdin,
B. Tommie. Destructive Consistency.
Presented at
Balisage: The Markup Conference 2022, Washington, DC, August 1 - 5,
2022. In Proceedings of Balisage: The Markup
Conference 2022. Balisage Series on Markup Technologies,
vol. 27 (2022). https://doi.org/10.4242/BalisageVol27.Usdin01.
×Beck, Jeffrey.
JATS Superhighway: Onramp to a Backward-incompatible
Version.
Presented at Balisage: The Markup Conference 2022,
Washington, DC, August 1 - 5, 2022. In
Proceedings of Balisage:
The Markup Conference 2022.
Balisage Series on Markup Technologies, vol. 27 (2022).
https://doi.org/10.4242/BalisageVol27.Beck01.
×Beshero-Bondar, Elisa E. Adventures in Correcting XML
Collation Problems with Python and XSLT: Untangling the Frankenstein
Variorum.
Presented at Balisage: The Markup Conference 2022,
Washington, DC, August 1 - 5, 2022. In Proceedings of Balisage: The Markup Conference
2022. Balisage Series on Markup Technologies, vol. 27
(2022). https://doi.org/10.4242/BalisageVol27.Beshero-Bondar01.
×Bormans,
Geert. Customisation of Akoma Ntoso using Schematron.
Presented at Balisage: The Markup Conference 2022, Washington, DC,
August 1 - 5, 2022. In Proceedings of Balisage:
The Markup Conference 2022. Balisage Series on Markup
Technologies, vol. 27 (2022). https://doi.org/10.4242/BalisageVol27.Bormans01.
×Bormans,
Geert. Excel to Excel using XML, really?
Presented at
Balisage: The Markup Conference 2022, Washington, DC, August 1 - 5,
2022. In Proceedings of Balisage: The Markup
Conference 2022. Balisage Series on Markup Technologies,
vol. 27 (2022). https://doi.org/10.4242/BalisageVol27.Bormans02.
×Cayless,
Hugh. On Translating the TEI.
Presented at Balisage:
The Markup Conference 2022, Washington, DC, August 1 - 5, 2022. In
Proceedings of Balisage: The Markup Conference
2022. Balisage Series on Markup Technologies, vol. 27
(2022). https://doi.org/10.4242/BalisageVol27.Cayless01.
×David, Ravit
H. BITS for Government Information?
Presented at
Balisage: The Markup Conference 2022, Washington, DC, August 1 - 5,
2022. In Proceedings of Balisage: The Markup
Conference 2022. Balisage Series on Markup Technologies,
vol. 27 (2022). https://doi.org/10.4242/BalisageVol27.David01.
× Emerson, Ralph
Waldo. Self-Reliance.
1841. In The Norton Anthology of American
Literature (vol. 1), eds. Ronald Gottesman, Laurence
B. Holland, David Kalstone, Francis Murphy, Hershel Parker, and
William H. Pritchard. New York: W.W. Norton & Co.,
1979.
×Gryk, Michael
Robert. Human Readability of Data Files.
Presented at
Balisage: The Markup Conference 2022, Washington, DC, August 1 - 5,
2022. In Proceedings of Balisage: The Markup
Conference 2022. Balisage Series on Markup Technologies,
vol. 27 (2022). https://doi.org/10.4242/BalisageVol27.Gryk01.
×Hillman, Tomos, C. M. Sperberg-McQueen, Bethan Tovey-Walsh
and Norm Tovey-Walsh. Designing for change: Pragmas in
Invisible XML as an extensibility mechanism.
Presented at
Balisage: The Markup Conference 2022, Washington, DC, August 1 - 5,
2022. In Proceedings of Balisage: The Markup
Conference 2022. Balisage Series on Markup Technologies,
vol. 27 (2022). https://doi.org/10.4242/BalisageVol27.Sperberg-McQueen01.
×Hillman,
Tomos, John Lumley, Steven Pemberton, C. M. Sperberg-McQueen, Bethan
Tovey-Walsh and Norm Tovey-Walsh. Invisible XML coming into
focus: Status report from the community group.
Presented at
Balisage: The Markup Conference 2022, Washington, DC, August 1 - 5,
2022. In Proceedings of Balisage: The Markup
Conference 2022. Balisage Series on Markup Technologies,
vol. 27 (2022). https://doi.org/10.4242/BalisageVol27.Eccl01.
×Holstege,
Mary. Metadata for Creators.
Presented at Balisage: The
Markup Conference 2022, Washington, DC, August 1 - 5, 2022. In
Proceedings of Balisage: The Markup Conference
2022. Balisage Series on Markup Technologies, vol. 27
(2022). https://doi.org/10.4242/BalisageVol27.Holstege01.
×Kalvesmaki, Joel. Multiple String Comparison in XSLT with
tan:collate().
Presented at Balisage: The Markup Conference
2022, Washington, DC, August 1 - 5, 2022. In Proceedings of Balisage: The Markup Conference
2022. Balisage Series on Markup Technologies, vol. 27
(2022). https://doi.org/10.4242/BalisageVol27.Kalvesmaki01.
×Kant,
Immanuel. Grounding for the Metaphysics of
Morals. 1785. 3rd ed. Translated by
J.W. Ellington. Indianapolis: Hackett Pub., 1993.
×Kay,
Michael. XSLT Extensions for JSON Processing.
Presented
at Balisage: The Markup Conference 2022, Washington, DC, August 1 - 5,
2022. In Proceedings of Balisage: The Markup
Conference 2022. Balisage Series on Markup Technologies,
vol. 27 (2022). https://doi.org/10.4242/BalisageVol27.Kay01.
×Kimber,
Eliot. Project Mirabel: XQuery-Based Documentation Reporting
and Exploration System.
Presented at Balisage: The Markup
Conference 2022, Washington, DC, August 1 - 5, 2022. In Proceedings of Balisage: The Markup Conference
2022. Balisage Series on Markup Technologies, vol. 27
(2022). https://doi.org/10.4242/BalisageVol27.Kimber01.
×La Fontaine, Robin, and John Francis. The Impossible Task
of Comparing CALS Tables.
Presented at Balisage: The Markup
Conference 2022, Washington, DC, August 1 - 5, 2022. In Proceedings of Balisage: The Markup Conference
2022. Balisage Series on Markup Technologies, vol. 27
(2022). https://doi.org/10.4242/BalisageVol27.LaFontaine01.
×Lenz,
Evan. XML in an AsciiDoc World: SaxonJS to the Rescue.
Presented at Balisage: The Markup Conference 2022, Washington, DC,
August 1 - 5, 2022. In Proceedings of Balisage:
The Markup Conference 2022. Balisage Series on Markup
Technologies, vol. 27 (2022). https://doi.org/10.4242/BalisageVol27.Lenz01.
×Meyer,
Bertrand. Object-oriented Software
Construction. 2nd ed. Upper Saddle River, NJ: Prentice
Hall PTR, 1997.
×Nordström, Ari, and Jean
Kaplansky. Migrating DocBook to Uncharted Waters.
Presented at Balisage: The Markup Conference 2022, Washington, DC,
August 1 - 5, 2022. In Proceedings of Balisage:
The Markup Conference 2022. Balisage Series on Markup
Technologies, vol. 27 (2022). https://doi.org/10.4242/BalisageVol27.Nordstrom01.
×Piez,
Wendell. Electronic Verse Engineer.
Presented at
Balisage: The Markup Conference 2022, Washington, DC, August 1 - 5,
2022. In Proceedings of Balisage: The Markup
Conference 2022. Balisage Series on Markup Technologies,
vol. 27 (2022). https://doi.org/10.4242/BalisageVol27.Piez01.
×Plato. The Republic of Plato. Translated with
introduction and notes by Francis MacDonald Cornford. London: Oxford
University Press, 1941; 57th printing, 1975.
×Renear, Allen H., and Steven J. DeRose. Markup Category
Terminology over the Years: a First Look.
Presented at
Balisage: The Markup Conference 2022, Washington, DC, August 1 - 5,
2022. In Proceedings of Balisage: The Markup
Conference 2022. Balisage Series on Markup Technologies,
vol. 27 (2022). https://doi.org/10.4242/BalisageVol27.Renear01.
×Robie,
Jonathan. Biblical Scholarship in the GitHub Jungle.
Presented at Balisage: The Markup Conference 2022, Washington, DC,
August 1 - 5, 2022. In Proceedings of Balisage:
The Markup Conference 2022. Balisage Series on Markup
Technologies, vol. 27 (2022). https://doi.org/10.4242/BalisageVol27.Robie01.
×Takeda, Joey, and Martin Holmes. Serverless Searching
with XSLT and JavaScript: Introducing staticSearch.
Presented
at Balisage: The Markup Conference 2022, Washington, DC, August 1 - 5,
2022. In Proceedings of Balisage: The Markup
Conference 2022. Balisage Series on Markup Technologies,
vol. 27 (2022). https://doi.org/10.4242/BalisageVol27.Takeda01.
×Udeshani,
Gayanthika. Getting Useful XML out of Microsoft Excel.
Presented at Balisage: The Markup Conference 2022, Washington, DC,
August 1 - 5, 2022. In Proceedings of Balisage:
The Markup Conference 2022. Balisage Series on Markup
Technologies, vol. 27 (2022). https://doi.org/10.4242/BalisageVol27.Udeshani01.
×Usdin,
B. Tommie. Destructive Consistency.
Presented at
Balisage: The Markup Conference 2022, Washington, DC, August 1 - 5,
2022. In Proceedings of Balisage: The Markup
Conference 2022. Balisage Series on Markup Technologies,
vol. 27 (2022). https://doi.org/10.4242/BalisageVol27.Usdin01.