Transformations are an idea as old as human thought. Primitive societies had werewolves, werebears, and weretigers. The Greeks had warnings against seeing goddesses bathe, unless one was interested in going to parties stag, literally. During the renaissance, there was Shakespeare's A Midsummer's Night Dream, in which Bottom was made an Ass of. Today we have Jack Chalker's Midnight at the Well of Souls and the Borg from Star Trek. And although the transformations in each of these stories dealt with the physical world and XSLT can affect only XML, they all share many of the same characteristics: Without change, the story can progress no further.
As one who has been working in the programming field for a number of years, I can attest to one thing: About 40 percent of the time, the data is in the wrong format. In ancient times, when great beasts with names such as System major problem. Programs had to be changed or written from scratch to massage the data to make it usable. Changing programs and creating programs has always been a costly undertaking in any day and age.
Now things are different, as time seems to be speeding up. The great beasts are all either dead or behind glass in museums, where people can stare in awe, never realizing that the old 486 machine that they gave to their kids had more power.
Today much of the information that we deal with is in the form of XML, which, interestingly enough, can be transformed by XSLT in much the same manner as Lon Chaney was by the full moon. Thankfully, however, the XML doesn't get hairyunless, of course, we want it to.
11.1.1. XML Magic
Here's the quandary: On the client side, we have XML and we want HTML. It's a real pain in the gluteus, isn't it?
11.1.2. How Microsoft Shot Itself in the Foot
Back in the old days, during the first browser wars, Microsoft released Internet Explorer version 5.0, the first web browser with XSLT support. It would have been a major victory for Microsoft, if it had not been for one little detail. In their haste, they forgot one little thing about the World Wide Web Consortium's recommendations. You see, recommendations are often vastly different from drafts. In an effort to produce the first browser with XSLT support, Microsoft used a draft as a guide.
It was only with the advent of Microsoft Internet Explorer 6 that Internet Explorer started following the recommendation instead of the draft. Personally, I believe that it is a good idea to ignore the old namespace entirely; I think that Microsoft would like to. And although they're currently considered the third most popular browser, at most, individuals using versions 5.0, 5.01, and 5.5 of Internet Explorer comprise only a fraction of the general population. It is a pretty safe bet that you can ignore these web browsers entirely without alienating anyone but technophobes, the White House, and project leaders who use the term blink.
11.1.3. XPath, or I Left It Around Here Someplace
Earlier I stated that XPath was the targeting device for XSLT, which is essentially true. XPath is used to describe the XML node or nodes that we're looking for. As the name suggests, XPath describes the path to the node that we're looking for. For example, let's say that we want the state_name node in the XML document shown in Listing 11-1. A number of different ways exist for locating it, some of which are shown in Listing 11-2.
Listing 11-1. A Sample XML Document
Listing 11-2. Sample XPath
Why so many? With XPath, it is possible to describe complete paths, paths with wildcards, and paths based upon its location, or to describe only the node itself. From a high level, such as an orbital view, it works as shown in Table 11-1.
Listing 11-3. Sample XSL Style Sheet
Pretty cool, isn't it? At first glance, not only is it nicely indented, but it also has the advantage of being one of the most obscure things that you've ever laid your eyes upon. A second glance reveals some details that you might have missed the first time; for example, the select statement looks remarkably like HTML. There is a very good reason for the resemblance: It is HTML. In fact, the xsl:output statement even says that it is HTML, and you can take it from me, xsl:output statements don't lie.
Upon closer examination, some other details might pop out, such as the xsl:template with match="/". From what we covered earlier, the slash means that we're looking for the root node. And while we're examining XPath, you'll find xsl:for-each with select="/states/state". Just in case you're wondering, for-each means exactly what you think it does: Iterate once for every node that matches the predicate.
Another thing that might jump out is the xsl:element node with name="option". This is an alternate method of specifying an output element. The xsl:attribute also does exactly what you'd expect from its name; it defines an attribute of the previous xsl:element. Finally, the xsl:value-of simply copies the node's content from the source document to the output document. In a nutshell, that's pretty much the basics of XSLT and XPath. The next question, of course, is, "So, what does the output HTML look like?" For the answer, check out Listing 11-4.
Listing 11-4. HTML Output
Later, both in this chapter and in others, you'll find more detailed examples of client-side XSLT.
11.1.4. What I Learned from the Gecko
Back when I was first learning XSLT, I was developing with the bare minimum, a text editor and a copy of Microsoft Internet Explorer version 5.01and I was happy! Well, at least for about 20 minutes or so, right up to the point I read the World Wide Web Consortium's XSLT recommendation. But we've already covered that, and after I downloaded a copy of Internet Explorer version 6, I was happy againat least, until I found Mozilla and then Firefox.
My first impression was that there was something wrong with the Gecko XSLT processor, but there was a gnawing doubt. The reason for this was that I'd never personally found an error in a Gecko-based browser, and I had found several in Internet Explorer. So with a critical eye and a hard copy of the recommendation, I began to examine the "bugs" that I had found in the Gecko XSLT processor.
The results came as no surprise to me. Gecko strictly followed the published recommendation, whereas IE seemed somewhat looser around the edges. My problem was that I had developed some bad habits developing in a microcosm and had a tendency to tailor my code to that microcosm. Because of this, I now try out my style sheets in at least two different XSLT processors before I consider them even partially tested.
Let's take a look at how to create an instance of the XSLT processor in Microsoft Internet Explorer and every other web browser on the planeter, I mean Firefox, yeah, Firefox. Listing 11-5 shows a little cross-browser web page that uses one XML Data Island, the first containing the XML while the XSLT is loaded from the server via the XMLHttpRequest object. This is nothing flashy, merely a "proof of concept." It just creates an HTML select object and plops it on a page.
Listing 11-5. XSLT Cross-Browser Web Page Example