Balisage Paper: Stone soup

Like most folktales, the story of Stone Soup circulates in a variety of forms. Some of you will have heard it in one form, some in another; some of you may never have heard it or not recognize it under this name. For those of you keeping score at home, you will want to know this is number 1548 in the Aarne-Thompson system of folktale classification. The version of the story that I have in mind goes something like this.

It's the end of a long war. Three destitute soldiers are making their way through a war-ravaged landscape, trying to get home, struggling against hunger and fatigue and suspicious villagers. They are benighted in a remote place, and they find a village as it is getting late afternoon or early evening, and they knock on a door and ask for food. The master of the house tells them, No, we don't have enough food to share with anybody, and slams the door in their faces.

They go to the next house, same story. They go through all the houses in the village; no one has enough food to be willing to share with strangers. So they go to the central place of the village, and they pull out a pot, and they go out to the nearby forest, and they gather some wood, and they make a fire. And one of them comes in, bringing a large stone, and he puts it in the pot. And they go out to the stream, and they draw water, and they fill the pot with water, and they start making the motions of cooking.

The villagers are of course watching them from behind curtains and shutters, and eventually one of the villagers goes out and asks them what they're doing. And they say, Well, we're making stone soup. You know, it's not ideal soup, but it's good to have when three is nothing else to be had. Actually, sometimes it tastes pretty good, although at the moment this one could use some more salt.

And the villager says, You make stone soup?

They say, Yeah. It's, you know, something you learn in the army.

And he's curious enough that he says, Well, I have some salt. So he gives them some salt, and they salt the water, and they say, Yeah, that's better.

And a few more minutes go by, and they explain that this takes a while. And then one of them pronounces, Oh, gosh, it would be nice to have some pepper.

Well, the first villager doesn't have any pepper, but he has a neighbor who does, and he goes and fetches that neighbor, and they add the pepper. And you can ... of course, the storyteller can spin this next bit out indefinitely. Since some of you have planes to catch, I won't. I'll just — you can imagine some onions, some leeks or chives, maybe some carrots, some meal — some oatmeal or flour — to thicken, potatoes, eventually some beef, and by the end of the, by the end of a certain amount of time all of the villagers are out cooking soup together and having a wonderful evening because when they share, they do have enough.

Now, it seems to me that this story of stone soup may illuminate our situation possibly in more than one way. Most obviously, of course, it describes a situation of limited resources, of reduced circumstances which may feel familiar to a lot of people from the last couple of years, given the situation of the world economy and the national economies of the various countries where most of us live. All of you will be aware that there are lot of people who are feeling rather straitened in their circumstances and wondering how to make do with less.

Of course, making do with less, lowering resource consumption, re-using existing resources — that, of course, has been a standard injunction to system designers and implementors for years. Don't re-invent the wheel! Don't waste resources by unnecessary duplication. Re-use. Share.

If there is anyone who ought to feel comfortable in a world of acute attention to careful use of resources, it ought to be people using descriptive markup. The principle of thrift that is embedded in the idea of re-use, the principle of openness embedded in the idea of information sharing, were, after all, the original motives for the development of descriptive markup in the first place as embodied in SGML and later in XML and still later in experimental languages like TexMecs and LMNL and Freestyle Markup Language and so forth. Stone soup could almost be the official folktale of the descriptive markup community.

Now, of course, a lot of things change. But as Eric Freese showed us on the first day [Freese 2010], the idea of re-use — of sharing — in the form of single-source publishing to multiple targets is still alive and well and living today on mobile devices.

But, of course, you don't always have the markup that you would like. In Eric's case, the main problem was he had markup that captured information he wasn't interested in so his first problem was to clear out markup he had no use for. Frequently, of course, we have too little information or the wrong kind of information. Or the title of the video game has been replaced by a digital image, and you have no textual access to it.

Intelligent use of what you have has always been part of the story of descriptive markup. One of my favorite histories in this regard took place a few years ago in the Perseus Project, which is now based at Tufts University.^[1] They got a grant to have the three important dictionaries of ancient Greek — ancient Greek-to-English dictionaries — digitized. The most recent — the most important — editors of the primary dictionary were Liddell and Scott, and there is a large Liddell, and a medium, and a hand copy called naturally Big Liddell, Middle Liddell, and Little Liddell.^[2]

The Perseus Project sent these offshore to be keyboarded, and of course, the keyboardists were not classical philologists, so they were keying in what were to them opaque strings. And the most you can expect in a situation like that is a fairly careful typographic markup. So they get digitized texts of the dictionaries back, but, you know, what you have marked is font shifts and bold and italics and small caps and not much else. And they knew from the outset that there was more work to be done. We have years, they figured, We have years of gradual enrichment in front of us before this can be a really useful digital resource. But, of course, the Perseus Project is not limited to short-term results. They've been around for awhile. They expect to be around awhile, and they are, of course, dealing with data whose average age is a little more than 2,000 years, so they're not impatient people. So, the first thing they did was make a stylesheet so they could display dictionary entries in their browser. Entry boundaries were, of course, marked in the data they had so that was fairly easy; you could look up a word and look at the dictionary entry.

