Note: Editor’s Note
This talk was given in the closing session of Balisage: The Markup Conference 2010.
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?
Yeah. It's, you know, something you learn in the
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. 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
Middle Liddell, and
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
small caps and not much else. And they
knew from the outset that there was more work to be done.
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,
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.
And, of course, unforgettably Allen Renear and Karen Wickett's
examination of fundamental notions of our work [Renear and Wickett 2010], including the
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].
I and just about every designer of Common Lisp and CLOS has had extreme exposure to the MIT/Stanford style of design. The essence of this style can be captured by the phrase the right thing. To such a designer it is important to get all of the following characteristics right:
Simplicity — the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation.
Correctness — the design must be correct in all observable aspects. Incorrectness is simply not allowed.
Consistency — the design must not be inconsistent. A design is allowed to be slightly less simple and less complete to avoid inconsistency. Consistency is as important as correctness.
Completeness — the design must cover as many important situations as is practical. All reasonably expected cases must be covered. Simplicity is not allowed to overly reduce completeness.
And after a little discussion, he describes the other philosophy:
The worse-is-better philosophy is only slightly different:Early Unix and C are examples of the use of this school of design, and I will call the use of this design strategy the New Jersey approach. I have intentionally caricatured the worse-is-better philosophy to convince you that it is obviously a bad philosophy and that the New Jersey approach is a bad approach.
Simplicity — the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.
Correctness — the design must be correct in all observable aspects. It is slightly better to be simple than correct.
Consistency — the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency.
Completeness — the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.
However, I believe that worse-is-better, even in its strawman form, has better survival characteristics than the-right-thing, and that the New Jersey approach when used for software is a better approach than the MIT approach.
Later, he continues the argument:
Now I want to argue that worse-is-better is better. C is a programming language designed for writing Unix, and it was designed using the New Jersey approach. C is therefore a language for which it is easy to write a decent compiler, and it requires the programmer to write text that is easy for the compiler to interpret. Some have called C a fancy assembly language. Both early Unix and C compilers had simple structures, are easy to port, require few machine resources to run, and provide about 50%-80% of what you want from an operating system and programming language.
Half the computers that exist at any point are worse than median (smaller or slower). Unix and C work fine on them. The worse-is-better philosophy means that implementation simplicity has highest priority, which means Unix and C are easy to port on such machines. Therefore, one expects that if the 50% functionality Unix and C support is satisfactory, they will start to appear everywhere. And they have, haven't they?
Unix and C are the ultimate computer viruses.
A further benefit of the worse-is-better philosophy is that the programmer is conditioned to sacrifice some safety, convenience, and hassle to get good performance and modest resource use. Programs written using the New Jersey approach will work well both in small machines and large ones, and the code will be portable because it is written on top of a virus.
It is important to remember that the initial virus has to be basically good. If so, the viral spread is assured as long as it is portable. Once the virus has spread, there will be pressure to improve it, possibly by increasing its functionality closer to 90%, but users have already been conditioned to accept worse than the right thing. Therefore, the worse-is-better software first will gain acceptance, second will condition its users to expect less, and third will be improved to a point that is almost the right thing. In concrete terms, even though Lisp compilers in 1987 were about as good as C compilers, there are many more compiler experts who want to make C compilers better than want to make Lisp compilers better.
The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++.
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
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].
both important; they are both worth supporting. And technology that
allows us to support both ways of looking at things is well worth
David Birnbaum, of course, has elevated double vision and doubt about
the right point of view almost to a principle of
art [Birnbaum 2010],
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
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,
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
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
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
with others ribbon.
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
Zholudev [Zholudev 2010]
on versioning support and the conceptual underpinnings of
versioning in XML.
And, of course, the panel on
Wheels [Harvey 2010]
also stressed the social context of
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.
[Bański 2010] Bański, Piotr. Proceedings of Balisage: The Markup Conference 2010. Balisage Series on Markup Technologies, vol. 5 (2010). doi:10.4242/BalisageVol5.Banski01.
[Barabucci et al. 2010] Barabucci, Gioele, Luca Cervone, Angelo Di Iorio, Monica Palmirani, Silvio Peroni and Fabio Vitali. Proceedings of Balisage: The Markup Conference 2010. Balisage Series on Markup Technologies, vol. 5 (2010). doi:10.4242/BalisageVol5.Barabucci01.
[Beck 2010] Beck, Jeff. Proceedings of the International Symposium on XML for the Long Haul: Issues in the Long-term Preservation of XML. Balisage Series on Markup Technologies, vol. 6 (2010). doi:10.4242/BalisageVol6.Beck01.
[Becker and Beck 2010] Becker, Abraham, and Jeff Beck. Proceedings of Balisage: The Markup Conference 2010. Balisage Series on Markup Technologies, vol. 5 (2010). doi:10.4242/BalisageVol5.Becker01.
[Birnbaum 2010] Birnbaum, David J. Proceedings of Balisage: The Markup Conference 2010. Balisage Series on Markup Technologies, vol. 5 (2010). doi:10.4242/BalisageVol5.Birnbaum01.
[Blažević 2010] Blažević, Mario. Proceedings of Balisage: The Markup Conference 2010. Balisage Series on Markup Technologies, vol. 5 (2010). doi:10.4242/BalisageVol5.Blazevic01.
[Briquet, Renders, and Petitjean 2010] Briquet, Cyril, Pascale Renders and Etienne Petitjean. Proceedings of Balisage: The Markup Conference 2010. Balisage Series on Markup Technologies, vol. 5 (2010). doi:10.4242/BalisageVol5.Briquet01.
[Candillon 2010] Candillon, William, Matthias Brantner and Dennis Knochenwefel. Proceedings of Balisage: The Markup Conference 2010. Balisage Series on Markup Technologies, vol. 5 (2010). doi:10.4242/BalisageVol5.Candillon01.
[Cayless and Soroka 2010] Cayless, Hugh A., and Adam Soroka. Proceedings of Balisage: The Markup Conference 2010. Balisage Series on Markup Technologies, vol. 5 (2010). doi:10.4242/BalisageVol5.Cayless01.
[Dombrowski and Dombrowski 2010] Dombrowski, Andrew, and Quinn Dombrowski. Proceedings of the International Symposium on XML for the Long Haul: Issues in the Long-term Preservation of XML. Balisage Series on Markup Technologies, vol. 6 (2010). doi:10.4242/BalisageVol6.Dombrowski01.
[Freese 2010] Freese, Eric. Proceedings of Balisage: The Markup Conference 2010. Balisage Series on Markup Technologies, vol. 5 (2010). doi:10.4242/BalisageVol5.Freese01.
[Georges 2010] Georges, Florent.
The EXPath Packaging System: A framework to package libraries and applications for core XML technologies. Presented at Balisage: The Markup Conference 2010, Montréal, Canada, August 3 - 6, 2010. In Proceedings of Balisage: The Markup Conference 2010. Balisage Series on Markup Technologies, vol. 5 (2010). doi:10.4242/BalisageVol5.Georges01.
[Harvey 2010] Harvey, Betty, David A. Lee, Steven Newcomb, Kenneth Sall and Priscilla Walmsley. Proceedings of Balisage: The Markup Conference 2010. Balisage Series on Markup Technologies, vol. 5 (2010). doi:10.4242/BalisageVol5.Panel01.
[Haupt and Stührenberg 2010] Haupt, Stefanie, and Maik Stührenberg. Proceedings of Balisage: The Markup Conference 2010. Balisage Series on Markup Technologies, vol. 5 (2010). doi:10.4242/BalisageVol5.Haupt01.
[Hennum 2010] Hennum, Erik.
XHTML Dialects: Interchange over domain vocabularies through upward expansion: With examples of manifesting and validating microformats. Presented at Balisage: The Markup Conference 2010, Montréal, Canada, August 3 - 6, 2010. In Proceedings of Balisage: The Markup Conference 2010. Balisage Series on Markup Technologies, vol. 5 (2010). doi:10.4242/BalisageVol5.Hennum01.
[Holstege 2010] Holstege, Mary. Proceedings of Balisage: The Markup Conference 2010. Balisage Series on Markup Technologies, vol. 5 (2010). doi:10.4242/BalisageVol5.Holstege01.
[Huitfeldt, Marcoux, and Sperberg-McQueen 2010] Huitfeldt, Claus, Yves Marcoux and C. M. Sperberg-McQueen. Proceedings of Balisage: The Markup Conference 2010. Balisage Series on Markup Technologies, vol. 5 (2010). doi:10.4242/BalisageVol5.Huitfeldt01.
[Kay 2010] Kay, Michael. Proceedings of Balisage: The Markup Conference 2010. Balisage Series on Markup Technologies, vol. 5 (2010). doi:10.4242/BalisageVol5.Kay01.
[Lewis and Johnson 2010] Lewis, Amelia A., and Eric E. Johnson. Proceedings of Balisage: The Markup Conference 2010. Balisage Series on Markup Technologies, vol. 5 (2010). doi:10.4242/BalisageVol5.Lewis01.
[Morrissey et al. 2010] Morrissey, Sheila, John Meyer, Sushil Bhattarai, Sachin Kurdikar, Jie Ling, Matthew Stoeffler and Umadevi Thanneeru. Proceedings of the International Symposium on XML for the Long Haul: Issues in the Long-term Preservation of XML. Balisage Series on Markup Technologies, vol. 6 (2010). doi:10.4242/BalisageVol6.Morrissey01.
[Perry 2010] Perry, Walter E.
IPSA RE: A New Model of Data/Document Management, Defined by Identity, Provenance, Structure, Aptitude, Revision and Events. Presented at Balisage: The Markup Conference 2010, Montréal, Canada, August 3 - 6, 2010. In Proceedings of Balisage: The Markup Conference 2010. Balisage Series on Markup Technologies, vol. 5 (2010). doi:10.4242/BalisageVol5.Perry01.
[Pondorf and Witt 2010] Pondorf, Denis, and Andreas Witt.
Freestyle Markup Language: Specification of an intuitive, powerful, polyhierarchical new extensible markup language. Presented at Balisage: The Markup Conference 2010, Montréal, Canada, August 3 - 6, 2010. In Proceedings of Balisage: The Markup Conference 2010. Balisage Series on Markup Technologies, vol. 5 (2010). doi:10.4242/BalisageVol5.Pondorf01.
[Portier and Calabretto 2010] Portier, Pierre-Édouard, and Sylvie Calabretto. Proceedings of Balisage: The Markup Conference 2010. Balisage Series on Markup Technologies, vol. 5 (2010). doi:10.4242/BalisageVol5.Portier01.
[Price 2010] Price, Lynne A. Proceedings of Balisage: The Markup Conference 2010. Balisage Series on Markup Technologies, vol. 5 (2010). doi:10.4242/BalisageVol5.Price01.
[Probst 2010] Probst, Martin. Proceedings of Balisage: The Markup Conference 2010. Balisage Series on Markup Technologies, vol. 5 (2010). doi:10.4242/BalisageVol5.Probst01.
[Renear and Wickett 2010] Renear, Allen H., and Karen M. Wickett. Proceedings of Balisage: The Markup Conference 2010. Balisage Series on Markup Technologies, vol. 5 (2010). doi:10.4242/BalisageVol5.Renear01.
[Rennau 2010] Rennau, Hans-Jürgen. Proceedings of Balisage: The Markup Conference 2010. Balisage Series on Markup Technologies, vol. 5 (2010). doi:10.4242/BalisageVol5.Rennau01.
[Stührenberg and Wurm 2010] Stührenberg, Maik, and Christian Wurm.
Refining the Taxonomy of XML Schema Languages. A new Approach for Categorizing XML Schema Languages in Terms of Processing Complexity.. Presented at Balisage: The Markup Conference 2010, Montréal, Canada, August 3 - 6, 2010. In Proceedings of Balisage: The Markup Conference 2010. Balisage Series on Markup Technologies, vol. 5 (2010). doi:10.4242/BalisageVol5.Stuhrenberg01.
[Toman 2010] Toman, Vojtěch. Proceedings of Balisage: The Markup Conference 2010. Balisage Series on Markup Technologies, vol. 5 (2010). doi:10.4242/BalisageVol5.Toman01.
[Vion-Dury 2010] Vion-Dury, Jean-Yves. Proceedings of Balisage: The Markup Conference 2010. Balisage Series on Markup Technologies, vol. 5 (2010). doi:10.4242/BalisageVol5.Vion-Dury01.
[Wickett 2010] Wickett, Karen M.
Discourse situations and markup interoperability: An application of situation semantics to descriptive metadata. Presented at Balisage: The Markup Conference 2010, Montréal, Canada, August 3 - 6, 2010. In Proceedings of Balisage: The Markup Conference 2010. Balisage Series on Markup Technologies, vol. 5 (2010). doi:10.4242/BalisageVol5.Wickett01.
[Wiecha, Akolkar, and Spyker 2010] Wiecha, Charlie, Rahul Akolkar and Andrew Spyker. Proceedings of Balisage: The Markup Conference 2010. Balisage Series on Markup Technologies, vol. 5 (2010). doi:10.4242/BalisageVol5.Wiecha01.
[Wrightson 2010] Wrightson, Ann. Proceedings of Balisage: The Markup Conference 2010. Balisage Series on Markup Technologies, vol. 5 (2010). doi:10.4242/BalisageVol5.Wrightson01.
[Zholudev 2010] Zholudev, Vyacheslav, and Michael Kohlhase. Proceedings of Balisage: The Markup Conference 2010. Balisage Series on Markup Technologies, vol. 5 (2010). doi:10.4242/BalisageVol5.Zholudev01.
 I heard this story in a talk by Greg Crane some years ago; I have quite possibly garbled some aspects of it in my memory, and I confess that I've made no attempt whatever to check the details.
 This is the kind of mistake a
non-classicist will make, when trying to tell a classicist joke. I
was reminded, immediately after the conference ended, that they are
Great Scott. Sorry about
 The reference is to an impromptu evening session organized by Ann Wrightson on the topic Markup semantics — what are the questions?
 Remember, this is 1991. -CMSMcQ
 It should be explained here
that during the conference, ribbons with a variety of messages were sold
to raise funds for the student scholarship program. Some of them
bore the text
Plays well with others.