Alligator Design
Notes
Propose a project

The promise of XML

The mark-up language XML promised that anything written once could be published anywhere. It kept that promise for people who had an anywhere. For a website that only ever published to itself, it was mostly a second language to look after.

Geert Valère AllegaertOctober 2026

XML documents should be human-legible and reasonably clear.

W3C, design goals of XML 1.0, 1998

Around 2000 I worked alongside an agency that built a corporate website the way the best people were talking about at the time. Not one page of it was written in HTML. Every text was stored in XML, in a structure the agency had designed, and turned into web pages by a transformation that ran on the server. The content was clean, separated from its presentation, ready to go anywhere.

It never went anywhere. The company published to its website and nowhere else. What it had gained was a source that needed dedicated tools to be read and maintained, and a structure that had to be extended every time somebody wanted a page that did not fit it. The promise was real. It just did not apply.

Where the promise came from

The idea did not start on the web. It came from technical documentation, where it had been true for years. A manual for a printer or a piece of software had to appear as a printed book, as online help, later as web pages, often in several languages. Writing it three times was expensive and the three versions drifted apart. So the text was written once, in a structured format that said what each part was rather than what it looked like, and each output was generated from it. The standard for that was SGML. It looks like the stone age now, but almost everything in this note descends from it.

The stone age of markup

Even the word comes from paper. Before computers, a copy editor marked up a typescript by hand: instructions in the margin telling the typesetter which typeface, which size, how much space. The markup was the pencil; the text was something else.

The decisive step was to stop telling the typesetter how something should look and say what it was. In September 1967, at a meeting at the Canadian Government Printing Office, William Tunnicliffe of the Graphic Communications Association spoke about separating the content of a document from its format. The people who took it up called it generic coding: a tag that says heading, not one that says format seventeen.

Two years later, at IBM, Charles Goldfarb, Edward Mosher and Raymond Lorie made it work. They were on a project for law offices, where one document had to be edited, formatted and searched by three different programs, and they needed a way for all three to share it. They called the result GML, the Generalized Markup Language, which are also, not by accident, their three initials. What GML added to the idea was a rule: a kind of document has a declared structure, with its parts nested inside each other. IBM wrote its own manuals in it.

After fifteen years of committee work GML became SGML, the Standard Generalized Markup Language, published as ISO 8879 in October 1986. The final text was produced with an SGML system written at CERN, the laboratory where a few years later Tim Berners-Lee would need a markup language of his own. SGML was not a language for writing documents but for defining them: a document type definition, the DTD, declared which parts a document could have and in which order. The American defence department used it for the manuals of its equipment, and American publishers for books and journals. In 1987 the University of Chicago Press, publisher of The Chicago Manual of Style, issued a guide that asked authors to put a short code before every heading and caption saying what it was, not how it should look. That was generic coding, explained to people who just wanted their book printed.

It was also heavy, on purpose. SGML let you leave out tags that the DTD could infer, change the characters that marked a tag, and declare almost anything. That suited a publishing department with specialists and a budget. For anyone else, a program often could not even tell where an element ended without reading the DTD first, and writing software that understood all of SGML was a project in its own right.

HTML was born into this family. Berners-Lee based most of its tags on SGMLguid, the documentation format CERN already used, and the HTML 2.0 specification of 1995 states formally that HTML is an application of SGML, with a DTD of its own. Browsers never read it that way. They guessed, forgave and carried on, which is why HTML spread, and why it became the mess that XML was later meant to tidy up.

In 1996 Jon Bosak of Sun Microsystems brought together a small group of people who knew both SGML and the web, to make SGML usable over the internet. Their first draft, published in November that year, was made mostly by taking things out: no omitted tags, no optional syntax, none of the special features. It added one idea SGML did not have. A document could be well-formed: readable by any program, without a DTD, as long as every element was closed and properly nested. The draft’s own example of a complete document is a single line, a greeting saying hello to the world. The family resemblance stayed in the name, and Michael Kay, who would later edit the XSLT standard, noticed it on a mailing list: Mosher and Lorie made it into XML, and Goldfarb did not.

