XML and XSLT Overview

HTML and XML are very similar in syntax, because both are subsets of Standard Generalized Markup Language (SGML). Both are used for marking up documents using tags. XML however has several important restrictions placed on it.

• Tags are case-sensitive. In HTML <P> and <p> can both be used to start a paragraph. In XML <P> and <p> are two distinct tags with two distinct meanings.
• All tags must have a close. HTML has several tags that are "empty" in that there is no text inside the tag. The image tag (<img>) and break tags (<br>) are good examples. Neither one is accompanied by a close tag (</img> or </br>) in XML this is not allowed. Every tag must have a close. The image tag would have to be written as <img></img> and the break tag as <br></br>. There is a special shortened syntax for writing empty tags, and that is to omit the close tag (</img>) and instead place a slash (/) before the close of the open tag (<img/>). Either format is acceptable and <img></img> = <img/>.

• All tags must be fully nested. When closing a tag the only tag that may be closed is the one that was most recently opened. For example the following is valid HTML 3:

  <b>bold, <i>bold and italic, </b>italic</i>
            

  After the italic is opened (<i>) the next thing closed is the initial bold (<b>). This is not allowed in XML. For this to be valid XML it would have to be written as:

  <b>bold, <i>bold and italic, </i></b><i>italic</i>
            

  The tags are now closed in the order that they were opened. This is called being "fully-nested."

