by Thomas Erl
Adding XML to the mix of Web page elements allows for the distinct separation of presentation and content. But what if you wanted to base your presentation on the newfound content definitions provided by XML? There are two technologies that can make this happen:
• Extensible Stylesheet Language (XSL)
• Cascading Style Sheets (CSS)
The Extensible Stylesheet Language (XSL), a supplementary technology for XML, allows for the definition of styles that can control both presentation and content output of queries made against XML documents.
To understand XSL's relationship to XML, it is useful to understand the relationship between Cascading Style Sheets (CSS) and HTML.
Since HTML is used to define the presentation of Web pages, including layout and formatting parameters, it is common to have to repeat several HTML statements throughout a document in order to duplicate a certain type of formatting style. For instance, if all paragraph titles within a document are displayed in a larger font size, bolded and centred, the corresponding HTML tags that produce this formatting need to be repeated for each paragraph title.
With CSS, it is possible to create a class that represents a specific combination of formatting parameters. Instead of repeating HTML code, the HTML document can simply contain a reference to the CSS file, and then add a reference to the paragraph title class for each paragraph title. Not only can this drastically reduce redundant HTML code, it provides an architecture where the appearance of a Web site can be changed by updating just one file (the CSS stylesheet), instead of having to revisit each Web page separately.
As CSS classes relate to HTML tags, so does XSL relate to XML tags. Instead of linking formatting characteristics to a class, they can be linked to specific XML tags. This would allow, for instance, all invoice numbers on an invoice to be automatically bolded, or all credit or negative dollar amounts to be automatically displayed in red. Taking this a step further, business rules can be attached to XML tagged information, so that, for example, all unpaid invoices past a certain date could be italicized on a sales report. Finally, as previously mentioned, XSL can control the output of the XML document content itself. This means that, through the use of XSL, content can be sorted and/or filtered in addition to being formatted.
Most basic formatting and layout parameters relating to XML tags can be controlled through the use of Cascading Style Sheets. Coding CSS to work with XML does not vary much from the creation of traditional CSS classes for HTML, which means those of you already proficient with CSS/HTML will have no problem coding style sheets for use with XML. CSS supplies only a subset of the functionality that XSL can provide to the presentation control of XML documents. Coding XSL style sheets, however, requires a knowledge of XML, and will therefore impose a learning curve on Web Designers familiar only with the CSS/HTML environment. Also, as with CSS output, XSL output will be interpreted differently by different browsers, which will result in the need for more extensive testing.
Server-side vs. Client-side XSL
It should be noted that XSL style sheets can be processed on either the client or the server end. In order to defer the processing overhead, it is preferable for XSL style sheets to be handled by the browser, but since not all browsers support XSL, it is more common to perform the processing on the server (usually the Web server), and then send the output to the client.
Applications that can be designed for specific browser versions can benefit by allowing the client to process the XSL functionality, as it allows browsers to provide a wide variety of data management features that require no communication with the Web server. The XSL prototype developed for this project demonstrates this by performing the processing of an XSL style sheet on the client side.
XSL's acceptance as a mainstream technology is not nearly as broad as XML's. In fact, it is much more common to see XML-enabled applications that do not use XSL than vice versa. One of the reasons behind this may be the fact that traditional CSS style sheets can be used with XML tags to accomplish basic formatting control of XML tagged information, which allows developers to build upon an existing architectural element, instead of having to introduce a new one. Another reason may be the before mentioned complexity of XSL coding. Then there is the entire issue of timing; XML is just establishing itself as a core Web technology, and it may take some more time before other related technologies, such as XLink, XPath and XSL attain a similar status.
Whatever the reason, the current lack of industry acceptance of XSL increases the risk of another technology emerging to take its place. Just because the XSL specification was produced by the W3C, (also responsible for HTML and XML specifications), does not guarantee that it will be become a de facto standard. In the wireless world, for instance, the W3C CompactHTML specification, has had to take a backseat to more accepted (non-W3C) technologies, such as HDML and WML.
The best way to currently approach XSL is to assess its value on a per project basis. The XSL specification provides a comprehensive set of features that allow for numerous ways of manipulating the display of XML documents, as well as the output of reports based on XML data. Implementation of these features can significantly reduce the amount of custom programming required to produce the same results.
CSS is a more established technology that has been successfully used by organizations for years. Combining CSS with XML documents may be a wise tactical decision for projects starting up in the near future. The only exception to this approach would be if features only deliverable by XSL were also required. It would be undesirable to have both CSS and XSL style sheets linked to the same XML document (or document set), and any standard developed around XML presentation and reporting should forbid this.
If XSL continues to succeed in establishing itself as the industry standard presentation control technology supplement for XML, there will be little need for CSS files.
What about XSLT?
XSL technology can be used specifically for the translation of XML documents from one schema to another without the need for custom programming. XSL Transformations (XSLT) provides this functionality, and is an implementation of XSL (with a dedicated specification by the World Wide Web Consortium) that is gaining a great deal of support (even more so than XSL itself), due to the simplicity of its makeup. To learn more about XSLT, read the Transforming Data with XSLT paper.
A Note Regarding Security
When using XSL style sheets with applications that allow external access, be aware that XSL files hosted by the Web server could be compromised. Through the alteration of XSL parameters, custom (but unauthorized) queries could be submitted to the Web server. Without proper security measures, this could even expose XML data residing on an application server. (Since parameters in CSS files don't represent actual data, this security risk does not apply.)
Regardless of whether XSL style sheets are used, XML usage should generally be restricted to server-side processing behind a DMZ. Web server processing or hosting of XML files is not recommended until firm security measures are in place, or unless the data being managed is not considered sensitive in any way.
- Inside XML Schemas
- SOAP in a Nutshell
- Transforming Data with XSLT
- Understanding DTDs
- Why SAX is Good for DOM
- What You Should Know about XPath
- An XHTML Primer
- XLink - Inside and Out
- Data Access with XQuery
- XSL versus CSS
- Another Introduction to XML
- Unifying Corporate Data & Documents
- Replacing HTML Documents with XML
- Meta-Enable Your Enterprise
- The XML Data Custodian
- Integrating XML into the Enterprise
- The Wireless Enterprise
Foreword by Grady Booch
With contributions from David Chappell, Jason Hogg, Anish Karmarkar, Mark Little, David Orchard, Satadru Roy, Thomas Rischbeck, Arnaud Simon, Clemens Utschig, Dennis Wisnosky, and others.
Governing Shared Services On-Premise & in the Cloud by Stephen Bennett, Thomas Erl, Clive Gee, Anne Thomas Manes, Robert Schneider, Leo Shuster, Andre Tost, Chris Venable
For more information about these books, visit: www.servicetechbooks.com