How to cite this paper

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.

Welcome to Balisage 2022. I was a little sad when we decided that it was necessary to do Balisage virtually again. But I’m not 100% displeased by it because we have speakers and attendees from all the world. We have a far wider range of geographic sources of people, and I think, also of skills and interests than we would have if we were in person anywhere. We have people who have been to every Balisage conference, every Markup Technologies before that, who were at many XML conferences, the one and only SGML/XML conference, and at a bunch of SGML conferences before that. Welcome home, fellow old-timers! We also have some people who are at this markup geek-fest for the first time. Welcome new friends! Please jump in. I want you to understand that your comments, questions, suggestions, and opinions are welcome. Really. We also have a few of my personal favorite participants, those who are here for the second time. That means they know, more or less, what they’re in for and what to expect, and they came back!

If you’re listening now, you made it into Whova and into this session. Those are the two hardest things a Balisage participant needs to know how to do. Let me give you a few tips on how to negotiate the logistics of Balisage and Whova (Whova, that’s the conference portal). First and probably most important, if you get stuck or don’t know how to do something, send up a flag; say so. Send email to <info@Balisage.net>, send me a message through Whova, post a question in Whova’s community Ask the Organizers Anything, send a message to anybody on the Conference Committee, or just put it into chat on whatever session is open at the time.

So, since I’ve told you to send a message to the Conference Committee, let me tell you who they are: Debbie Lapeyre, Jim Mason, Michael Sperberg-McQueen, and Norm Walsh. You’re going to be seeing them throughout the conference. They will be introducing speakers, managing questions & answers, and generally keeping things running. Also keeping things running will be Tonya Gaylord; ask her if you need a receipt for your conference registration, a correction to your paper in the proceedings, or any other logistical sort of help.

We are grateful to our sponsors. Their support takes a lot of the financial pressure off making Balisage happen. You’ll see the names of our sponsors at the top of the Whova screen, on the Balisage website, and in the conference proceedings. Some of them are going to give presentations during the mid-day break. I want to thank Docugami, Typefi, Antenna House, <oXygen/>, and le-tex. Their support is enormously helpful.

Balisage is not television. Balisage is not television in many ways. Balisage speakers are selected for the quality of their ideas, for what they have to tell us. Some of them are experienced speakers. Some them are a little shy. Some are speaking their third or fourth language. Some of them are not polished presenters. Listen to the ideas. If you want content where nobody stumbles over their words, stutters, repeats themselves, or skips something and has to backtrack, go watch television. Balisage is not television. Balisage is live. We have no pre-recorded content, and we do not record the event. There is a permanent record of Balisage; it’s the proceedings.

Balisage is not television. There are a couple of things you can do to help. When you’re not speaking, please mute your microphone. Even the little sounds of several people shifting in their chairs, sipping coffee, moving paper become distracting. Also, if you’re actively watching, please leave your camera on. Not necessarily all of you, only those who are comfortable that way. And not necessarily all of the time; turn your camera off if you’re bored or shaving. But if you’re actually watching, please leave your camera on because for many of us — especially those of us who are not experienced television presenters — it is easier to talk to people we can see.

Balisage is interactive. Questions for the speaker go in the Q&A window; a moderator will sequence them and manage them for the speaker. Why? Because the speakers frequently can’t see the Q&A window because when we share your screen, we lose the ability to see the Q&A window. The moderator is going to manage and sequence the questions. Maybe the moderator will ask the first question that was asked first, or maybe the moderator start with one that they know has a short answer or that they think will answer several people’s questions or that seems very general, or very specific, or that comes from someone we haven’t heard from recently. The moderator is going to pick the sequence.

Don’t raise your hand. There are too many of us for it to be likely that a raised hand will be noticed.

Whova provides a chat window. Use it; enjoy it. Don’t expect the speaker to read what is in there until long after the conference is over.

