The Web Publishing Process

XML makes the Web publishing process much easier than it was before, when Web site programmers relied solely on HTML. To appreciate how XML helps, we're going to take a brief look at the history of Web publishing and see how dismal the situation was before XML appeared. Afterwards we will introduce the example XML document we will use while solving the Web problems of a fictional company.

When Web sites first began popping up, the designers didn't have many options in the form of Web design languages. Designers created Web pages statically using HTML. Though considered old now, HTML does have a number of attractive features. It consists only of rich, plain text, which makes it easy to transfer, store, and view. Armed with a strong knowledge of Cascading Style Sheets (CSS) and table manipulation, a competent Web page designer could create an impressive-looking document.

HTML's significant shortcoming, however, is that it is static. The Web's explosion into commerce heightened the need for dynamic content. Stock quotes, book prices, and inventory information needed to be displayed with immediacy. With these changes came the Common Gateway Interface (CGI), which allowed developers to write programs and scripts, hosted and run by a Web server, to produce dynamic HTML pages. The programs could now process form data, query databases, and build dynamic output.

CGI paved the way for other technologies, such as Microsoft's Active Server Pages (ASP), Allaire's ColdFusion, and many other server-side scripting engines. These technologies offered significant improvements over CGI, such as performance and scalability, and took a giant leap forward through multithreading, a lightweight alternative to creating a new process with each CGI request. Scripts could now be embedded directly into HTML source code, shortening the learning curve for beginning programmers. These tools also made database access for developers easier. Suddenly huge repositories of information could be accessed and updated online. The ubiquitous Web browser made an ideal distributed client as well.

Ironically, the speed of the Web's growth hindered its maturation. Fueled by the promises of riches through e-commerce, companies raced to stake a claim on the Internet. For the developers of sought-after Web products, time to market became more important than sound application design. A paradigm shift began.

Web content underwent a metamorphosis from scholarly publications to corporate billboards to online shopping markets to full-blown enterprise applications. Business logic, database queries, and service communication logic crept into HTML source code. Web pages increased in complexity and began to resemble computer programs instead of publishing documents. A number of the following problems arose with this phenomenon:

• Scripting languages, while ideal for small amounts of logic, are not robust enough for large-scale applications development. They discourage the use of object-oriented design and do not scale well as an application's complexity grows over time.
• A tight coupling of presentation and content hinders application extensibility. How many developers have solved browser incompatibilities quickly by copying and pasting chunks of similar code? This solution looks easy until you have several versions of one site to maintain! Similarly, how many hours have Web designers spent changing colors, fonts, and page layouts after a company decided to change its corporate logo or image?
• A tight coupling of presentation and content leads to a tight coupling of employee skill sets. Many people can design and code a slick Web site or understand complex business rules and database schemas. Only a precious few can do both. How much time is spent fixing bugs in a design specialist's logic or making a code guru's attempt at page layout passable?

Intuitive Web professionals began to see the need to divide the content of a Web page from the rules that govern its display on browsers or small devices. This distinction is what XML seeks to achieve.

An XML Navigation Example

Navigation has always been an important element to any Web site. The developing field of E-commerce placed an even greater emphasis on effective navigation. If potential customers cannot quickly find what they are looking for, they will spend their money elsewhere.

XML is a useful tool for achieving effective Web site navigation. Expandable and collapsible trees are familiar navigation devices but are tricky to implement because they must work with many browsers. Regardless of implementation, all trees share the same conceptual organization. They consist of a number of nodes (or elements) that are assembled in a hierarchical fashion. Such a tree can easily be modeled in an XML document.

Listing 5-1 is an example of such a document. Each <navitem> element contains a description, one or more images, a hyperlink to another document, and an optional list of children.

The data in this example can be modified to represent anything from Web site navigation to a help document's table of contents. In fact, this document is an excerpt from Microsoft's XML 3 Software Development Kit (SDK) documentation. Its generic navigation information can easily be transformed into a browser-specific UI, and Figure 5-1 shows how Microsoft Internet Explorer 5.5 displays this document by using its default transformation.

Figure 5-2 shows the same document transformed into an interface suitable for a user.

Listing 5-1 Navigation.xml: An XML model of a simple navigation tree.

 <?xml version="1.0"?> <navigation type="tree"> <description>XML (Extensible Markup Language)</description> <openImage>/xmlbook/images/general/open.gif</openImage> <closedImage>/xmlbook/images/general/closed.gif</closedImage> <href target="detail">item2.htm</href> <navitem> <description>What's New</description> <image>/xmlbook/images/general/item.gif</image> <href target="detail">item2.htm</href> </navitem> <navitem> <description>Copyright and Legal Information</description> <image>/xmlbook/images/general/item.gif</image> <href target="detail">item2.htm</href> </navitem> <navitem> <description>XML Developer's Guide</description> <openImage>/xmlbook/images/general/open.gif</openImage> <closedImage>/xmlbook/images/general/closed.gif</closedImage> <href target="detail">item1.html</href> <children> <navitem> <description>Introduction to XML</description> <openImage>/xmlbook/images/general/open.gif</openImage> <closedImage>/xmlbook/images/general/closed.gif</closedImage> <href target="detail">item1.htm</href> <children> <navitem> <description>Advantages of the XML Format</description> <image>/xmlbook/images/general/item.gif</image> <href target="detail">item1.htm</href> </navitem> <navitem> <description>Creating a Simple XML Document</description> <image>/xmlbook/images/general/item.gif</image> <href target="detail">item1.htm</href> </navitem> <navitem> <description>Displaying the File in Internet xplorer </description>  <image>/xmlbook/images/general/item.gif</image>  <href target="detail">item1.htm</href> </navitem> </children> </navitem> </children> </navitem> . . . . </navigation>  

Figure 5-1 Internet Explorer displaying the navigation XML document.

Using a New Publishing Technique with XML

Later in this chapter we will explore a real-world example using XML in the Web publishing process. XML will be used to model the different elements of a fictitious company's Web site. The company, Noverant, sells CDs through its online storefront. Noverant wants to convert its site to XML in an effort to lower ongoing maintenance and development costs. The site will support all major browsers (even those without XML support) and will take advantage of some browser-specific features for a richer user experience.

Figure 5-2 A more user-friendly presentation of the navigation XML document.

Although this example is discussed later, it's useful to introduce some of the concepts now so that you can get an early start. The Noverant site will use a design pattern known as Front Controller. This pattern prescribes a centralized access point for all page requests in the site.

All user requests will flow through a single ASP that will perform the following duties:

1. The controller will check the user's request arguments and will set any relevant security or device-specific flags.
2. The controller will parse the browser's request string for the requested page.
3. The controller will call a helper ASP to build an XML model of the requested view.
4. The controller will choose a user-interface "skin" to govern the transformation of the view XML. The skin will contain the majority of the HTML code that will ultimately be shown in the browser.
5. The controller will either produce the final HTML document itself or, depending on browser versions and user settings, will return the XML and XSLT code to the client to be processed locally.

By having a single access point act as a proxy to the Web site, it will be much easier to control the flow of information through the site. Global settings can be applied once rather than copied and pasted into every page on the server.