A common dilemma faced by many professional writers in this day and age is what format their work will appear in. This article appears as a Web page, however, depending on the needs of publication, the editor might want to redeploy it in print. If my article appears as a Web document, the text can be formatted using just HTML. In this age of browser wars and legacy systems, however, many Web pages are created using more than just HTML. Just considering the browser war between Netscape and Microsoft, you have a minimum of six different specifications to worry about. These range from HTML 2.0 compliance with Internet Explorer 3.0 and Netscape Navigator all the way to the advanced dynamic HTML (ostensibly HTML 4.0, but also including JavaScript, Cascading Style Sheets, XML, and XSL) that seems to be on the drawing board for the fifth generation browsers. If you add to that mix the componentization introduced by technologies such as ActiveX and Java, the life of a Web developer can become a living hell.

Print introduces an additional layer of complexity—one which HTML really isn't up to solving. Editors of print publications often make use of sidebars, or areas where information that may be useful but isn't central to the article or chapter is displayed. As a writer, I would prefer being able to do the following when having to use sidebars:

As an editor, however, I would rather not have my writers decide to format text as "indented 11pt Helvetica justified" when the article will appear in 10pt Garamand with justification turned off. Ideally, a writer should have as little interaction with the formatting of a page as possible.

The problem here is that as both editor and writer I want to separate the data layer (the words and their underlying structure) from the presentation layer (how the page gets displayed in its given medium). While HTML is a remarkably flexible medium, it suffers from some significant defects that have been evident for a while but are only just being addressed:

The original purpose of HTML was to provide a means of displaying scientific documents. These roots are evident in HTML tags such as <CITE>, which makes perfect sense in a scientific context but not in a typical publishing context. In addition, HTML is not intrinsically extensible. If you want to add functionality to an HTML document, you must either work with an advanced browser and use JavaScript or Cascading Style Sheets (CSS) to provide that functionality yourself, or petition the World Wide Web Consortium (W3C) to include a tag that meets your need. The first approach is technically expensive and the second is virtually impossible unless you have the reach of Microsoft or Netscape. Even in its simplest form, the presentation layer sneaks into the data layer of HTML in subtle ways. This intrusion becomes far more blatant when you use a tag that is directly tied into presentation (for example, the ill-considered <FONT> tag).

Cascading Style Sheets were the first tentative step toward decoupling the data layer from the presentation layer. CSS works on the premise that each element in the page can be described through a set of common properties within the style attribute of that element. You can specify the background color, font-size, height, or border style of an element by changing the appropriate CSS property.

The next step is to create classes that collect all of these CSS properties into a single entity that can be named. This allows you to create more customizable pages in which the classes become ersatz tags. For example, the following Web page would let you define your own Sidebar class in CSS.

You still have to be aware of the order of things (presentation information) with CSS, even if it is not to the same extent that generic HTML would be. In HTML, you can't nest paragraph tags in HTML. The Sidebar, however, has to be contained within the body of a paragraph. I used the <SPAN> tag to accomplish this effect.

XML is About Data

In certain respects, mixing presentation and data lies at the heart of the most significant dilemma that the Internet has faced yet. The Internet is fracturing. Each time a new generation of browsers comes out (which seems to take place about once every 18 months or so) the discrepancies between different versions of the HTML "standard" mean that surfers will find themselves able to view fewer and fewer pages with their browsers. Older browsers will break on new features and JavaScript enhancements; newer browsers will be unable to leverage their most significant enhancements.

In theory, the solution to this problem is relatively simple: divorce the data and structure of a page from its presentation layer. By doing this, people can create or leverage the content that they have (either from a file or, increasingly, from a database on the server) and then work with a series of templates that will present the information in the best way for the browser being used.

In practice, this solution requires changing the underlying paradigm upon which Web pages are built by abandoning HTML as the authoring language. Since there are hundreds of millions of HTML pages currently on the Internet and millions of people proficient with the language to one degree or another, this theoretically simple problem takes on a whole new dimension of complexity. However, unless we want the marvel that is the Internet to collapse under all of the fissures being introduced into it, this step is necessary.

The solution that has emerged from the W3C (and more importantly, the solution that both Netscape and Microsoft seem to have agreed upon) is Extensible Markup Language, or XML. XML has been bandied about as the next great language, the data solution par excellence, and a pretty good floor wax and dessert topping too. As with all such technologies, it's important to separate the hype from the actual capabilities. But the promise that XML shows is having (and will continue to have) a powerful impact upon the Web community.

The idea behind XML is deceptively simple. Rather than providing a set of markup tags like HTML does (such as <P>,<H1>, <BR> and so forth), XML lets you create the markup tags yourself. For instance, the Sidebar above might be described like this:

This fragment illustrates several salient points about XML. First, there is no presentation information intrinsic to an XML document. Every tag describes the data that it contains, but provides absolutely no clue as to how the tag should be displayed. Also, the data is structured. HTML is theoretically structured, but because there are so many presentation elements that have crept into the language over the years, there's a lot of ambiguity in an HTML page that the browser's parser has to negotiate. Finally, the tags are defined by the user, not by a standards committee.

