True to the Apache spirit, the Cocoon project is a collaborative, open-source effort. Information can be found at xml.apache.org, where you can also find products, documentation, mailing lists and discussion servers. You can even contribute to the project, if you feel up to the task.

Cocoon is based on a pure Java implementation. The Web site explains why simply using existing Java servlets to generate dynamic XML content does not work. It boils down to the fact that the Java servlet API does not support servlet piping; thus, one servlet's output can't be another's input.

The aim of the project is to change the way Web information is created, rendered and served by separating content production, content processing and content rendering. In the Cocoon Project, content production is always done using a Java servlet, known as the producer. The producer can simply read XML content from a file, or it can perform complex database operations to dynamically extract XML content from a database.

The producer's output is fed to the processor. As stated earlier, this step can be eliminated, depending on your content. The following XML content would be generated by the producer:

<?xml version= 1.0 ?>
<page>
<p>The Current Time in Sydney is <AusiTime/></p>
</page>
Our processor would search for tags, such as <AusiTime/>, and replace them with the actual value, resulting in:
<?xml version= 1.0 ?>
<page>
<p>The Current Time in Sydney is 9:15 a.m.</p>
</page>

For more complex needs, the Cocoon Project ships with the following processors (and two deprecated processors):

The XSLT Processor. XSLT is a W3C recommendation. This processor lets you apply XSLT to your document.

The XSP Processor. The XSP (Extensible Server Pages) is a proposal of the Cocoon Project. The proposal is still in the development phase and offers a mechanism for dynamic content development of Web pages. This processor evaluates XSP pages and compiles them into producers.

The LDAP Processor. This processor evaluates LDAP tags inside your documents, executes them against directory servers and returns the results as part of the output.

The workings of some of these processors are extremely technical, beyond the scope of this article. If you want more information, visit xml.apache.org/cocoon/dynamic.html.

The third step in XML publishing is the rendering, or formatting, of the final output. The Cocoon Project has five formatters: HTML, XHTML (Extensible HTML), text, XML and Apache FOP (Formatting Objects to PDF), which generates PDF files. These formatters are simple pass-through codes that call existing components in the Apache Web server to perform the actual formatting. This serves to emphasize that the Web server and its assorted components are an integral part of any Web publishing framework.

Oracle XSQL

As with the other implementations, Oracle's XSQL lets you create XML content, process it and format it for output. Oracle, being a database player, emphasizes the generation of the XML content from the database. Contrast that with the Cocoon Project, which makes almost no mention of a database interaction but rather focuses on the rest of the process.

Oracle has two design goals for its XSQL technology: First, make simple things very simple and hard things possible; second, keep the "datapages" separate from the way the data will be rendered and formatted. A simple XSQL document will look something like this:

<?xml version= 1.0 ?>
<?xml-stylesheet type= text/xsl href= mydemo.xsl ?>
<page connection= demo xmlns:xsql= urn:oracle-xsql >
<xsql:query bind-params= id sal >
select * from EMP where EMPNO= ? AND ? BETWEEN 1000 and 4000
</xsql:query>
</page>

In this example, not only did we include SQL code inside our XML page, but we parameterized it using the standard JDBC (Java Database Connectivity) bind variable indicators. At run-time the two question marks in the text of the select statement will be replaced with the values of the id and sal parameters, respectively.

To render the output to your liking, simply include a reference to the style sheet of your choice, as we did with the mydemo.xsl sheet. Although Oracle leaves it up to you to come up with the style sheets you need, the implementation does include support for calling the Apache FOP processor to produce PDF documents, much as the Cocoon project does.

The XSQL implementation is based on Java servlet technology and is closely linked to JDBC. For more information about this technology, go to technet.oracle.com/tech/xml/xsql_servlet/htdocs/relnotes.htm.

Microsoft SQL Server

Microsoft's SQL Server 2000 has new features that allow select statements to return XML code directly out of the server. This functionality is not limited to Web publishing; it can be used in XML EDI (Electronic Data Interchange) projects and anywhere else you need data formatted in XML. For example, to retrieve information from the sample Northwind database that ships with SQL Server, you could write the following code:

select * from Customers order by CustomerID for XML AUTO

The result would come back in XML. In addition, with IIS 5 you can now embed SQL code directly into XML pages, much as you can do with Oracle's SQL server. The output can then be formatted using an XSL style sheet and presented in the appropriate format. If you're already familiar with Microsoft SQL Server and style sheets, you can probably create a simple yet completely dynamic data-driven Web site in about 30 minutes using Microsoft's new offerings.

You can also create XML views of your relational data, much as with SQL views. XPath queries can then be used to query the XML views. In general, Microsoft has included more capabilities and features in its new XML offerings, in terms of both the SQL Server database and the Web server. However, it also seems that Microsoft did the least in terms of formatting the final output using XSL.