Web Content System Design with XML
The process of transforming XML to HTML is fairly straightforward, but a few factors must be considered.
Document Volatility
One consideration when converting XML documents to HTML is how often the source document will change. Is it really a static document, or is it an XML fragment that's generated on-the-fly by a script or database server? If the document changes often, offline or batch conversion solutions will not be responsive enough.
Server Capabilities
Another factor is which XML transformation capabilities are supported by your web server platform. Table 1 shows the XML transformation capabilities of the most popular web servers.
Table 1 Web Server XML Transformation Capabilities
Web Server |
XML Transformation Support |
Apache |
The Apache XML Project's Cocoon server uses Xerces and Xalan to provide on-the-fly XSLT transformations as part of its 100% pure Java publishing framework. |
Microsoft Internet Information Server (IIS) |
Microsoft provides a little-known ISAPI extension that uses the MSXML parser to perform real-time XSLT transformations on static XML documents as well as XML that's generated using ASP logic. |
iPlanet |
iPlanet's Java-based 4GL environment (Forte) includes support for performing XSLT transformations on XML messages and documents. |
Client Capabilities
Very few web browsers support client-side XSL transformations. Microsoft's Internet Explorer began supporting XSLT in version 5.0, but the final XSLT specification had significant differences from the version implemented by Microsoft. Besides a general lack of support, the variations among different browsers make it impractical to rely on client-side transformation.
Besides transformation, some browser clients support applying Cascading Style Sheets (CSS) to XML documents. Although CSS support for HTML pages is fairly mature, the extensions that allow them to be used with XML documents are still not widely supported. Also, unlike XSLT, CSS has very little support for massaging the underlying structure of the XML document. This limitation prevents most data-centric documents from being displayed in a human-readable format.
Application Requirements
You also need to consider whether the application in question requires real-time transformations. Is the data generated on demand, or is it simply a static file that's stored on the server? Does the data need to be transformed differently depending on the client viewing it?
In some cases, such as displaying personal account information to a user, offline transformation will be impossible. The data must be prepared on demand for each user. Also, if the data must be transformed differently depending on the capabilities of the client (older web browsers, text-only browsers, PDAs, cell phones, people with disabilities, and so on), the web server must perform transformations on demand.
Conclusions
Client-side transformations allow for greater flexibility and more dynamic content, but too few browsers currently support them. Although new versions of the most popular browsers either already support XML or have plans to, users are not upgrading to newer browser versions very quickly. Client-side applications are really practical only when the audience is known and minimal configurations can be dictated (such as employees or partners).
Server-side transformations are safer but may incur unnecessary performance penalties for static XML documents. Transforming on demand ensures that the client receives only the most up-to-date data from the source document. However, invoking an XSLT transformation each time a client requests a static document wastes server processing power and reduces overall site response time. Although most web servers provide for caching of transformed document images, if the underlying data changes infrequently, static transformation is a more viable option.
Based on the stable nature of the underlying documents for this particular application, static transformation is the most efficient and straightforward way to implement this application.