Exploring Mark-up Languages: From SGML to HTML and XML

Every web page you open, every data file your phone syncs in the background, and every e-book you flip through shares a hidden ancestor. Behind the neat headings, links, and images lies a set of rules called mark-up languages. These languages tell a computer not just what text says, but what each piece of text is: a heading, a paragraph, a price, a date. Three names dominate this story, namely SGML, HTML, and XML, and they are tied together like grandparent, child, and grandchild. Understanding how one grew out of the other makes the modern web far less mysterious, especially for students of information science who deal with documents, metadata, and digital records every day.

What a mark-up language really does 🔗

A mark-up language adds labels, called tags, around content. These tags describe the structure and meaning of the content rather than the content itself. For example, a tag can mark a chunk of text as a title or a list item. The software reading the file then decides how to display, store, or process that labelled content. This simple idea, separating what something is from how it looks, is the thread running through every language we will discuss.

The reason this matters is reuse. The same labelled document can be printed, displayed on a screen, read aloud by an accessibility tool, or fed into a database, without rewriting the content each time. For libraries and archives that must keep records readable for decades, this separation is not a luxury. It is a survival strategy.

SGML: the foundation of mark-up 🔗

The story begins with the Standard Generalized Markup Language, or SGML. It grew out of work at IBM in the 1960s on something called Generalized Markup Language, and it was eventually formalised as an international standard. In October 1986 it became ISO 8879, published by the International Organization for Standardization. That standard is still listed as current today, which says a great deal about how solid the original design was.

Why SGML was built 🔗

SGML was designed to share large, complex documents across different systems in government, law, the military, aerospace, and industrial publishing. According to the Library of Congress, many of these documents needed to stay readable for several decades, which is a long time in computing. The goal was hardware and software independence: a document marked up once should be usable on any machine, by any program, far into the future.

The ideas SGML introduced 🔗

SGML is not really one language. It is a meta-language, meaning it is a system for defining other mark-up languages. Two of its concepts still shape everything we use today.

Descriptive mark-up. SGML promoted labelling content by what it is, such as a chapter, a paragraph, or an index entry, rather than by how it should be printed. The actual appearance is decided later by separate instructions. This is the separation of content and presentation that web designers still talk about.

The Document Type Definition. SGML allowed authors to define a set of rules, called a DTD, listing which tags are allowed, how they nest, and what attributes they carry. A document could then be checked against its DTD to confirm it follows the rules. This idea of validating a document against a formal structure is central to data quality work in any information system.

SGML also gave us the language of elements (the tagged components), attributes (extra information attached to a tag), and entities (reusable references to text or symbols). If those words sound familiar from HTML, that is because HTML inherited them directly.

Why SGML faded from everyday use 🔗

SGML was powerful, but that power came with heavy complexity. Writing a full DTD and configuring an SGML processor was difficult and expensive, which kept it confined to large institutions rather than ordinary users. As the web exploded in the 1990s, the world needed something simpler. SGML did not disappear, though. It survives in specialised settings and, more importantly, it lives on through its two famous descendants.

HTML: organising content for the browser 🔗

The HyperText Markup Language, or HTML, was created so that ordinary documents could be shared and linked across a network. It was developed by Tim Berners-Lee at CERN, the European nuclear research organisation, around 1989 to 1991, originally to help scientists exchange research documents. HTML was built as an application of SGML, meaning it is essentially a specific, predefined set of tags following SGML’s general rules.

From a research tool to a global standard 🔗

HTML’s purpose is to tell a browser how to structure and display content. It uses a fixed set of tags, such as those for headings, paragraphs, lists, and links, so that any browser can interpret a page the same way. To keep this consistent across competing browsers, Berners-Lee founded the World Wide Web Consortium (W3C) in 1994, and the W3C has guided HTML’s standardisation ever since. Over the years HTML moved through versions, adding tables, forms, and richer structure, while the W3C and the WHATWG group worked to keep the language reliable across devices.

HTML and multimedia 🔗

Early HTML handled text and links well but struggled with audio and video. For a long time, embedding a video meant relying on third-party plugins such as Flash, which were clumsy and inconsistent, especially on mobile devices. This changed with HTML5. As Mux explains, HTML5 introduced dedicated tags for audio and video, letting browsers play media directly without external plugins. HTML5 also added semantic elements that label parts of a page, such as headers, footers, and articles, improving structure, accessibility, and search visibility.

This is the key point about HTML: it is fundamentally about presentation and linking. Its tags carry built-in meaning for a browser, which knows that a heading tag should look like a heading and a link tag should be clickable. That predefined behaviour is exactly what makes HTML easy to learn and consistent across the web, but it is also its limitation.

XML versus HTML: structure against presentation 🔗

HTML answered the question of how to display documents, but it could not store and exchange arbitrary structured data well. Its tags are fixed, so you cannot invent a tag for, say, a student’s enrolment number or a book’s ISBN. This gap led to the Extensible Markup Language, or XML.

What makes XML extensible 🔗

The W3C released XML as a recommendation in February 1998. The W3C press release described it as a system for defining, validating, and sharing document formats on the web, and noted that XML is a simplified subset of SGML. In other words, XML took SGML’s flexibility but stripped away much of its complexity so that it could work easily on the web.

The defining feature of XML is in its name: it is extensible. Unlike HTML, XML has no fixed list of tags. You define your own tags to match your data. A library catalogue could use tags named for author, title, publisher, and call number, all chosen to fit the information being described. This makes XML ideal for storing and transporting structured data between different systems, applications, and databases.

Strict rules and validation 🔗

Because XML carries meaning that machines must read precisely, it follows strict syntax. Every tag must be closed, tags must nest correctly, and XML is case sensitive. HTML, by contrast, is more forgiving and a browser will often display a page even if a tag is left open. XML’s strictness is deliberate, since a single error can stop the file from being processed at all. The W3C designed XML for ease of implementation and interoperability with both SGML and HTML, so that data could move cleanly between platforms.

Crucially, XML on its own does nothing. It only holds data. It needs another application, a stylesheet, or a program to display or act on that data. This is the opposite of HTML, where the browser already knows how each tag should appear.

Choosing between them 🔗

The simplest way to remember the difference is this. HTML is concerned with presentation, deciding how content looks in a browser. XML is concerned with structure, defining and carrying data in a machine-readable form. They are not rivals so much as partners built for different jobs. A common pattern is to store information in XML and then use HTML to present it. RSS feeds, configuration files, and data exchange between web services are all classic XML territory, while the page you read sits in HTML.

How the three fit together 🔗

Seen as a family, the relationship is clear. SGML is the grandparent, a vast and complex meta-language for defining mark-up. HTML is one child, a fixed and friendly application of SGML built for displaying web pages. XML is the other, a streamlined descendant that kept SGML’s flexibility for structuring data while being far easier to use. There is even a hybrid in the family. XHTML reformulated HTML using XML’s strict rules, giving web pages the discipline of XML while keeping the look of HTML, as the W3C noted when it published the XHTML recommendation.

For students of information science, this lineage is more than trivia. Metadata standards, digital archives, e-book formats, and library catalogue exchange formats all rely on these languages. Knowing that they share one ancestor, and understanding the split between describing structure and controlling presentation, gives you a framework for making sense of almost any digital document format you will meet in practice.

What do you think? If SGML was so powerful, why do you think its simpler descendants ended up shaping the modern web instead of SGML itself? And in your own field of study, would you reach for HTML or XML to preserve a document for the next fifty years, and why?

References

1. https://www.iso.org/standard/16387.html
2. https://www.loc.gov/preservation/digital/formats/fdd/fdd000465.shtml
3. https://www.w3.org/TR/xml/
4. https://www.mux.com/articles/html5-video-players-understanding-the-video-tag
5. https://www.w3.org/press-releases/1998/xml10-rec/
6. https://www.w3.org/news/2008/extensible-markup-language-xml-10-fifth-edition-is-a-w3c-recommendation/