For the sake of clarity, we are going to be talking very imprecisely and impressionistically about XSLT. We'll add precision later. At its simplest, an XSLT stylesheet takes an input file (an XML tree structure) and transforms it or changes its form somehow. It does this by taking the input tree, piece by piece, and applying transformation rules to each piece. These rules say what to do with each piece of input. We call these transformation rules "templates", and an XSLT stylesheet is basically a set of templates, each one with a condition of operation (when do I happen?) and its own specific task (what do I do?). These tasks will take place if and only if the conditions of operation are met.

In this slide, we see a very simple XML input on the top-left and a corresponding HTML output on the top-right. The boxes at the bottom of the slide are representations of the templates in an XSLT file: They are the conditions by which the XML input is transformed into an HTML output.

You may notice that some of the stylesheet conditions are not met in the the input document. For example, there is no emph in the imput document, so that operation (and it's corresponding HTML em element it would output) is not carried out.

In this slide, we have a very simple XML document and a very simple XSLT stylesheet. Take a minute to think about what the output document might look like if we apply this stylesheet to the input document on the left.

As you probably can guess, the stylesheet shown on the right is going to transform the input tree shown on the left into the elements within the xsl:template. Over the next two slides, we will go over this process step-by-step

The first thing that happens in this example is that we build an output tree—a structural skeleton for the file we are creating. If we look at this diagram we can see that the stylesheet contains an entire miniature HTML document within this template.

When we run this particular stylesheet, we say, in effect I have a paragraph here. What do I do with a paragraph? The stylesheet answers, When I have a paragraph, I create an output tree like this!

Notice that the output tree can include some predefined content (like the head and title in the example).

But where does the content of our input document (i.e. Hello, World!) show up in our output document?

Once we have the output tree, we need to fill it with the content of the input tree. As you may have guessed, the xsl:apply-templates element allows us to do precisely this. Think of it as a conduit from the input tree to the output tree. It instructs the stylesheet to replicate the content of the input tree within the output tree that you have created in your stylesheet. In this case, it grabs the content of the matched paragraph, Hello, World!, and puts it in the appropriate place in the output tree (in the HTML p element).

The processor works much like the dog playing fetch in this slide. The xsl:templates instructs the processor to fetch the content (in this case, text).

We can imagine more complex examples, where the content of paragraph is not only text, but additional elements that one may want to process in some way. A more complex example like this will be covered in the next slide.

Let's take a closer look at an example with more elements to transform. This slide will be useful to come back to as we continue on throughout this tutorial, but let's have an introductory look now. We'll add more details later.

Looking at the templates themselves: You will notice that each template in the stylesheet is represented by an xsl:template element. The @match attribute tells us what element on the input tree we are dealing with. This attribute essentially specifies a condition that has to be met: "if we find the "x" element, perform this transformation." It is important to note that the value of @match specifies a location on the tree. This means that we can provide different rules for elements when they occur in different contexts. We can treat a persName that occurs in body differently than we treat a persName that occurs in the teiHeader. We will learn how to specify the context of the element later in this primer.

Now that we know how the xsl:template interacts with the input tree, we should ask: what does the template do? Inside these templates, there is a snippet of the output tree (in this case, html). There is also the xsl:apply-templates element, which essentially indicates to the stylesheet: don't stop here! go back and process the children or spit out text! Another, more precise way of interpreting this element is to say "go ahead and process any children of the matched element." Without this instruction, the stylesheet logic reaches a dead end.

Perhaps the trickiest thing about XSLT is understanding the order in which things happen, and the logic that determines what comes next. It is important to understand this because, otherwise, you may get some puzzling results.

The processor begins with the root of the input tree (for now, we'll pretend that's also the root element of the document). Then the processor goes to the stylesheet to look for the template that matches that root. When it finds the matching template, it does what the stylesheet says.

If the template contains an instruction to continue applying templates, the processor goes back to the input tree to consider the children of the matched element. For each child, it goes back to the stylesheet to see if there are templates to match it. And on and on until it reaches the end of the stylesheet.

We might be used to thinking of computer programs as sets of steps that will happen in order, where the sequence of events is determined by the computer program itself. XSLT is different in that the ordering of the steps is determined by the input tree. As you can see here in the example, since opener appears in the input document before l, the opener template is applied first, even though it appears after the l template in the stylesheet. Thus, the h2 appears before the two p elements in our output document.

So the process is recursive in that you keep drilling down the input tree and processing the children, and then their children, and so on. But it can also come to a dead end. The drilling-down process requires that we receive an instruction to continue applying templates (using the xsl:apply-templates element).

In the diagram, we can see that the xsl:apply-templates instruction is really the key to everything past step 3. It is this element that allows the stylesheet to process any children of lg (i.e. opener, l, and byline). If this element is absent, nothing else happens. The stylesheet isn't instructed to process more children, so the children are ignored.

Note that although this diagram does not show how each l element is processed, each would treated in the same way as the first two in the output document (that is, transformed into HTML p elements.

Let's try a real example. For this example, you should have <oXygen> downloaded. If you have not set it up already, please visit the tutorial setup page.

In our workshops, we have students download and open these two files: verse.xml verse.xslt

Once you open these files in Oxygen, you will also need to go to the XSLT debugger. This ought to be in the upper right hand corner of the <oXygen> window, and should say XSLT.

If you have not used the XSLT debugger in Oxygen yet, we recommend that you use the XSLT Debugger tutorial to get yourself set up and comfortable with the debugger view.

These are the same input and XSLT files we've been looking at throughout this tutorial. In the Verse example, run the transformation (with the blue arrow) to see the XML file transformed into XHTML (your output document). If you choose an output file and location with the XSLT debugger, you can then open that file in a browser if you wish (or enable XHTML output in the debugger to view the file in Oxygen). With these test files, you can play around with the input document (verse.xml) and the XSLT stylesheet to make changes to the output document.