Rough transcript and notes, as delivered at Balisage 2013, August 6, 2013. Paper at http://balisage.net/Proceedings/vol10/html/StLaurent01/BalisageVol10-StLaurent01.html

1. The Allure of#Gothic Markup
Simon St.Laurent
DISCLAIMER
[READ DISCLAIMER in auctioneer voice]
O Reilly doesn t just allow these kinds of wanderings, but encourages them.
If you don t have an employer that lets you talk, especially if you have one
that won t let you talk about what you do, look for better employers. We can
improve the world this way.
Ten Years Ago
Ten years ago I stood here, and I opened with 2001: A Space Odyssey and the
invention of markup. But quickly, matters devolved. This is XML Schema parts I
and II. The hazmat crew is out removing the black sludge it has left on our
beautiful markup. At the time I was reasonably sure I had outline the problems
with schema but I didn t really have a compelling solution. I suggested that
we take a break, and focus on markup syntax, thinking about how people actually
interact with markup as markup. It was fun; it gave me something to do for a
while. But it didn t really catch on. It turns out the power of markup is
not so much the syntax. So what is the power of markup?
Montreal
We re also in Montreal. In addition to multiple pronunciations of my name, we
have this classic form of architecture stuck next to insane office building.
Architectural geologists theorize that tectonic disturbances hurled parts of
Quebec City and Toronto into Montreal. Somehow in the resulting collision much
of the stock market moved to Toronto.
As you walk around, it s hard not to be struck by contrasts. Montreal is just
contrast after contrast   part of why it s an exciting place.
St. Leonard Cohen de Montreal
Montreal also gave us Leonard Cohen. Cohen gives us the equivalent of what
Tommie [Usdin] said NOT to say:  This is the dumbest thing I ve ever
heard. 
This is what I expect the response will be to a lot of this talk. I am calling
for repentance. Even my own biography was repenting some of my books. The
usual response when you issue a call for repentance is for people to say  I
don t think that applies to me. I m a good person. I have corners of my
life that aren t afflicted by what you re describing. 
I would encourage you to track down The Future and check out the rest of
Cohen s message, though I will warn you that it needs one of those little
parental advisory stickers, and was the theme song for Natural Born Killers as
well.
We Are Fallen Creatures
This is the inside of that beautiful Minster I showed you. As you tour
buildings, you get a sense of your place in them, and your place outside of

2. them. It s hard to describe the effect this building has without actually
going there, but you can see this tracery on the top. It invites us to become
involved with it, to become involved with the building in a way that is about
more than  this is the structure of the building, and it s all about form!
 
