A friend wanted to show me a great new thing in 1993, this crazy HTML browser called Cello. He knew I was working on hypertext and this seemed like just the thing for it! Sadly, my time in HyperCard and an unfortunate encounter with the HyTime specifications meant that I bounced off of it, because markup couldn’t possibly work.
I was, of course, very very wrong.
Markup with some brilliantly minimal hypertext options was about to launch the World Wide Web. The toolset was approachable, easy to apply to many kinds of information, and laid the foundation for greater things to come.
When I first got to XML, the markup was still primary and the processing an afterthought. Get the markup right, for many different values of right, of course, and the processing will be manageable. The markup approach offers some powers that I haven’t found in other data models and systems:
- The very term “markup” reminds us that we are indeed ‘marking up’ documents that may have cohesive value on their own, not just as shredded and codified chunks of data.
- Broken and incomplete documents may yet contain especially important information.
- Markup leaves the door open for information that didn’t fit in someone’s prized model, allowing for format evolution rather than cycles of standardization. The structure of a given document is almost always easier to change than the programs that process it. (The nodes view emphasizes the priority of programs and all too often celebrates the things that make them brittle.)
- Markup makes comprehensible possibilities that can’t be reached if you lock yourself into nodes from the beginning, like overlapping structures. Programmers indoctrinated into neat structure often see this as an utter corner case, but those who work with human documents know it exists regularly in the wild.
At some point, maybe around the time of the Microsoft “he doesn’t know what XML is” advertisement, a lot of people arrived in markup who had no interest in its details.
XML was exciting because it made clear that data interchange was possible with much simpler tools than its predecessors. Markup was still incredibly useful, but as the servant of programmers. XML structures suddenly had to look like programming structures, because nothing else could be trusted. They could look a little different, because after all programmers from different environments had different expectations, and there were documents to tolerate, but Schemas and WSDL and similar structured approaches dominated.
The data hygiene and mental hygiene of programming are not appropriate for markup. Programming and markup have connections, much like carpentry and plumbing, but their best practices are very different.
JSON, ASN.1, and similar approaches are much better fits for programming, which need only the structure but not the weight of markup. Over time, they (JSON in particular) are eroding XML’s share of markets it was never well-suited for anyway.
Markup isn’t done yet.