Sadly, however, most of the time this content is kept in its kinetic state by having a large staff of HTML editors constantly create and revise it. This process is costly, error-prone and cumbersome. The CSS (Cascading Style Sheets) standard helped streamline the visual aspects of complex, dynamic Web sites, but it fell short of what is really needed. The next step was to use server-side technologies to create the content. These technologies come in two flavors: "code in your pages" and "pages in your code."
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:
- 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.
- 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.
- 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.
Actual implementations of such a framework are at the very early stages of development. At the forefront of these implementations are the Cocoon Project, from Apache; Oracle's XSQL pages; and Microsoft's version, introduced in Internet Information Server (IIS) 5.0 and SQL Server 2000.
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.
We like Microsoft's implementation because it is the most developed and easiest to master. The downside, of course, is that you will need to run it on a Windows platform, which may not be your corporate standard. As for Oracle's XSQL, if you have an Oracle database, you should definitely stick to this solution. To install and deploy Cocoon, you will need hard-core Apache, Java or Linux expertise. If you do have the manpower, this is definitely the most diverse -- and the only vendor-neutral -- solution.
RSS