While I’m encouraging active participation, I should mention we have a code of conduct. It’s available both on the Balisage site and in Whova. We take it seriously. So should you. This is a great place for disagreements; this is a great place to discuss priorities, approaches, big pictures, details. But keep it civil. Anybody who doesn’t will be ejected. We just won’t put up with it. We can disagree and be polite.

Balisage sessions alternate virtual rooms. You get to the rooms through the Agenda. The speakers are introduced, they give a presentation, and they respond to the questions in the Q&A window, ideally all in 45 minutes. We then have a 15-minute break, at least officially. If we were in a physical conference facility, that is when most people would head for the hospitality station to refill their coffee cups, and a few would gather around the speaker for informal conversation. This, by the way, is my all-time favorite piece of a conference: those conversations right after a talk. The speaker and the people who gather after the talk are welcome to stay where they are and discuss for a while; through the break and into the next session if they want to. The next session will be starting in a different room. How do you get there? Through the Agenda. You go to the Agenda, you click on the session you want to go to.

We want to know what you think. The very last session of the conference is a feedback session. In addition, as soon as a session starts a Rate Session button will be functional, leading to a questionnaire in which you can tell us what you think about the conference and about the speaker and the content of the talk. Don’t expect the speaker to see that promptly; they’ll get it after the conference, but we’ll pass along any interesting or helpful comments to the speakers from the session.

How else can I inspire you all to get involved in Balisage? Q&A’s for the speakers and chat are important. Balisage Bard is our literary performance activity. Participants recite poems, they sing songs, they act out skits. Markup-related poetry can be very weird and kind of entertaining. Anything markup-related and within the code of conduct and two minutes or shorter is welcome. There is a place to sign up in the community.

We have a new thing at Balisage this year called Open Mic. We found as we were encouraging people to submit papers to Balisage that several said, Well, I have an interesting thing that I might want to talk about, but it isn’t big enough for a talk; it’s not a paper; it’s just a tidbit. So, we have Open Mic. And we have a few people who have already said We have tidbits we want to share. But we have room for more. Two to ten minutes, any topic within the code of conduct. Sign up by sending email to <info@balisage.net>. If you look at the program, you’ll see what our guidance is on what we need to know from you.

We also have Birds of a Feather discussions scheduled for the ends of the days, Monday through Thursday. For each day, we’ve already got one topic set. But we’re happy to create more of them. We have the ability to make a bunch of Birds of a Feather spaces. Tell us what you want to discuss with each other; we’ll create a Birds of a Feather room for that conversation.

Some of you have already visited our social spaces: the Firepit and the Curved Benches. Like the benches outside the auditorium of a venue-based conference, they are always there. Sometimes there will be people hanging out to chat, sometimes not. Last year a several people mentioned to me that they popped into one of the social spaces, saw that there was nobody there, and left. I asked how long they were there, and they said, Oh, I don’t know. Ten seconds. There was nobody there; why would I stay? Well, you know, there are about 125 of us here; if each of us spends about two seconds, decides nobody is there, and leaves, nobody is ever going to see anybody there. That doesn’t work. If you’re interested in being social and when you get there, nobody is there, sit down, sip your tea, hang around for a few minutes, and see if somebody else stops by. Think about it in systems terms for just a moment.

Systems terms — that’s what we’re talking about this week. This week we’re going to talk about markup and about the interfaces and interactions between the world of markup — or the world of markup as we believe it should be — and the real world — or the real world as we believe it should be. We’re going to talk about real projects in which we have been forced by sponsors, content owners, or management to compromise on markup best practice as we understand it. We’re going to talk about what markup best practice is and will probably disagree with each other about it. I hope we will go on to discuss how we made it work in the environment we actually work in because that is the only test of success. At Balisage we’re likely to be challenged with respect to the tag set, markup environment, and tools we’ve chosen for particular work. Why did you decide not to use my favorite tag set or my favorite tool or specification? is going to be a very common question at Balisage. In fact, it was asked already once at the pre-conference yesterday. I don’t want to discourage questions of this form, but I want to remind everyone that they are requests for information, not back-door criticisms of the decisions that were made. People choose to use infrastructure and tools that seem to be good fits for the work they are doing and that work in the environments they are familiar with and will be able to work in effectively. From time to time, we make technology selection choices out of a desire to stretch our wings, but more often we choose the familiar because we would like to succeed at what we’re trying to do.