Don t: Politics and Morality of Tech
One of the worst things you can do at a technical conference   there are the
usual rules about not talking about politics, religion, and morality. We like
this it s because there are diverse opinions and everyone thinks they have
better opinions. There can be strange surprises, as people s views don t
match what you d expected. But there s a deeper reason that we don t
talk, especially about the politics and morality of technology.
[Daunting scale
Distribution
Concurrency]
The Problems Lie Deep
The problems are deep   there is an entire mountain of technology that we take
for granted that rests on top of our most fundamental mistakes.
We Are Complicit   I Am Complicit
We are complicit in these mistakes. By writing books on XML, by writing books
on programming, I have encouraged them. To take a more surface example, I
recently became the chair of O Reilly s open source conference. I m
pretty certain that the NSA is smart enough not to use any of the open source
code that I ve actually published. I don t feel that by posting libraries
that kinda sorta fix Erlang string handling I ve done much to support their
activities. As the chair of the Open Source Conference, I know they re
attending, I know they re talking with people, and using open source as a key
component of their development process.
So what is my level of being attached to this?
Again, while we think we are all good people, we are doing good work, there are
corners that are very hard to talk about.
What has Gothic to do with markup?
Morality. Markup? What am I talking about with Gothic?
Gothic has about 100,000 meanings. If you want to talk about a word that has
been semantically obliterated, Gothic is a good choice. There is an excellent
The Gothic: A Very Short Introduction
(http://ukcatalogue.oup.com/product/9780199586790.do). It s about 120 pages
saying  it changes .
By Gothic I mean basically what comes out of John Ruskin and William Morris
looking back on Gothic architecture. I m not wearing all black, and I m not
talking about Gothic as currently used in typefaces.
Ruskin & The Nature of Gothic
So John Ruskin, who defines himself in the same book as both  a violent Tory
of the old school  and  the reddest of the red , sort of meaning both, was

3. someone who began in art and architectures. Modern Painters is a classic of
Victorian prose. I ll let you decide if it s beautiful or overwrought
yourself. In the Stones of Venice, he described the progression of buildings
and architectural styles. He realized that the buildings that were frequently
dismissed   after the Renaissance   were by far the most compelling. He s
looking at the transition from Byzantine to Gothic, and it turns into something
more than a discussion of stone and archways.
Savageness
Ruskin finds values in the Gothic. I left this out of the original paper but
was told by Mark Bernstein that it absolutely positively had to be there, and he
was right. Ruskin starts with savageness. We think of the Goths, and we think
of barbarians. When you look at Gothic architecture, you see gargoyles, devils,
strange ideas that someone inscribed on the side of a building. It s easy for
people who think the world should be organized in classic orders to dismiss them
as accidents of a deranged mind. However, they are compelling in and of their
own. They reflect an individuality of the craftsmen, they bring us much closer
to the people who created the buildings than abstract form can.
[From Ruskin:
...go forth again to gaze upon the old cathedral front, where you have smiled so
often at the fantastic ignorance of the old sculptors: examine once more those
ugly goblins, and formless monsters, and stern statues, anatomiless and rigid;
but do not mock at them, for they are signs of the life and liberty of every
workman who struck the stone; a freedom of thought, and rank in scale of being,
such as no laws, no charters, no charities can secure; but which it must be the
first aim of all Europe at this day to regain for her children.
Let me not be thought to speak wildly or extravagantly. It is verily this
degradation of the operative into a machine, which, more than any other evil of
the times, is leading the mass of the nations everywhere into vain, incoherent,
destructive struggling for a freedom of which they cannot explain the nature to
themselves....]
Changefulness
Changefulness is where I started. I actually have a friend who named his company
Changeful   a brilliant re-appropriation of Ruskin.
This is not the best illustration, but you ll notice that there s variation.
Even when there is a clearly-defined form, even when the form is reused, there
is change from item to item. If you have the time to go explore a cathedral and
examine the many variations inside, things that looked the same from a distance,
you will marvel. It s not just about time. Some of these things were done at
the same time. Builders allowed variation, expecting things to move. You
don t come up with a plan for a cathedral and say  this is the way it s
going to be  and expect it to magically appear over the next hundred years of
stone carving.
[From Ruskin:
We have now to consider what reward we obtain for the performance of this duty,
namely, the perpetual variety of every feature of the building.
Wherever the workman is utterly enslaved, the parts of the building must of
course be absolutely like each other; for the perfection of his execution can
only be reached by exercising him in doing one thing, and giving him nothing
else to do. The degree in which the workman is degraded may be thus known at a
glance, by observing whether the several parts of the building are similar or
not; and if, as in Greek work, all the capitals are alike, and all the mouldings
unvaried, then the degradation is complete; if, as in Egyptian or Ninevite work,
though the manner of executing certain figures is always the same, the order of

4. design is perpetually varied, the degradation less total; if, as in Gothic work,
there is perpetual change both in design and execution, the workman must have
been altogether set free....]
William Morris
William Morris takes the intricacy a little bit further. Morris was writing in
the late Victorian period. You can read Charles Dickens for the social effects
of the Victorian age, but Morris remained optimistic. He made it clear that it
was possible for us to rejoice in our work. There had been times when we did do
that, instead of taking the joy out of work by mechanizing everything in sight
without regard to the worker. I like his last bit:  all but the worthless
must toil in pain.  The people who were gaining the enjoyment were not people
he was very fond of.
Christopher Alexander
During an XML show in Philadelphia, I was very excited to find the American
Institute of Architects  bookstore nearby. I ran over there and I splurged on
Christopher Alexander s A Pattern Language and The Timeless Way of Building
and they had several of them. I brought them over to the cash register and she
said  You must be be a programmer!   What gave me away? I m not
wearing a badge, I m not…   Only programmers buy that. Architects
don t do this stuff. That s just for programmers. 
A lot of programmers know Alexander through Design Patterns, the  Gang of
Four  book. If you know Alexander through that book, start again. I cite in
my paper a talk he gave to the IEEE that clarifies some of it. To say that they
got it backwards would be an understatement.
A Pattern Language is this amazing book where you can go through and see
different parts of architecture and how they work at all kinds of scales. The
Timeless Way of Building explains how they figured out these things, how they
got to  these are the right patterns. 
More recently, he s been writing a little more polemically, because as he took
his theory to the real world, he found himself battling against not just bad
architecture   that happens   but against the very system by which
architects operate. These two books [are actually in the social room downstairs
- if you have a chance take a look.] in addition to being beautiful, they have
a lot to tell us.
System-A and System-B
After 40 years of fighting, Alexander creates this distinction. I know a lot of
people hate dichotomies, but this one in actually pretty telling. System A is
what Alexander wants to do, while System B is what we actually do. System-A is
iterative, with drawings coming after facts on the ground. There is a tight
communications loop between client and builder   the client is always in it.
The plan is in continuous development. You build the large features and only
then decide on the details of the small features. This allows that strange
serendipity thing to work in your builds. You drop features, if you need to, to
do cost control at the end. I think everyone realizes that when you build
something there are usually overruns. You control your costs by customizing
your buildings to fit their situation tightly.
This is not the way that  normal  architects work. Drawings come before,
there s a separate designer and contractor, everything possible is done to
keep the customer off the site, you draw as much as you can at the beginning.
Costs are controlled as much as possible by standardization. There s a
wonderful passage in Alexander where he talks about the damage that standard

5. size electrical boxes have done to our buildings, because we plan around them.
This has made for layer after layer of standardization replicating itself.
Depth, Not Quantity
Alexander proposes changing the model of work. Instead of an architect who can
design a hundred buildings in a year (or a contractor who can build thousands
based on a small set of plans) they become an architect-building, who works on
say 20. There is a much tighter focus on the details of the work, and much less
interest in scale. Scaling up is part of the problem, which is something
that s really hard to tell technologists.
But what has this to do with markup?
Markup, houses, what?
[Even Christopher Alexander s website shows little evidence of interest in
markup detail!]
Markup as Architecture
Markup is our architecture. We live in markup. The people in this room
probably excessively live in markup and we should go take a walk outside. That
is why this conference is in Montreal in August.
Markup creates spaces, structures, it gives us places to have fun, and perhaps
most important we assemble these structures into larger groups. It s not
quite the William Gibson vision of cyberspace, with its geometric columns for
databases and such, but there could be an amazing visualization of the XML work
done to date if we wanted to view it as a city.
XML as Industrialized Data
There s a problem, though. We ve build all of this on the industrial model.
XML has become something that is about automation, about touching the
information as little as possible. Predictable results are central. We did not
invent that, I grant   predictable results have other sources. When we want
to do versioning, we have all these arguments. Should we change the namespace?
How do we re-label these things? We ve created brittleness that s a lot
like an auto factory where they used to shut down for months at a town to shift
out old model tooling for new model tooling.
Markup, despite being a unique intersection of human and computer, a place where
millions and millions of people actually sully their hands with the characters,
is something generally considered to be avoided.
There is anarchy in XML, which is good for many of this in this room, but we
treat it as an exception. It is something grudingly given, or given for  this
will be filled in at a later date. 
Validation
Validation. For my first few years of XML, I thought it was amazing. You could
have this validation step that would tell us whether we should bother to work
with a document, and then I could just go on happily.
As I got deeper and deeper into projects, I realized that validation wasn t
just about making the consumers of the data happy. It was about setting up
barriers, and setting up lines of blame in systems. Beyond markup, there s

6. now a tool called  git-blame  that lets you look up who changed that line of
code that irks you. The happy story is probably actually less than half the
story.
We Fear That Work Is This
We are afraid of chaos. People do very different jobs, with onlookers passing
through. We know that there are all of these things happening at the same time
  this terrifies us about computers and most of us strive to be the onlookers.
Asynchronicity Works This Way
The reality is that these complicated situations can work, and this is just
normal. If you think back, away from the computer to just human experience…
Here, Christ somehow got a nail In his hand, and you can guess the symbolism.
His mother is asking him to give her a kiss rather than the other way around,
but John the Baptist is bringing water to the room, and Joseph is looking at his
hand. They re working on a door. They are shavings on the ground, lumber in
the background, which in Victorian times created a huge scandal.  How dare
you show the Son of God with wood shavings? 
It is messy, it is complicated. But that works. This is a very human way of
dealing with the world.
Data Transformation Flows
As we step back to markup, looking at transformations. Changefulness to me
reads as transformation. We shift state. XSLT is frequently how we do this. I
only figured out XSLT about five years ago.
This is the most important device in the world for XML people. It s a
Pachinko machine. You send the balls up, and they come down through the slots
in different configurations. If you spend time working in XSLT or in functional
languages you quickly find your brain becomes one of those.
The other thing I wanted to mention here was internal and external structures.
Transformations let you say they don t have to be the same. Sometimes this is
obvious. Sometimes it s not.
Douglas Crockford: JSON and Functional Programming
No one shouted  Satan! . This is good.
Doug extracted JSON from JavaScript   that s part of why the syntax for JSON
is a little odd. He didn t invent anything. The bigger thing that he did was
re-orient JavaScript developers toward this Pachinko mindset. Everything will be
functions and data flowing through. He avoids schemas. The JavaScript folks in
practice, without necessarily realizing it, tend to focus on transformation just
as a fact of life, whether it s a simple transformation or a massive one.
[I ll explain the  don t be evil  license over beer. (But no one
asked.)]
Human Transformers
We are transformation devices, for better or worse. Even reading is a
transformation, when you start looking at how you consume content. Document
creation is an insanely flexible transformation. One things I suggest is that
we need some transformation tools that are more than the decoration that CSS

7. offers us but less even than XSLT 1.0. Something that people can just walk up
to and just take as normal.
A few recent finds
A few things have come up since I put in the paper in July. I m actually much
more optimistic in this talk than I had planned to be because of things that I
keep finding that suggest that people, whether inside or outside of the markup
world, are heading in this direction.
John von Neumann
It turns out that some people were doing this earlier   much earlier. We think
of computers as they very neat on-off switches multiplied by millions of times.
For the early pioneers of computing, this was not reality. They had to spend a
lot of time determining whether something was wrong in their code, or whether
something wacky was happening to a vacuum tube. As a result, they spent a lot of
time contemplating unreliable systems, systems whose reliability was actually
worse than humans. This is a very old problem.
Roger Costello: Fine-Grained Validation
Roger Costello, who s sitting over there, posted something to xml-dev a few
weeks ago that made me feel much better about schemas. That s an achievement
in itself. Instead of the  whole doucment  view that we traditionally do  
and again, there have been ways to get to what failed but it wasn t fun  
Roger is proposing that we do the validation piece by piece, which effectively
turns the validation step into a transformation with usable results without the
barrier being set, without the same kind of scapegoating. You might have many
little scapegoats in your system, but you wouldn t have one giant fail.
Waterfall, Agile, Lean
On the business side   I m always cautious about business models and their
relationship to tech. I found a wonderful description of the change I ve seen
in tech in the last 20 years, from Alistair Croll. I think it applies to
markup.
In the waterfall system, you knew you had a problem, you figured out a solution,
and you implemented it. This is the classic  Architect looks at problem,
figures out solution, we build it. 
Agile   which we ve all been talking about for the last ten years until
we ve forgotten what it really means   is where you know you have a problem,
but you iterate over solutions. You don t have one design and one build
process.
These days, we have people, not all of them in Silicon Valley, talking about
lean models, where you don t even know what the problem is. You come up with
possible problems, you test various solutions, you develop a minimum viable
project, and go from there. One of the things that I love about these, is that
as they ve been implementing and testing these, they ve been more willing to
include people, not just customers, in these. You pass data to a person who
then makes a phone call and fixes something. It turns out to be a lot cheaper
to hire a person to make a phone call than to architect an entire system and
distribute it on the cloud. At least up to a certain scaling point, which you
may never reach.
The Importance of Wheedling

8. When I was coming into Canada, filling out the forms, I noticed that they have
these nice little lines to keep your letters separate, and I just didn t fit.
I was wondering if I was going to get flak when I got here. Of course I
didn t - the customs officer looked at it, read it like a human would, and
went  wham! . That was a good  wham! , not a bad  wham! 
You just can t wheedle a machine. They re designed not to do that. Some
fool thought that was a virtue.
So…
Emphasize Markup
We have a unique opportunity   not entirely unique but a very strong
opportunity with markup in that it has this direct connection between people and
information.
Programmers marvel that one of the goals of XML was that humans could approach
it. It doesn t seem right from a programmer perspective. You create the data
through the code, and you interact with it through the code, and the code is
central, and the data is this thing that you wrap in methods.
I keep   this is just as true of web stuff as it is of XML stuff   you can
shift the programming to be secondary rather than primary. Transformation can
be critical but the programming part of it isn t as central. You can do
transformations different ways. We can do things that are as simple as just
declaring that  this X is a Y thing  and it has tremendous power. Any of
you who are looking at the web right now   this [in CSS] is doing huge amounts
of work for you and huge amounts of work for the people building those sites.
The Promised Land
[That came out terrible on the projector! I m sorry! The promised land is
supposed to be bright and sunny, not foggy and dismal.]
I put this up because it is very deliberately bucolic. It s not downtown
Montreal, it s absolutely not downtown Toronto or New York. There are people
who want to live there. There are people who want to live in factories. I
don t understand everyone.
[Original notes:
Clean Code
Flexible Code
Scalable Code
Superpowers
Concurrency
Integration
Provability]
The Journey: Setting Out
We re setting out on a strange journey. These things that I speak of, of
different interactions between humans and computers, this model of
transformations   I ve been told that I was looking for the Holy Grail.
Welcoming: Entry Points

9. We need to change the way that we approach this conversation. Even XML was
daunting to a lot of people. I think part of the reason that it wound up a
programmer-centric community for a while was just that even as it attempted to
be accessible to humans, the conversation frequently wasn t. There s one
big problem with Balisage and with the markup community in general, and with
James Clark especially: and that s that we re too damn smart. We need to
work on these entry points.
[Ease the gap between  programmers  and  end users .]
Welcoming, Not Overwhelming
And be welcoming, not completely  welcome to our world, you will be one of us
now. You will learn out machines and our ways. 
Teaching: Get Them First!
Get to people early. This is my 3-year-old with a rasp. This may be a little
too early   I m not sure   but thing that I wanted to emphasize is this
direct tactile contact of rasp and basswood. He s transforming that. He s
doing a transformation. Now I know that isn t connected directly to a
computer itself, except through a camera, but that model of creation is
something we have to integrate back into our technical world or we will just be
lost.
Designing for Approachability
We build these wonderful things, frequently   well, I d like to say that
people who build editors are different, but frequently they re not different
enough. People build these things expecting familiarity with computers, tech,
and especially programming. It s time to get past that. I marvel that the
web tools in particular are still as crappy as they are because they reach
millions of people who complain about them daily. We still somehow haven t
moved beyond that.
Experts have a hard time conceiving of the needs and interests of non-experts,
much less valuing them.
Maximum Welcome
We need to achieve maximum welcome. We need to say  you are savage. Life
changes. We accept that into our system. We recognize the value of what humans
create and not just this neat array of bits that we ve been talking about for
the last sixty years. Thank you. 

10. We need to change the way that we approach this conversation. Even XML was
daunting to a lot of people. I think part of the reason that it wound up a
programmer-centric community for a while was just that even as it attempted to
be accessible to humans, the conversation frequently wasn t. There s one
big problem with Balisage and with the markup community in general, and with
James Clark especially: and that s that we re too damn smart. We need to
work on these entry points.
[Ease the gap between  programmers  and  end users .]
Welcoming, Not Overwhelming
And be welcoming, not completely  welcome to our world, you will be one of us
now. You will learn out machines and our ways. 
Teaching: Get Them First!
Get to people early. This is my 3-year-old with a rasp. This may be a little
too early   I m not sure   but thing that I wanted to emphasize is this
direct tactile contact of rasp and basswood. He s transforming that. He s
doing a transformation. Now I know that isn t connected directly to a
computer itself, except through a camera, but that model of creation is
something we have to integrate back into our technical world or we will just be
lost.
Designing for Approachability
We build these wonderful things, frequently   well, I d like to say that
people who build editors are different, but frequently they re not different
enough. People build these things expecting familiarity with computers, tech,
and especially programming. It s time to get past that. I marvel that the
web tools in particular are still as crappy as they are because they reach
millions of people who complain about them daily. We still somehow haven t
moved beyond that.
Experts have a hard time conceiving of the needs and interests of non-experts,
much less valuing them.
Maximum Welcome
We need to achieve maximum welcome. We need to say  you are savage. Life
changes. We accept that into our system. We recognize the value of what humans
create and not just this neat array of bits that we ve been talking about for
the last sixty years. Thank you.