The XSLT Processing Model

The XSLT processing model: overview

So let’s come back now and consider in more detail how an XSLT stylesheet runs and what it does. What we’re talking about here is something called the XSLT processing model and it is essentially the set of rules that direct how the stylesheet will run and what it will do, in what order. These rules are actually fairly simple once you’re familiar with them, although they’re not perfectly intuitive at the outset--so we’re going to step through them in detail with an actual example and follow how they work.

Essentially we are starting with the root of the input document, and working our way through that tree, based on the templates we find in the stylesheet.

The XSLT processing model: matching the root

So what’s the first rule? we remember this from our earlier, more informal look:

• start with the root of the input document (what is it?)
• and then ask: is there a template that matches this element I’m considering? (is there?)

The XSLT processing model: applying a template

If I do find a template that matches the element I’m considering, I apply that template:

• in this case, what is it doing? (writing out the first few layers of the output tree, and including a little bit of literal text)

The XSLT processing model: processing children

So what did we just do? We applied a template, which entails:

• putting out the output elements
• writing out any literal text
• and one thing further: if there are instructions to apply templates, then process the children of the matched element

So what is the element we just matched? (TEI)

And it does include instructions to apply templates, which means that we... (process the children of the matched element, i.e. the children of TEI

So what are these children? text: what do we do with this? What rule applies in this case? (no template matches it: so we apply built-in processing rules, which say that we... (spit out any text, and process any children)

So what are the children of text?...front: what do we do with this? What rule applies in this case?

There’s a template that matches front, but what does it tell us to do? What rule applies in this case?... there are no instructions to apply templates, so this part of the process stops there. There’s no output from front.

Does it stop altogether? Or are there other loose ends that will keep the process going?

The XSLT processing model: chugging along

There’s another child of text, namely body, so our built-in stylesheet rule of process the children applies here and allows us to proceed to the body element

So what happens here? (another output element is generated, and inside it, additional templates will be applied)

The XSLT processing model: processing more children

Next we start processing the children of body, and we have two templates here that do somewhat similar things; what are we matching here?

What if we had wanted to just match any head in the input document?

Why do it this way? Why distinguish between two different locations for head

The XSLT processing model: a final round

Finally we’re getting to the last of the children in the input document... What is happening here? What rules apply when we get to emph? (There’s no template that matches, so we apply the built-in rules, which say...if what we’re processing is text, spit out the text)

The XSLT processing model: a last look

Now we can back up again and study the whole thing as a finished product: the input, the stylesheet, and the output. Any questions?

Namespaces and languages

You’ve probably already noticed that we’re dealing here with three languages:

• The language of the XSLT stylesheet itself (which is a language containing elements like tempate and apply-templates)
• The language of the input document (in this case, TEI)
• The language of the output document (in this case, HTML)

Within the stylesheet itself, we need to keep these three different languages distinct from one another, so that the processor always knows what piece of what tree it is dealing with. We do this with something called namespaces. (Does everyone understand namespaces? Quick review on the next slide if necessary...)

Each of these languages plays a specific role in the stylesheet ecology and gets referenced in a distinctive way:

• Let’s take the simplest first: the output tree, which is being treated transparently in our examples: it doesn’t use a namespace prefix, and this is because we have declared that the entire stylesheet is in the HTML namespace (we did this with the namespace declaration attribute-like thingy: xmlns)
• The next fairly simple case is the input tree, which also looks as if it’s not getting a namespace. How are we keeping this separate from the output tree? The trick here is that the input tree is always accessed via these match and select (and similar) attributes. These attributes all access the input tree via XPath, and up at the top, we provided a default namespace for all XPaths (via xpath-default-namespace)
• And finally, the stylesheet document has its namespace specified as the XSL namespace (the default namespace for the stylesheet is already set to HTML) so all of the stylesheet elements have a namespace prefix.