To illustrate, suppose that I want to change the XML definition of a customer from the original format of <customer> <id>101</id> <name>Rick Blaine</name> <city>Manchester</city> <state>NH</state> <zip>02522</zip> </customer> into this: <customer id=”101”> <fullname>Rick Blaine</fullname> <address city=”Manchester” state=”NH” zipcode=”02522”/> </customer> Before XSLT came along, I’d have to dust off my programming software, bury myself in a cave for a day, and write a program to do this migration process. However, with XSLT, I can transform the data from one XML format to another nearly instantly, with no true programming required. XSLT is not a programming language as such. In fact, when written out, it doesn’t even look anything like C++, Java, or Visual Basic. Like its XSL parent, XSLT rules and templates are defined by using XML. Most programming languages transform data structures through blood, sweat, and tears. In contrast, XSLT does this work in what can best be described as transforming by example  you provide an example of what kind of information you’d like to see, and XSLT does the rest. For example, the following XSLT snippet changes the name element to fullname in the output document. <xsl:template match=”name”> <fullname> <xsl:apply-templates/> </fullname> </xsl:template> (I get into the specifics of how XSLT template rules work in Chapter 4.) However, as powerful as XSLT is, it needs help to do its transformational magic from our last X-Team member: XPath. XPath specializes in picking out the specific nuggets of information from one XML document in order for XSLT to fit it neatly into another one. 15 Chapter 1: Introducing the X-Team