Now, Greg Crane was from an early age known a regex wizard (he's a fanatical user of lex — not yacc, just lex). He noticed, You know, there's an interesting thing here. Arabic numerals occur in exactly two positions in an average article in Greek-English dictionaries. It is either the book and section number of a citation and is immediately followed by Greek characters, or it's a sense number in which case it's immediately followed by a Latin character because glosses are given in English. And armed with this information — most of you could write the appropriate regular expression already — armed with this information, he was able to identify the major sense boundaries in the articles of the dictionary. And as he pointed out, it was at that moment — six weeks after they got the digitized data, not six years — that the digital object became more useful for almost every purpose than the paper object because they could insert blank lines between the senses and it became much easier to get an overview of long and complicated articles. If you have ever studied dead languages with dictionaries built by philologists whose attention to detail is, shall we say, fabled in the academic world, you know that a long dictionary entry may go on for column after column after column and because space is at a premium on the page, there is no typographic marking. You have to pay attention to the numbers. But because space is not at such a premium on the screen — pixels are free in ways that paper is not — they were able to make it visually easier to track the structure of articles. And at that point, almost everybody in the Perseus Project preferred to look up words in the electronic version rather than the paper version because it was easier to use.

One of the reasons I liked the paper by Stefanie Haupt and Maik Stührenberg the other day is that it illustrates the same kind of thing [Haupt and Stührenberg 2010]. It has always been a challenge to find ways to do up-translation, but the key remains the same: Know your data; exploit that knowledge. Knowing that even if the title on the main review has been replaced by an image, you can probably find it by following a link and then looking for the back link, that requires knowledge of data. Exploiting that knowledge makes possible an up-translation that might otherwise have looked impossible. Know your data.

Economic poverty comes in at least two different forms. Some people are poor because they have no choice. But in many cultures, there are those who embrace economic poverty willingly, often for religious or, more generally, spiritual reasons. Here in primarily Catholic Quebec, monasticism comes to mind. Intellectually there seems to be an analogous kind of choice or move made by those who focus their attention on a small number of fundamental objects or questions. And one of the big themes for me of this year's Balisage has definitely been the very prominent thread of focus on fundamentals and on foundations in two rather different flavors; first, there are foundational questions and foundational, intellectual topics. I think here of Mario Mario Blažević's work exploiting the relation of marked-up documents to their underlying document grammars [Blažević 2010], or more abstractly, the work by Maik Stührenberg and Christian Wurm on the expressive power of document grammars [Stührenberg and Wurm 2010] — important work in the service of keeping our intellectual foundations in good order.

Of course, one of the other intellectual foundational questions that has always occupied this conference and its predecessors — the problem of overlap — was also well-represented this year. Piotr Banski's work on stand-off annotation [Bański 2010], and Pondorf and Witt's work on the Freestyle Markup Language [Pondorf and Witt 2010] help to keep that thread of Balisage papers alive.

But most visible in this area of fundamental concepts, I think, are the various papers on this and that aspect of semantics. The work by Quinn and Andrew Dombrowski in the pre-conference's symposium applying Montague semantics to the question of vocabulary choice for institutions that aim at long-term preservation of data [Dombrowski and Dombrowski 2010]. Karen Wickett's work applying situation semantics to markup interpretation [Wickett 2010]. The work done by my colleagues, Claus Huitfeldt and Yves Marcoux, on the applicability of Peirce's type/token distinction to markup languages also fits here [Huitfeldt, Marcoux, and Sperberg-McQueen 2010]. Ann Wrightson's persistent effort to place the questions of markup semantics on a firmer foundation, beginning with the natural and not always easy task of identifying, as she tried to do in her nocturne, exactly what the questions are.^[3] And, of course, unforgettably Allen Renear and Karen Wickett's examination of fundamental notions of our work [Renear and Wickett 2010], including the questions What is a document? and Do we really know that documents exist? Outstanding in their patient willingness to follow arguments to their conclusions regardless of how unexpected those conclusions are and regardless of, at least to some of us not yet accustomed to having our heads reorganized in that particular pattern, how disorienting those conclusions may be. That's an important kind of intellectual service.

But there's another kind of foundation that's been, I think, more visible than usual at this year's Balisage. If you wanted to redo the foundations of a lot of our work, you would have to spend time improving the situation of XML processing in our programming language libraries and improving the tools that we use to build applications for our customers, so you might want to have, say, somebody smart working on a better API to tree representations so that you weren't locked in to this or that tree model the moment you wrote an XML application. So you might want exactly what Amelia Lewis and Eric Johnson gave us early in the conference with their work on gXML [Lewis and Johnson 2010]. You might want to be able to build a full XML application as far as possible in the browser, so you would want surely an XProc processor in the browser of, gee, pretty much exactly the kind that Vojtěch Toman presented to us [Toman 2010]; good luck on getting that last 17% done. Cyril Briquet similarly reported on software for making it easier to process large XML-encoded corpora [Briquet, Renders, and Petitjean 2010]. Wendell Piez emerged victorious from the demo jam, demonstrating software using XML-based infrastructure to process and visualize overlap. Mary Holstege's work on schema analytics [Holstege 2010], Martin Probst's discussion of persistent DOMs [Probst 2010] — both of those fit here as does Hugh Cayless' work showing us how to implement the kind of string-range function that we have in many of our vocabularies been assuming and wanting for a long time even though the implementations were not there. Fortunately, we have some hope that when we finally put our foot down in that direction and move forward, Hugh and his colleague will have put some ground underneath it [Cayless and Soroka 2010].

The second aspect of the stone soup story that strikes me though, one is that the soup is like an agile product; it goes through a number of iterations. And the first one really doesn't have a very close resemblance to the last; it starts out as hot water, and it ends up as soup or stew. And the idea of getting something done — getting something out — and iterating again and again and again as many times as it takes is also one that is useful to take to heart. It reminds me, in a way that I'm not sure I fully understand, of Richard Gabriel's distinction between what he calls the do the right thing and the worse is better schools of design. I hate to bore you with stuff you've already heard, so I need a show of hands: How many of you don't know Richard Gabriel's essay which circulates on the web under the title Worse Is Better? Oh, gosh. Now, sorry, just to make sure we have the right polarity, I was asking for the people who don't know it. Okay, well, in that case, I'm going to read you a lengthy quotation from Richard Gabriel; I will not attempt to project it and let you read it silently because you read at different speeds; this way we all end up together. Gabriel is talking about the state of LISP processors; this is 1991. He is talking at a LISP users conference, and he pauses to compare and contrast two different schools of design [Gabriel 1991]. He says:

And after a little discussion, he describes the other philosophy:

Later, he continues the argument:

I don't know about you, but that seems awfully prescient to me. I know some working group chairs who have done their best to make the "worse is better" essay required reading for every member of a working group. Sometimes it works. Sometimes the result is still more complicated than you might like, but I shudder to think what some of the specs I've been involved with would look like if we hadn't made that required reading.

I think the outstanding outstanding illustration of this point in this year's Balisage was given by Michael Kay's presentation of the streaming features in XSLT 2.1 [Kay 2010]. If the XSLT 1.0 working group had tried to put those features into 1.0, we would still be waiting for 1.0 implementations of XSLT. And that development of XSLT seems to me to illustrate very nicely the progress you can make if you start with something relatively small, relatively simple, but basically good, and gradually, incrementally improve it.

Another kind of iteration — iteration, of course, etymologically means just walking around things, so I think of looking at things from multiple points of view as another kind of iteration, and we've had a number of talks here that seem to me excellent examples of the examination of problems or the solution of problems from multiple points of view. I think of Andrew Spyker's presentation about seeing web development from both sides of the glass [Wiecha, Akolkar, and Spyker 2010]. They are both important; they are both worth supporting. And technology that allows us to support both ways of looking at things is well worth working on.

David Birnbaum, of course, has elevated double vision and doubt about the right point of view almost to a principle of art [Birnbaum 2010], although sometimes I confess I do sometimes want to shake him and say, Just make a decision! I think the cultivated hesitation and the insistance on looking for reasons is an intellectual habit we would do well to cultivate.

Some double points of view, of course, are less helpful. One of the take-home messages that I think some people took from Lynne Price's report on DITA [Price 2010] is, of course, that consultants are saying one thing, namely, If you adopt DITA, you are going to need to customize it and then it will bring you all of these advantages, and what their customers are hearing is If you adopt DITA, mumble, mumble, mumble, it will bring you all of these advantages, and the customers are not planning on expending any effort on the customization. That's a kind of double vision that's more problematic, and those who care about the success of DITA, as well as consultants who care about not having their customers come back and say, You promised me this was going to be wonderful, need to find a way to solve that problem.

And, of course, Walter Perry taught us all a new way of thinking about things from different directions [Perry 2010]. Are my XML elements nouns, or are they verbs? Buckminster Fuller asked the same questions about human beings. I think Walter Perry is a verb. And I think the question that he teaches us to ask is a good one.

The third lesson I draw from the stone soup story took me a little bit by surprise because I didn't see it for a long time, but the final product, the soup that everyone enjoys, is not created by the three soldiers and not by the villagers working alone or individually, but by everyone working together. The stone doesn't create it either; it catalyzes it, together with the story told by the soldiers. There is an object lesson there perhaps in the catalytic effects of the right narrative, but also an object lesson in the importance of the social context. Working collaboratively is difficult. But there are advantages we can achieve, if we manage to overcome our aversion to the risks inherent in collaboration and to the risks involved in coming out of our separate houses. Florent Georges' report on EXPath make me optimistic about the XML community as a community [Georges 2010]; that's a socially-organized and socially-supported project. I wish it all success. Pierre-Édouard Portier's report on the social development and adoption of annotation vocabularies similarly [Portier and Calabretto 2010]. And — outstanding example! — Gioele Barabucci's talk about the excellent work done by that large team in Bologna on a shared vocabulary and on an ecology of software and processing expectations in the notoriously difficult domain of legal and legislative information [Barabucci et al. 2010].

On a software level, I think, the social context is also important. And in this connection, I think of Hans-Jurgen Rennau's paper [Rennau 2010], which I think of as attempting to find a way to allow XML and XML languages to play well with others, namely, with the general purpose languages that many programmers prefer to use at least for some processes. And Erik Hennum similarly on how to let XHTML dialects play well together [Hennum 2010]. I don't know where the plays well with others ribbons ended up, but we really should all strive to deserve to wear a plays well with others ribbon.^[5]

And one aspect of working with XML in a social context is, of course, that things change and you need versioning support, so I was interested in the papers today by Jean-Yves Vion-Dury [Vion-Dury 2010] and Vyacheslav Zholudev [Zholudev 2010] on versioning support and the conceptual underpinnings of versioning in XML. And, of course, the panel on Greasing the Wheels [Harvey 2010] also stressed the social context of XML. And long-term preservation of XML requires social commitment, and one of the most impressive things for me in the pre-conference symposium were the reports from PubMed Central and Portico that show, by God, there are social institutions that are taking on that task and are doing the right thing [Beck 2010], [Morrissey et al. 2010]. I wish there were more, and I wish the coverage were broader, but it's not an impossible task. It just requires commitment and organization and hard work and probably some money along the way, but that's by the by. And directly connected with that, but pointing back to the fundamental questions with which we began, recall the paper on XML essence testing in which Abraham Becker and Jeff Beck showed us that asking what things are in essence, which looks awfully theoretical and foundational in many respects, can have important practical implications for database management or data management [Becker and Beck 2010].

How to use technology in applications is in some sense a purely intellectual and technical question, but it's also a social question. How do we propogate the relevant knowledge and ensure that it's accessible to the developers who need it? And it's here that design patterns seem to me to fit together with the talks that we've just heard this morning from William Candillon and his colleagues on XQuery design patterns [Candillon 2010], and from Ann Wrightson [Wrightson 2010] on the implications for XML vocabulary design of the shift in processor architectures that's taking place under our feet. (Implications which may or may not apply; see previous discussion.)

So the story of stone soup seems to me to illustrate three lessons we can usefully keep in mind. Make the most of what you have. Second, iterate. Start simple and then keep trying; don't let the best be the enemy of the good. But also and contrarily — this is the way proverbs always are — prepare for future growth; prepare for change. Try to avoid getting locked into a particular technology or version of your technology forever for backward compatibility reasons, i.e., don't let the good be the enemy of the best. Work for a path where you can get the good now and get the best, or at least better, later. Third, work together. The kind of information we want to collect, manage, and preserve is for the most part social, organizational, and cultural information. Even when it's purely scientific data, even when it's the mass spectrometer data, the reason that we want it and the way that we exploit it are given partly by our cultural organizations. It arises from and has meaning primarily, or exclusively in some cases, in the social context; don't leave that social context out of account.

One way to make the most of what you have, of course, is to learn by talking to other people and by attending conferences like, for instance, Balisage. One way to iterate is to do so on a schedule, to do things again and again at regular intervals like, for example, annually, like Balisage. One way to remember the social context is to remember that you are part of it and to make yourself actively a part of it, for example, by gathering together with people with whom you share interests, for example, at Balisage. So, one moral of the stone soup story is attend Balisage in Montreal! Of course, you already knew that. Some of the best stories remind us of things we already know. Now, on Monday or Tuesday I remember standing up here and saying how glad I was to see so many unfamiliar faces in the audience, and I'm equally happy today to see how many of those faces have become familiar, now representing friends I hope to see at future occurrences of this conference. Some of them I haven't managed to talk to as much as I would like, which just means you also have to come back next year so we can try again. Thank you for coming to Balisage, and I hope to see you next year and in years future at Balisage.