The Node Tree

Before we start looking at templates in detail, we first need to look at an XML document in the way that an XSLT processor does. When an XSLT processor reads in a document, it generates a representation of the XML as a node tree. As you might expect from its name, the node tree is a bunch of nodes arranged in a tree. Nodes are a general term for the components of an XML document, such as:

•        element nodes

•        attribute nodes

•        text nodes

•        comment nodes

•        processing instruction nodes

The nodes are arranged in a tree such that the tree forms a new branch for every node contained in an element. The relationships between the nodes in the tree are described in terms of familial relationships, so the nodes that an element contains are called its children and an element node is its children's parent. Similarly, all the children of an element node are siblings, and you can also talk about the descendents of an element node or a node's ancestors.

At the very top of the node tree is the root node (for some reason node trees grow down rather than up). You can think of the root node as being equivalent to the XML document itself. The root node's children are the document element and any comments or processing instructions that live outside the document element.

Attribute nodes are a bit special because attributes are not contained in elements in the same way as other elements or text, but they are still associated with particular elements. The element that an attribute is associated with is still known as its parent, but attributes are not their parent element's children, just its attributes.

Note that comments and processing instructions are nodes and part of the node tree, so you need to take them into account if you count nodes or iterate over them. As we'll see in Chapter 7, text nodes that consist purely of whitespace might also be part of the node tree, but you have some control over which are and which aren't.

The view of XML as a node tree is a very natural view because of the way that XML is structured, with elements nesting inside each other. In XML, the relationship between an element and its contents is a one-to-many relationship – each element can only have one parent – which fits the pattern of a tree structure. Processing XML as a tree of nodes is also useful because it means you can focus down on a particular branch of the tree (the content of a particular element) very easily. Other models of XML documents, such as the Document Object Model (DOM) and the XML Infoset, also view XML documents as tree structures, although the models are just slightly different from the node tree that XSLT uses.

You can find out more about the DOM at http://www.w3.org/DOM/Activity.html and more about the XML Infoset at http://www.w3.org/TR/xml-infoset/.

Having a picture of the node tree can be very useful because it lets you view the XML document in the same way as the XSLT processor does. Here's a simplified version of the XML that we're using to hold the information in our TV guide:

Every node tree starts with the root node, so that's the starting point for our diagram. The root node of the tree is like the document itself. The XML document has two nodes at the top level, the xml-stylesheet processing instruction and the document element – the <TVGuide> element. The document element is the top-most element in the node tree, but other things (like comments and processing instructions) can occur at the same level. We can also draw the children of the root node in, as follows:

An XSLT processor doesn't see the XML declaration (the first line of an XML file). The information held in the XML declaration relates to how the XML document has been stored, which the XSLT processor doesn't care about. Also, note that the pseudo-attributes in the xml-stylesheet processing instruction aren't nodes (unlike proper attributes), they're just part of the value of the processing instruction.

Now, the <TVGuide> element has a couple of attributes: start and end. These attributes shouldn't be added to the tree in the same way as the children of the <TVGuide> would be, so we'll place them off to one side and use a different kind of line for them, as follows:

Now let's look at the content of the <TVGuide> element. The <TVGuide> element contains a <Channel> element, which in turn contains a <Name> element and a <Program> element. The <Name> element contains some text. Pieces of text are represented as separate nodes in the node tree, so the <Name> element node contains a text node, as shown here:

The child elements of the <Program> element are treated in the same way – they each have a single text node as a child:

The rest of the tree follows a similar pattern: element nodes having either other elements or text nodes as children. It's often very useful to keep a picture of the node tree of the source document that you're working with close at hand, to help you work out what nodes you're selecting and processing.

Many XSLT editors help with this by providing a simple tree view on a source document. Alternatively, you can use a stand-alone tool such as Mike Brown's Pretty XML Tree Viewer (http://skew.org/xml/stylesheets/treeview/html/).

Part 1 : XSLT Templates XSLT Part 2 : Defining Templates XSLT Part 3 : The Node Tree XSLT Part 4 : XSLT Processing Model XSLT Part 5 : The Built-in Templates XSLT Part 6 : Templates as Mapping Rules XSLT Part 7 : Context-Dependent Processing XSLT Part 8 : Resolving Conflicts Between Templates XSLT Part 9 : Processing with Push and Pull XSLT Part 10 : Using Moded Templates XSLT Part 11 : Summary Buy Beginning XSLT here © Copyright 2002 Wrox Press This chapter is written by Jeni Tennison and taken from "Beginning XSLT" published by Wrox Press Limited in June 2002; ISBN 1861005946; copyright © Wrox Press Limited 2002; all rights reserved. No part of these chapters may be reproduced, stored in a retrieval system or transmitted in any form or by any means -- electronic, electrostatic, mechanical, photocopying, recording or otherwise -- without the prior written permission of the publisher, except in the case of brief quotations embodied in critical articles or reviews.