Architectures for Styling

April 19, 2000

Didier Martin

Some months ago, I saw an amusing cartoon. Two scientists are in the middle of a huge footprint. One of them says to the other: "I do not see any sign of its presence", talking obviously of the monster who made this huge footprint. You, as an observer, can see that these two fellows are right in the middle of a huge footprint, but neither of them can notice that -- both only notice that the ground level is slightly lower.

Often, we are in also in the middle of the footprint and we need to take a new perspective to notice the obvious. So, let's explore the footprint of styling XML.

As you know, in order to view an XML document, it has to be transformed into objects that our senses can perceive -- this transformation process is called styling. This transformation can occur either on the server side or on the client side. The same XML document may be presented in many different ways. On a cellular phone, where only a few lines of text are available, the XML document is not displayed in the same way as it would be with a desktop computer browser. Thus, the appearance an XML document takes depends on the client user-agent we are using to render it. Some user agents may transform the document into an aural experience, others into a visual or a tactile experience.

So, where should styling occur? In the user-agent, or before the user-agent ever receives a document? Should we use XSLT or CSS? We'll examine the possible combinations of styling languages and processing models.

Server Side Processing

XSLT can be used to transform an XML document into a rendering language. An XSLT transformation sheet can be used to transform a particular XML document into HTML for an HTML browser, into WML for a cell phone, into SVG for an SVG viewer. The web server may recognize the user-agent and use the appropriate transformation sheet to provide a document the user-agent can understand. With this kind of scenario, all transformations occur on the server side. XSLT is then used to produce a document encoded with a format the user agent can understand.

Figure 1: An example of server-side XML processing

When this type of architecture is adopted, all processing occurs on the server side. This type of architecture does not take advantage of the full the potential for distributed style processing that XSLT offers.

The Beginning of Distributed Style Processing

Some user agents may include an XSLT engine, so that they user agents can receive an XML document and transform it locally into a particular language that they can render.

For instance, an SVG viewer may include an XSLT engine: it could receive XML documents from relational database queries, convert the data into a sophisticated SVG layout and display it in a nice form that includes graphics, pie charts and tutti quanti. In this scenario, the relational database may offer an HTTP interface. The client receives both the data (i.e. the XML document) and a transformation sheet that can produce a particular view and set of behaviors to manipulate the data.

This architecture takes advantage of the distributed processing that XSLT offers. The transformation may occur on the server side or the client side. It all depends on the capabilities of the user-agent. As more "XSLT aware" user-agents are present in the field, the more the server workload is reduced, resulting in better scalability.

Figure 2: Combined client/server side processing

CSS vs XSLT

When a web server sends an XML document, it can be sent to the client with a CSS style sheet instead of an XSLT transformation sheet. In this case, there is no intermediary rendering language like HTML, but a direct translation into CSS formatting objects that are displayed by the browser.

So how does using XSLT for styling XML on the client side stack up against using CSS?

CSS is constrained by document structure

CSS provides a one-to-one mapping between componets of an XML document and their rendered form. In some cases, a limited one-to-many mapping is possible when external content is included in the result layout. Also, the resultant layout object structure must closely follow the XML document structure. This is mainly because CSS does not include any transformation facilities. This is a serious handicap for CSS because, most of the time, a desired view of a particular XML document does not share the same tree structure as the original document.

For instance, the view may require that a name and address be presented first on a form, even if the original XML document includes these elements at the end. This implies a move of the name and address elements from the end to the beginning -- the XML document has to be transformed. Transformation tools allows us to create different views of a single XML document.

Thus, the main difference between using CSS and XSLT for client-side styling is that CSS presents document views that are constrained by the tree structure of the source document, which is not the case with XSLT.

XSLT allows complex visualizations

An other point of differentiation between XSLT and CSS is that, with XSLT, multiple rendering objects can be created from a single document fragment. For instance, the example below shows a single <netfolder> element mapped to several HTML visual constructs. What XSLT offers is the possibility of creating your own formatting objects from built-in formatting objects made available by the rendering language (with CSS, you are constrained to the formatting object primitives of the user-agent).

In the following example, the <netfolder> element needs to be mapped to a visual object that is not a built-in browser formatting object. With XSLT we can create a one-to-many relationship between an XML tree node and formatting objects, so we construct a new visual object to render the <netfolder> element, as illustrated in Figure 3.

Figure 3: A one-to-many style mapping (Click for larger image)

Here is the source XML fragment:

<netfolder title="MySports">

  <xinclude:include

   href="http://test.com?sql=select teams from sports where id='Didier'"/>

</netfolder>

And here is the XSLT template used to style it:

<xsl:template match="netfolder"> 

  <!-- widget area --> 

  <table border="0" cellpadding="1" cellspacing="0" 

    width="100%" bgcolor= "#FFCC00"> 

    <tr><td bgcolor="##99cccc"> 

      <!-- widget title --> 

      <table border="0" cellpadding="0" cellspacing="0"

        width="100%" bgcolor="#cccccc"> 

        <tr><td colspan="3" width="100%"> 

          <img align="right" border="0" height="15" 

            width="18" src="http://test.com/img1.gif" alt="Remove" /> 

          <img align="right" border="0" height="15"

            width="28" src="http://test.com/edit2.gif" alt="Edit" /> 

          <img align="right" src="http://test.com/detach.gif" 

            border="0" height="15" width="18" alt="Detach" /> 

         <b><font size="3" color="#ffffff" 

            face="Arial"><xsl:value-of select="@title" /></font></b> 

         </td></tr> 

       </table> 

       <!-- widget body --> 

       <table border="0" cellspacing="0" cellpadding="3" 

         width="100%" bgcolor="FFFFFF"> 

         <xsl:apply-templates /> 

       </table>

     </td></tr> 

  </table>

</xsl:template>

Conclusion

XSLT allows either server side or client side styling. It also offers one to many mappings between XML objects (element, attributes, etc.) and formatting objects. Multiple views can be created from a single XML document, even if these views require a re-ordering or modification of the document's tree structure.

CSS is closely mapped to the XML document structure. Some document views are impossible to create with CSS. CSS does not allow distributed processing, it is a client side only styling engine. However, it is a great complement to certain rendering languages like XHTML, HTML or SVG.