15.1 Languages and Metalanguages

A language is comprised of symbols that we assemble in a meaningful way to express ourselves and pass along information in a way that is intelligible to others. For example, English is a language with rules (grammar) that define how to put its symbols (words) together to form sentences, paragraphs, and, ultimately, books like the one you are holding. If you know the words and understand the grammar, you can read the book, even if you don't necessarily understand its contents.

An important difference between human and computer-based languages is that human languages are self-describing. We use English sentences and paragraphs to define how to create correct English sentences and paragraphs. Our brains are marvelous machines that have no problem understanding that you can use a language to describe itself. However, computer languages are not so rich and computers are not so bright that you could easily define a computer language with itself. Instead, we can define one language — a metalanguage — that defines the rules and symbols of another language.

Software developers can use a metalanguage to define the rules for defining a language and then define one or more languages based on those rules.^[1] The metalanguage also guides developers creating the automated agents that display or otherwise process the contents of documents that authors have created using that language.

^[1] The use of metalanguages has long been popular in the world of computer programming. The C programming language, for instance, has a set of rules and symbols defined by one of several metalanguages, including yacc. Developers use yacc to create compilers, which in turn process language source files into computer-intelligible programs (hence, its name: Yet Another Compiler Compiler). yacc's only purpose is to help developers create new programming languages.

XML is a metalanguage created by the W3C and used by developers to define markup languages such as XHTML. Browser developers rely on XML's metalanguage rules to create automated processes that read the language definition of XHTML and implement the processes that ultimately display or otherwise process XHTML documents.

Why bother with a markup metalanguage? Because, as the familiar proverb goes, the W3C wants to teach us how to fish so we can feed ourselves for a lifetime. With XML, there is a standardized way to define markup languages that are customized for different needs, rather than having to rely upon HTML extensions. Mathematicians need a way to express mathematical notations; composers need a way to present musical scores; businesses want their web sites to take sales orders from customers; physicians look to exchange medical records; plant managers want to run their factories from web-based documents. All these groups need an acceptable, resilient way to express these different kinds of information, so that the software industry can develop the programs that process and display these diverse documents.

XML provides the answer. Each content sector — the business group, the factory-automation consortium, the trade association — may define a markup language to suit its particular needs for information exchange and processing over the Web. Computer programmers can create XML-compliant processes — parsers — that read the new language definitions and allow the server to process the documents of those languages.

15.1.1 Creation Versus Display

While there is no limit to the kinds of markup languages you can create with XML, displaying your documents may be more complicated. When you write HTML, a browser understands what to do with the <h1> tag because it is defined in the HTML DTD, and browsers have been programmed to display all standard HTML tags.

With XML, you might create a DTD^[2] for describing recipes. It would be a great way to capture and standardize all those kumquat recipes you've been collecting in your kitchen drawers. With special <ingredient> and <portion> tags, the recipes are easy to define and understand. However, browsers won't know what to do with these new tags unless you attach a style sheet that defines their handling. Without a style sheet, XML-capable browsers such as Internet Explorer 5 and 6 and Netscape 6 render these tags in a very generic way — certainly not the flourishing presentation your kumquat recipes deserve.

^[2] An alternative to DTDs is XML Schemas. Schemas offer features related to data typing and are more programmatically oriented than document oriented. For more information, check out XML Schema by Eric van der Vlist (O'Reilly).

Even with style sheets, there are limitations to presenting XML-based information. Let's say you want to create something more challenging, such as a DTD for musical notation or silicon chip design. While describing these data types in a DTD is possible, displaying this information graphically is certainly beyond the capabilites of any style sheets we've seen yet; properly displaying this type of graphically rich information would require a specialized rendering tool.

Nonetheless, your recipe DTD is a great tool for capturing and sharing recipes. As we'll see later in this chapter, XML isn't simply about creating markup languages for displaying content in browsers. It has great promise for sharing and managing information, so that those precious kumquat dishes will be preserved for many generations to come. Just bear in mind that, in addition to writing a DTD to describe your new XML-based markup language, in most cases you will want to supplement the DTD with a style sheet.^[3]

^[3] In fact, it is possible to write XML documents using only a style sheet. DTDs are highly recommended but optional. See http://www.w3c.org/TR/xml-stylesheet/ for details.

15.1.2 A Little History

To complete your education into the whys and wherefores of markup languages, it helps to know how all these markup languages came to be.

In the beginning, there was SGML, the Standardized Generalized Markup Language. SGML was intended to be the only markup metalanguage, from which all other markup languages would be created. Everything from hieroglyphics to HTML can be defined using SGML, negating the need for any other metalanguage.

The problem with SGML is that it is so broad and all-encompassing that mere mortals cannot use it. Using SGML effectively requires very expensive and complex tools that are completely beyond the scope of regular people who just want to bang out an HTML document in their spare time. As a result, other markup languages that are greatly reduced in scope and much easier to use have been created. The HTML standards themselves were initially defined using a subset of SGML that eliminated many of the more esoteric features. The DTD in Appendix D, uses this subset of SGML to define the HTML 4.01 standard.

Recognizing that SGML was too unwieldy to describe HTML in a useful way and that there was a growing need to define other HTML-like markup languages, the World Wide Web Consortium (W3C) defined XML. XML is a formal markup metalanguage that uses select features of SGML to define markup languages in a style similar to that of HTML. It eliminates many SGML elements that aren't applicable to languages like HTML and simplifies other elements to make them easier to use and understand.

XML is a middle ground between SGML and HTML, a useful tool for defining a wide variety of markup languages. XML is becoming increasingly important as the Web extends beyond browsers and moves into the realm of direct data interchange between people, computers, and disparate systems. A small number of people wind up creating new markup languages with XML, and many more people want to be able to understand XML DTDs in order to use all these new markup languages.