• All attributes must be quoted. In HTML the double-quotes (") surrounding attributes were not required if the attribute's value was numeric. In XML this exception is not allowed; all attributes must be in quotes.

There are two primary reasons for the number of restrictions that have been placed on XML in comparison to HTML. The main one is simplicity; a program to deal with XML can be much simpler than a program that has to be prepared with the intricacies and exceptions of HTML. The program can use less memory and can be less processor intensive which is ideal for smaller devices like wireless phones and pda's. Another consideration has to do with the way that the world wide web is developing. There are many people producing HTML for publishing who have little or no experience with HTML. This, along with poorly written editors, and browsers including proprietary extensions to HTML is producing a huge variety in the types of documents that can be found on the web. As the variety of documents gets wider, browsers have to become larger and more intelligent if they are going to render the HTML as the author intended. The simplicity and restrictions placed on XML does not restrict any of the expressiveness; it does however force people to write correct documents.

To speak of HTML and XML like this gives a false impression that they are more related than they are in reality. HTML is a specific set of tags for describing the structure of hypertext documents. XML is not a specific set of tags at all, rather it is a set of rules for describing what properties XML based languages must have.

There could be hundreds or thousands of different languages that conform to the rules set out in XML. XML as a format is still growing in popularity, but many interesting languages already exist:

The basic benefit of XML is the same as that of HTML: there exists a specification somewhere saying how a document may be marked up and so long as I conform to that specification my document should render correctly in any web browser that someone wants to use. An XML document will not necessarily describe a webpage, but the contract specifying what tags are allowed where still exists and I can write my documents according to the specification and programs supporting that type of markup should deal with my document with no problem.

There are two main ways that the contract (what tags are allowed where, called a Document Type Definition (DTD)) is specified. The original way was to use SGML which is the same way that HTML is specified. SGML simply sets out a Backus Naur Form (BNF) for the document. A more modern way of laying out the document is an XML based language called XMLSchema. XMLSchema is more complex and allows a tighter specification of the tags as well as allowing templates for different types to be created. Another advantage is that with XMLSchema you don't need a standalone parser to parse the SGML, the same parser can parse both the Schema and the document. SGML and XMLSchema are both languages in their own right and sufficiently complex not to cover here.

Another big advantage of XML has to do with parsing. Because of the restrictions placed on the language it is possibly to create a standard parser that will deal with any XML document. Creating configuration files in XML allows the author so specify what values are allowed in the DTD and also saves the author from having to parse the configuration file herself. There are two main classes of parsers that can be used depending on the needs of the application:

• Simple API for XML Parsing (SAX): This is an event based API. Each time that a new tag is opened or closed a callback is made to the main program. This keeps the whole document from having to be stored in memory at one time. Also if the entire document is not needed parsing may be stopped at any point.
• Document Object Model (DOM) Parsing: One perspective on an XML document is to see it as a tree where tags nested inside of other tags are considered children of the original tag. A DOM parser creates a tree that can be searched for different nodes and manipulated in a variety of ways. This gives the programmer a more comprehensive view of the program, it requires the entire document be in memory at once however and that the whole file be parsed before the tree is available.

One way to view an XML document is as a tree. For instance given this simple XHTML document:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
  <html>
    <head>
      <title>Will's Webpage</title>
      <link rel="stylesheet" type="text/css" href="main.css" />
    </head>
    <body>
      <h1>Welcome!</h1>
      <p>
        Hello, everyone. Welcome to my little spot on the world wide web. 
        Hope you are having a nice day.
      </p>
    </body>
  </html>
      

You will notice that since this is a valid XML document as well as being HTML the empty link tag ended with a />. Also all of the <p> tags ended with a </p>. This is not just an authors preference it is required for this to be valid XML.

This document can be represented as a tree like this:

As you can see each tag is a child of the tags that it is nested inside of. If you use a DOM parser in dealing with your XML files then this is the basic layout that you will deal with. In XML there is only allowed to be one element at the very top (called the "root" element; it is <html> in this case.) This tree layout is also what you deal with in XSLT.

XSLT is a functional language, this means that unlike an inperative language like C you will not write your program as a set of procedures for accomplishing a task. One analogy for functional languages is working in a spreadsheet; instead of specifying how to compute the value for an individual cell you express the value of that cell as a relationship of other cells and then let the computer figure out how to get the answer. In XSLT you will write a set of templates to "match" different nodes and then the program will run by matching your input document with the templates.

For our example we are going to step through a simple set of templates to transform this document from the DocBook that it is written in into XHTML for presentation on the web. DocBook is a fairly complex language and by no means will these templates convert all of DocBook to XHTML. The most commonly used program to deal with DocBook is called Jade. It is written using another transformation language, Document Style Semantics and Specification Language (DSSSL) and will handle the source for this document it may be though that we have a special need that Jade does not address, so writing a new set of transformations is not just an exercise. For this though we need only deal with the few tags used in this document which are:

Because XSLT is an XML based language we will have to create a single root element to contain all the templates. A couple of other things that the basic layout will do is specify a doctype and a namespace. I haven't talked about these in detain, but namespaces are ways to have multiple XML languages in the same document. Say you have a report with some equations and graphs in it. The base report could be written in XHTML, but for the equations you could mix in some MathML and for the graphs some SVG. A namespace simply precedes the tag and is separated by a colon. A namespace can be any string, but for this example I am going to use xsl: to represent the XSLT namespace.

<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
  <xsl:output
   method="xml"
   standalone="yes"
   indent="yes"
   doctype-public="-//W3C//DTD XHTML 1.1//EN"
   doctype-system="http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"/>
    <!-- This is a comment in SGML (thus HTML and XML
       - All of the templates will go in this space and any tag that
       -  is not prefaced with <xsl: will go to the output document
      -->
</xsl:stylesheet>
        

Each template now will just be a <xsl:template> child of the main <xsl:stylesheet> root element.

Because XSLT is a functional language we don't have to worry about going in any certain progression. We can start with the easier templates and work our way to the more complicated ones. The easiest is going to be <para> because there is a one-to-one correspondence between DocBook and XHTML. Both have a paragraph tag and we are not adding any formatting. So, we simply have to create a template that will match the <para> tag and will place the contents of that tag inside XHTML <p></p> tags. Such a template would look like this:

<xsl:template match="para">
  <p><xsl:apply-templates/></p>
</xsl:template>
        

Seems simple enough. In addition to the <template> tag you will also notice an <apply-templates> tag. <apply-templates> just instructs the processor to do another set of matches. It can take an optional "select" attribute to choose a set of nodes to match, but by default it simply matches the children of the current node.

Another tag which is relatively simple is <programlisting>. Let's say that in our output we want for a program listing to be preformatted and enclosed in a gray box. In XHTML we would do this with a <pre> tag and a special style. To make it easy to change the appearance of the tag instead of placing style information in all the <pre> tags we will use the "class" attribute to designate that they are all of a similar type. So the template would look like:

<xsl:template match="programlisting">
  <pre class="listing">
    <xsl:apply-templates/>
  </pre>
</xsl:template>
        

The <mediaobject> tag for DocBook is fairly sophisticated. We are going to only allow it to include a single image in a document. The structure of the tag will be assumed to be:

<mediaobject>
  <imageobject>
    <objectinfo>
      <title>Description</title>
    </objectinfo>
    <imagedata fileref="path/to/file"/>
  </imageobject>
</mediaobject>
        

This is obviously a much more sophisticated set of tags. As I mentioned before we are only using about 3% of the functionality of <mediaobject>. All of this information is going to map to a single <img/> tag. Specifically we are going to select the values of children of <mediaobject> using a special syntax where values inside of {} are replaced with the value of selecting those children. The template would look like:

<xsl:template match="mediaobject">
  <img
    src="{imageobject/imagedata/@fileref}"
    alt="{imageobject/objectinfo/title}"/>
</xsl:template>
        

There is also a <value-of> tag in XSLT that does the same thing as the {} notation. It can't be placed inside of a tag like the {} notation because that is not valid XML. If you wanted to use the <value-of> tags instead you would have to use the <element> tag. <element> is replaced with a tag specified by the "name" attribute in the output. For instance this image tag would look like:

<xsl:template match="mediaobject">
  <xsl:element name="img">
    <xsl:attribute name="src">
      <xsl:value-of select="imageobject/imagedata/@fileref"/>
    </xsl:attribute>
    <xsl:attribute name="alt">
      <xsl:value-of select="imageobject/objectinfo/title"/>
    </xsl:attribute>
  </xsl:element>
</xsl:template>
        

One advantage of this syntax is you can use the decision structures that XSLT has to decide the value of attributes. Say for instance you decided that if they didn't include the <objectinfo> then you wanted to leave the "alt" attribute out. The template could be written as:

<xsl:template match="mediaobject">
  <xsl:element name="img">
    <xsl:attribute name="src">
      <xsl:value-of select="imageobject/imagedata/@fileref"/>
    </xsl:attribute>
    <xsl:if test="count(imageobject/objectinfo) > 0">
      <xsl:attribute name="alt">
        <xsl:value-of select="imageobject/objectinfo/title"/>
      </xsl:attribute>
    </xsl:if>
  </xsl:element>
</xsl:template>
        

The language that is being used to specify the child nodes to select is called XPath and it is a fairly robust language for selecting nodesets from trees. The default is to select children, but it can do more complex sets like ancestors, preceding siblings, nodes with certain attributes, and nodes a certain depth in the tree.

<table> is also fairly straightforward in how it translates to XHTML. Both DocBook and HTML 4.0 are based off of the Continuous Acquisition and Life-Cycle Support (CALS) table model. This is slightly different than the HTML 3.0 table model, but is fairly simple in general. From the HTML 4 SGML DTD the model is:

<!ELEMENT TABLE    - - (CAPTION?, (COL*|COLGROUP*), THEAD?, TFOOT?, TBODY+)>
<!ELEMENT CAPTION  - - (%inline;)*  -- table caption -->
<!ELEMENT COL      - O EMPTY        -- table column -->
<!ELEMENT COLGROUP - - (COL)*       -- table column group -->
<!ELEMENT THEAD    - O (TR)+        -- table header -->
<!ELEMENT TFOOT    - O (TR)+        -- table footer -->
<!ELEMENT TBODY    O O (TR)+        -- table body -->
<!ELEMENT TR       - O (TH|TD)+     -- table row -->
<!ELEMENT (TH|TD)  - O (%flow;)*    -- table header cell, table data cell-->
        

If you are familiar with BNF then this ought not be too difficult to read. The model for DocBook is about the same except instead of having <tr> there is <row> and instead of <th> or <td> there is <entry>. Rather than having a single template to create a table however we can break it up into several distinct templates:

<xsl:template match="table">
  <table>
    <xsl:if test="count(title) > 0">
      <caption><xsl:value-of select="title"/></caption>
    </xsl:if>
    <xsl:apply-templates select="child::*[name() != 'title']"/>
  </table>
</xsl:template>

<xsl:template match="thead">
  <thead><xsl:apply-templates mode="header"/></thead>
</xsl:apply-templates>

<xsl:template match="tbody">
  <thead><xsl:apply-templates/></thead>
</xsl:apply-templates>

<xsl:template match="row">
  <tr><xsl:apply-templates/></tr>
</xsl:template>

<xsl:template match="row" mode="headed">
  <tr><xsl:apply-templates mode="headed"/></tr>
</xsl:template>

<xsl:template match="entry">
  <td><xsl:apply-templates/></td>
</xsl:template>

<xsl:template match="entry" mode="headed">
  <th>xsl:apply-templates/></th>
</xsl:template>
        

The <section> template is going to be perhaps the most complicated. Sections are going to be numbered according to their depth, so the third section inside of section one would be Section 1.3. This number is handled automatically by XSLT which is fortunate because counting in a functional language is difficult. Also we are going to place an anchor at the beginning of each section so that later we can link between them. The anchoring for this document is based on each <section> in the DocBook source having an "id" attribute with a value that is unique for the document. This is not an uncommon property for DocBook documents because that unique id is used sometimes in cross referencing.

We could put the sections in a list to indent them on the screen, but instead we will signify the depth with both a change in the number and a change in the font size.

<xsl:template match="section">
  <a name="{@id}"/>
  <xsl:element name="div">
    <xsl:attribute name="class">
      <xsl:text>section-</xsl:text>
      <xsl:value-of select="count(ancestor::*)"/>
    </xsl:attribute>
    <xsl:text>Section </xsl:text>
    <xsl:number level="multiple" format="1.1."/>
    <xsl:text> </xsl:text>
    <xsl:value-of select="title"/>
  </xsl:element>
  <xsl:apply-templates select="child::*[name() != 'title']"/>
</xsl:template>
        

As you hopefully can tell I create a <div> in the output HTML with a class attribute of section- and then then depth of the section in the tree. Then I use <number> to create my numbering and put the contents of the title tag after the preface. You might have noticed earlier that I am using <text> tags to surround output text that is not inside of a tag. This is not strictly necessary. If you do not do it this way any whitespace before or after your text may get included in the output document which is not usually a problem in HTML, but can cause issues occasionally.

We are pretty much done except for one obvious issue. There is no base for the document. Nowhere in the templates we have defined are the <html> tags placed in the output. When the XSLT engine starts processing it will try to match the root of the document first. In this case the root is <article>. To put the groundwork down for the document we will write a template to match <article>. Something that might be nice in a document like this would be to have a listing of the different sections so we can jump around, so we will make one of those too. The templates would look something like:

<xsl:template match="article">
  <html>
    <head>
      <title><xsl:value-of select="title"/></title>
      <link rel="stylesheet" type="text/css" href="document.css"/>
    </head>
    <body>
      <h1><xsl:value-of select="title"/></h1>
      <hr style="width: 45%;"/>
      <xsl:call-template name="toc-outline"/>
      <hr style="width: 45%;"/>
      <xsl:for-each select="section">
        <xsl:apply-templates select="."/>
        <xsl:if test="count(following-sibling::section) > 0">
          <hr style="width: 25%;"/>
        </xsl:if>
      </xsl:for-each>
      <xsl:if test="count(articleinfo/legalnotice) > 0">
        <hr style="width: 85%;"/>
        <xsl:apply-templates select="articleinfo/legalnotice"/>
      </xsl:if>
    </body>
  </html>
</xsl:template>

<xsl:template name="toc-outline">
  <xsl:if test="count(section) > 0">
    <ul>
      <xsl:apply-templates select="section" mode="outline"/>
    </ul>
  </xsl:if>
</xsl:template>

<xsl:template match="section" mode="outline">
  <li>
    <xsl:element name="a">
      <xsl:attribute name="href">
        <xsl:text>#</xsl:text><xsl:value-of select="@id"/>
      </xsl:attribute>
      <xsl:call-template name="section-name"/>
    </xsl:element>
    <xsl:call-template name="toc-outline"/>
  </li>
</xsl:template>

<xsl:template name="section-name">
  <xsl:text>Section </xsl:text>
  <xsl:number level="multiple" format="1.1."/>
  <xsl:text> </xsl:text>
  <xsl:value-of select="title"/>
</xsl:template>
        

To generate this correctly you will need several things: