The code-in-your-pages camp includes the ASP (Active Server Pages), JSP (JavaServer Pages) and PHP (PHP Hypertext Processor) standards. In all cases, server-side scripts are mixed with HTML code to provide dynamic content. Clearly, logic, content and user interface are closely mixed; thus the burden is shifted from HTML coders to PHP, JSP and/or ASP coders, but the problems persist.

The pages-in-your-code camp includes Java servlets and Microsoft's Web classes. Once again, developers are promised technologies that would separate content from the user interface, but instead they end up with a plethora of code that produces HTML tags from inside Java or Visual Basic. Instead of editing HTML text files, we find ourselves revising out.println( ) and response.write( ) statements. To be fair, some programmers manage to split the content from the user interface to a certain degree. However, this feat is accomplished in spite of the available technology, not because of it.

So What's a Site Developer To Do?

With the advent of XML, a new Web publishing framework is evolving. This framework is based on XML (Extensible Markup Language) and its siblings, XSL (Extensible Style Language) and XSLT (Extensible Style Language Transformation). This framework provides content to requesting clients in much the same way as Web servers today provide HTML pages to requesting browsers.

There's a key difference, however: The new framework does not provide a page; rather it provides a published form of a page. Although the content is the same, the published page differs by client. For example, if an Acrobat reader made the request, the published page would come back as a PDF document. A WAP (Wireless Application Protocol) device would receive a WML (Wireless Markup Language) page, and a regular Web browser would receive an HTML page. In the case of a Web browser, you may even choose to serve different published pages depending on whether the incoming request is coming from the text-only Lynx browser, or from Netscape Navigator or Microsoft Internet Explorer.

A Nifty Trick

To accomplish this feat, the XML Web publishing framework separates Web content generation into three steps:

1. XML Creation. Content owners create and develop the XML files. These content owners do not need to know anything about how the content is processed or presented. While this is how mature publishing systems handle content, most Web publishing does not work in this manner. Rather, content owners and HTML writers are often doing each other's jobs.

   People using regular text editors generally perform this part of the cycle, though some XML-aware text editors are available and make the process a bit easier. Some vendors are enabling their databases to produce XML data directly out of select statements.

2. XML Processing. Next, the XML file is processed. Any intermediate logic is applied here. This step may be eliminated depending on how Step 1 was performed. We'll look at an example of XML processing when we discuss the Cocoon Project.

3. XSL Rendering. The document generated in Step 2 is now rendered by applying an XSL style sheet to it. Specific formatting is applied, resulting in a document applicable to the requesting client. Possible outputs include HTML, PDF, WML and XML.

The Oracle and Microsoft solutions are based on the respective vendors' flagship databases. In contrast, the Cocoon Project focuses on the publishing process and tools and cares less about the source of the data.