At Balisage we are in the unusual situation of being among people who are familiar with markup and who are, generally, comfortable looking at pointy-bracket syntax in one sort of code or another. Let’s enjoy that. We will have slides with pointy brackets on them. They won’t poke us, and we won’t bleed. But let’s remember that most of the world — and most of the people we work with — are not comfortable having things explained to them by sharing fragments of XML documents, snippets of XSLT, or short XQuerries. I understand and generally sympathize with the sentiment behind the probably apocryphal story of Mies van der Rohe involving the workers installing mechanical window shades. The main part of the shades had been installed, and the workers started to place the valance on top. Mies asked what they were doing and why. The answer: installing the valance to hide the mechanism. Mies is said to have responded, Take it down. Never hide the mechanism.

As a child, I removed or occasionally bent covers to see how things worked. I disassembled and usually managed to re-assemble toys, both my own and other people’s. I remember watching the gears of an escalator with transparent sides for far longer than the adults I was with understood or had patience for. I understand wanting to see the mechanism. But many people have other world views. Valances exist for a reason. Most toys resist disassembly. Most escalators have opaque sides. And most end user computing applications are hidden behind graphic user interfaces.

This year at Balisage we will hear about efforts to hide the mechanism or to make it more palatable to people with less comfort than I have for seeing the mechanics of markup and mechanical markup manipulation tools. We may, as a community, be coming to terms with the fact that many people do not share our interests. That doesn’t mean they’re stupid or lazy or misguided or silly. It means they have different interests. People who are experts in medical research, writing television scripts, managing fire departments, farming, or politics are not likely to have any interest in learning XML. And people who try to coax, bully, bribe, or shame them into it are likely to fail.

I live in an environment in which it is assumed that everyone drives. This means that an enormous amount of the public space and resources are devoted to streets, parking lots, and the enforcement of traffic and parking laws. It means that many people invest significant resources into cars and the maintenance and housing of those cars. It means that for many people getting a license to drive and a car are tickets to full participation in society and the economy. It means that, while unstated, the society excludes people who do not or cannot drive. Non-drivers are othered or secondary. We provide mass transportation, but even there, we assume people can and will drive to access it. That isn’t strictly necessary, but end-to-end public transportation where I live is inconvenient and uncomfortable. We tolerate that because the system is designed for people who can and do drive. I suspect that most of us at Balisage recognize this as an imperfect social model; most of us are likely to agree that the people who are too young to drive, or are unable or unwilling to drive for some reason, or are unable to afford a reliable car should still be considered full members of society. Some of us would be willing to put money into making public transportation easier, more comfortable, and more affordable.

Why am I talking about public transportation at Balisage? Because many of us who don’t want to think of ourselves as transporation elitists seem to be markup elitists. We know about markup. Not only do we know about it, we think explicit markup — often, but not always XML — is the right answer to almost every text document data manipulation problem. XML, with XSLT and perhaps XSL-FO and CSS, is the right way to create, manage, interchange, and publish anything and everything. We offer to help out by moving content from word processors, databases, or spreadsheets into clean XML. We get sucked into long, circular discussions about the advantages of XML over JSON, or JSON over XML. We — okay, in this case, I — sneer at people who don’t see why anyone would want to, as a friend of a friend described it, go to all the trouble to typeset from that XML junk when Microsoft Word does high-end publishing, including footnotes and everything. So, my friend of a friend clearly does not know what high-end publishing is, or what everything is involved in typesetting. I think my friend of a friend is a pretty typical member of the world that has never heard of Balisage and wouldn’t be interested if they had. A world we need to work with.