Light enough for the web

XML was SGML made light enough for the web. It became a W3C Recommendation on 10 February 1998, and its design goals read like a list of good intentions. Documents should be easy to create. They should be “human-legible and reasonably clear”. And, in the same list, “terseness in XML markup is of minimal importance” — which anyone who has opened a real XML file will recognise as the goal that won. XSLT followed in November 1999, a language for transforming XML documents into other documents, including HTML. With the two together, single-source publishing was available to anybody.

It was meant to fix the web itself as well. HTML had grown up loose: browsers forgave missing end tags, invented elements and markup that mixed structure with appearance, and every browser forgave differently. XML would bring order. In January 2000 the W3C published XHTML 1.0, “a reformulation of HTML 4 as an XML 1.0 application”, and work began on an XHTML 2 that would break with the old HTML altogether. Nine years later the W3C announced that the XHTML 2 charter would not be renewed and put its resources into HTML 5 instead. The web had kept its forgiving language. What survived from the effort was mostly a habit: closing your tags and keeping structure apart from presentation.

Where it worked: DocBook

For me the discovery was DocBook. It began in 1991 in discussion groups on Usenet, became a joint project of HaL Computer Systems and O’Reilly, the publisher, and moved in 1998 to the consortium that became OASIS, where it is still maintained. It was designed for exactly the work I was doing: technical documents about hardware and software. Its markup described chapters, procedures, warnings and commands, not fonts and margins. Norman Walsh wrote its definitive guide, DocBook, and the guide was itself written in DocBook.

It worked because the conditions were there. A book really did go to print, to HTML and to help. The writers were trained to think in structure. The vocabulary was a shared standard with tools around it, not something an agency had invented for one client. And the structure was paid back with every output: the second one cost almost nothing, the third even less.

The same idea went on, through the same field, into DITA, the Darwin Information Typing Architecture. But that is another story, with its own ending.

The test is the second output

The clearest success story came later. In 2009 NPR described how it had built its content system so that it “could publish to anything, including NPR.org”: browsers, feed readers, iPods, radio displays, mobile devices and televisions. Because the content was kept apart from its display, a new site could be launched without rebuilding the system underneath. That is single-source publishing doing what it promised, at the scale it was made for.

Put the two stories side by side and the difference is not the technology. NPR had many places to publish and a team to maintain the structure. The agency’s client had one website and a communications department that needed to change a sentence on a Tuesday afternoon. Structure that is never used for a second output is cost without return: every edit passes through someone who can read the markup, and every new kind of page becomes a change to the schema.

Most websites today need only the modest part of the promise, and they already have it. A content management system keeps the text in a database and the design in a theme. Change the theme and the text survives. That is separation enough for a site that publishes to itself.

If you are tempted to go further, here is what I would settle first.

Before you separate content from its page

  • Name the second output. A real one, needed now: a printed version, an app, a partner’s site. “One day” is not an output.
  • Count who edits. If the people who write cannot edit the source themselves, every change becomes a ticket for someone else.
  • Structure what is reused, not everything. An address, a price, an opening time that appears on five pages deserves to live in one place. An ordinary paragraph does not.
  • Choose a standard over a private vocabulary. A format with tools and documentation outlives the agency that introduced it. Tags invented for one client do not.
  • Keep the source readable. A person should be able to open it and understand it without the transformation that turns it into a page.
  • Plan the way out. Make sure the content can leave in a plain format, without the people who built the system.

A promise with a condition

The promise of XML was true, and in my own field it changed how documentation was made. But it came with a condition that was rarely said out loud: you had to have more than one place to publish. Without that, writing once and publishing everywhere is just writing once, in a harder language.

Read the originals