/ciol/media/agency_attachments/c0E28gS06GM3VmrXNw5G.png)
Follow UsAlthough it has been nearly two years since Extensible Markup Language (XML) 1.0 was declared a W3C Recommendation, Web developers have accepted it more in theory than in practise. There is a consensus in the community that separating content from presentation will go a long way towards promoting the growth of the Web and enriching users" online experience.
With data neatly tucked into XML documents, and formatting declared in Cascading Style Sheets (CSS), a site can grow very large without cracking under its own weight. Also, Web content will be more accessible to the many unnamed clients that will proliferate in the years to come, e.g. voice browsers, hand-held PCs with low resources, and agents built into everyday gadgets.
Two new standards: XSLT and XPath
With XML and CSS having already been formalized by W3C, the only other standard left wanting was Extensible Stylesheet Language (XSL). Doing any work on XSL was like shooting ducks in the dark. The specifications were fluid, tutorials on the Web were frequently taken off, and XSL processors (developed as experiments) got outdated in no time. Thankfully, the W3C came up with a pack of Halloween surprises in the form of two recommendations - XSLT and XPath - released on November 16th, 1999. This time, it"s a treat.
Transforming and addressing XML data
XPath is an addressing mechanism by which one can navigate into the structure of an XML document and get the required data. It is like URLs that locate resources on the Web in terms of a Web site"s directory structure. XSL Transformation (XSLT) is a language for taking XML data, fitting it into a template, and transforming it into a new document altogether. These are just two of the components that make up the XSL specification. On the whole, an XSL processor must be able to transform XML input into any format as specified in the XSL stylesheet. The result may be an HTML document, a PDF file, or even a new XML data tree.
No dearth of support
There are a number of freely downloadable tools on the Web that have implemented these standards in different stages of their evolution. This probably stands in testimony to the demand that XML publishing has generated. Microsoft Internet Explorer browser has had XML-XSL support since early this year with launch of version 5. These tools will soon be upgraded to incorporate the specifications in their finished form.
Serving up XML
The simplest form of XML rendering is using plain CSS. An XML file can be linked to a style sheet, and when opened in an XML- and CSS-ready browser, it will be formatted as specified.
However, the real power lies in transforming the data to a useful format, say HTML. This will be a two-step process. The XML data is transformed to HTML using XSLT, and that HTML document is rendered using CSS. Simple enough. The resulting document, being plain HTML, is browser-independent.
In the future, however, a request for a Web page will be served with three files - XML data, XSL template, and CSS styling. The process of rendering will be done at the client-side by a capable browser, taking a huge load off the server. Perhaps in transition to this phase, we will see server-side HTML generation through XSL transformations.
XML now!
If you want to experiment with risk-free XML publishing, you can do it right away. Get a simple XML editor like Microsoft XML Notepad to code your data. Download one of the several command-line XSL processors. For the time-being, you can generate the HTML documents each time you want to update the site.
This semi-automatic content generation model should work fine for small and medium Web sites. When weighed against the burden of having to maintain a non-scalable mammoth on the Web, and moving to a new standard overnight, this is a more graceful solution. You can move your XML stock to the server once the next-generation browsers become a standard. Do I see Mozilla on the horizon?