Most of us know and have deeply internalized the logic behind and the details of one or perhaps a few tagsets, specifications, or tools. We see the world through that lens, and sometimes we get impatient with people who don’t. That is not a good look either at Balisage or any place else. It seems to be the nature of people drawn to discussions of markup — that is, the people likely to be here at Balisage — that we value consistency. Many of us want the world — or at least the part of it that we work with — to be logical and consistent. We write naming conventions and stick to them. We want parallel cases to be handled in parallel ways. We think we’re improving the world by pushing for this sort of consistency.

For example, if the default behavior of most of the toggles in a system is toggle it, we’ll push hard to make the case for all of them. I’ve been knee-deep in JATS for years — that’s the tag set I swim in these days. (Well, some days it has felt more like I was more chin-deep than knee-deep, but that’s another story.) JATS has several elements that have a @toggle attribute with the possible values yes/ and no: <bold>, <italic>, <monospace>, <overline>, <roman>, <sans-serif>, <sc> (small caps), <strike>, <styled-content>, and <underline>. For most of them, this is an optional attribute, meaning the designers of the tag set are telling people who tag documents that they are not required to provide guidance on this and if they do not, they are trusting that strangers, possibly far away and far into the future, will do something appropriate. They’re trusting the good sense of strangers. For two elements, JATS provides a default and not the same default. For <italic>, the default is yes, and for <roman>, the default is no. Many people have told us, often in no uncertain terms and not always politely, that this is terrible markup design. And my inner markup geek agrees with the complaint. However, it conforms to the way real people with experience in publishing expect things to work. They expect that if a word is italic in the context in which it typically appears, if its context becomes italic, the word will stop being italic so that you can still see it — so it still stands out. If a ship name is typically italic, but it is in a caption that is italic, the ship name should not be italic. On the other hand, if you want to talk about something being S-shaped, you want that S to be displayed as sans-serif, no matter what the context; otherwise, it isn’t S-shaped anymore. The world is not consistent. We’re not going to change that. We need to live with the world as it is, not try to remake it according to the principles of good markup design.

There was a time when XML was new and shiny, and some of us hoped (and some of us assumed) that XML was going to become as fundamental to the computing environment as driving is to my physical world. Some of us spend a substantial amount of energy bemoaning the failure of XML or the foolishness of people who failed to see the light. Please understand: I have fully bought into the advantages of using declarative markup in many environments and applications. I count myself among the XML cognoscenti and enjoy spending time with my tribe, which is a large part of what Balisage is about, at least for me. I’m sure that at this conference, like most (maybe all) markup-related conferences in the last 20 years, we’re going to hear lamentations about the lack of respect XML and semantic markup, in general, are getting. We’re going to hear about people we believe should be using XML but aren’t. We’re going to hear about projects that would be far better off if they embraced semantic markup. We’ll hear stories about projects that were using XML but inexplicably switched to a proprietary application. We’re going to hear about people abusing other tools instead of using the XML stack. We will be righteously indignant, and it will feel good. We probably won’t say it out loud, but many of us will enjoy feeling superior to those too ignorant to properly embrace XML and related technologies.

It’s a familiar story. I remember a famous rendering tool for SGML documents that was in many ways superior to anything we have now. The fact that the president and the main salesperson for the product started sales pitches by insulting the prospective customers’ current products, technical staff, and management is probably not the only reason the product failed, but it certainly didn’t help.

We understand and appreciate the value of descriptive markup and assume that anyone else — everyone else — should and does. We’re familiar with and comfortable with and, in some cases, fanatic about the power of the XML stack. We know we have tools that will make many people’s work easier and many projects more effective. And we’re frustrated that they’re not using it.

This year at Balisage we will hear about several efforts to get over that barrier. We will talk about ways to get content into and out of XML so that we can use our tools, and the content creators and users can use the tools and techniques they’re familiar with. And we will talk about ways to deploy our tools on their content. Perhaps in future years, we will stop talking about our XML and their content, but I don’t think we’re there yet. Welcome to Balisage.