You should examine this last point more closely. XML is a way of taking hierarchical data and expressing it in an HTML like format. The strength of this concept is not so much in the actual data formatting but that XML is an agreed upon standard for formatting that data in a specific way. The data that I use in my application may be completely different in both content and structure from your application data, but because there is an agreed upon vocabulary for what elements are used to structure that data, the same parsing tools can understand and display both sets of data. XML gives a universally agreed upon syntax for describing data. In this respect, XML isn't a language at all—it's a meta-language. The same conventions can be used to talk about an article about music (with musical notation) and a chemical abstract written by an engineer. Even though the specific data structures are going to differ dramatically between the two, since they both use XML syntax to structure the data, a browser can read and transform both types of XML documents to properly display them (as discussed in Showing Off With XSL below).

This ability to customize your tag set would appear to be an open invitation to disaster. If I choose to designate all of my paragraphs with a <PARA> tag and you choose a <P> tag, then one of our browsers will break. You can think of an XML structure as a tool for negotiating a common standard. Part of the reason for creating a structured tool like XML in the first place is to communicate with others, so you will need to determine an agreed upon vocabulary of tags with everyone else who will be using this standard.

This vocabulary contact is known as a Document Type Declaration, or DTD. A formal DTD defines which elements are included within the vocabulary, which elements contain which other elements, what kind of attributes (analogous to an HTML attribute like src for an <IMG> tag) belong to each element, and what primitives are defined within the vocabulary. The details of how to set up DTDs are definitely beyond the scope of this article, but you can find several useful books on XML that cover this topic extensively.

The scope of agreement on a DTD will depend upon how many people are likely to be using the XML data. Already, a number of industry groups have defined common DTDs for everything from displaying chemical information to regulating e-commerce systems. Each official version of HTML has a DTD (although these DTDs are actually generated from XML's parent meta-language, SGML). DTDs for synchronized media and two dimensional vector graphics are still hotly debated, and there is some indication that VRML, the 3D markup language, may end up being redefined using XML for its next release.

Showing Off With XSL

If XML is all about data, you may beg to ask, "How do I display the XML?" The answer to that question involves Extensible StyleSheet Language (XSL). XSL extends the notion of Cascading Style Sheets to the next logical level. The principal model in use for XSL works like this:

• The browser loads an XSL parser into memory.
• The parser retrieves the XML document and an XSL document, which consists of a set of rules for transforming the XML data.
• The parser follows the rules in the XSL and retrieves data in the order that it is contained in the document.
• The output from applying the XSL rules is stored in a local buffer. When the document has finished processing, the parser spits it out to the browser.
• The browser then displays the transformed data.

The specific details of XSL have just recently been approved by the W3C, although its recommendations won't become widely available until the fifth generation browsers are released. However, a short sample XSL document illustrates the power of the language:

At first glance you may be wondering how this can be an improvement over standard HTML. The rules that XSL employs aren't altogether that straightforward—the syntax demonstrated above uses a form of recursion to apply the appropriate HTML formatting. The advantage here is that the same exact rules can be applied to formatting a document with a hundred complex paragraphs as can be applied to the simplest document that has one paragraph. Moreover, in conjunction with a switching mechanism written in JavaScript or a related scripting language, you could load a different XSL document depending on which browser you're targeting. If deployed from server-side scripts, this ability offers many advantages.

I'm being deliberately vague about what kind of browser is being used to display the transformed output. XSL doesn't have to convert the XML into HTML, although it will almost certainly be used for that purpose first. One potentially explosive scenario for XSL is using it to convert an XML data document into a JavaScript or VBScript program which would in turn automate other data processes (perhaps generating another XML stream with embedded processing instructions that gets sent to a different machine, where the whole process gets repeated). As long as all of the machines support a consistent XSL parser, this use of XSL could become a significant step toward providing a completely platform independent remote processing architecture.

Coming Soon?

Whether the data source is a document (such as this article, which was written in XML) or a complex data format for conveying financial information within a banking conglomerate, there is no question that XML will become one of the most important ways of exchanging data in the twenty-first century.

However, XML will not completely replace HTML any time soon and this changeover won't take place overnight. Internet Explorer 5.0 is likely to be the first Web browser to support XML, and it probably won't be released as a commercial product before the end of the year at the earliest (and I would be willing to bet it will probably be delayed until the release of Windows NT 5.0). There are few tools out there at the moment for creating complex XML data, although again that will change by the early next year. Finally, XML involves a level of abstraction that may not be readily grasped by HTML hobbyists; it will have a fairly steep learning curve for all but the simplest of functions.

If you are a Web developer working on a data driven site, you should explore the capabilities that XML has to offer. Most of the next generation data environments such as SQL Server 7 will allow you to retrieve data in XML format, simplifying the task of manipulating complex tables and hierarchical objects on the page. XSL's transformational capabilities can be used independently of the Web environment for data conversions. The potential that XML and XSL offer for concepts such as intelligent agents, cross platform data-driven applications, e-commerce, and data mining makes the technology truly exciting.