World of XSLT craft: AKA World of Warcraft site WoWarmory.com

Several years ago, there were actually people who debated whether XSLT was useful or not.

Once they famous white paper on AJAX programming was written by the web developers who modernized Amazon.com with AJAX components and a bevy of web 2.0 features now commonly associated withe the social web.

The most vociferous opponents of XSLT that I encountered were those were software developers who did not know XSLT and did not want to learn it. These were folks who seemed to only know and use one programming language and it was C++ or Java.

Others, including a fellow Java programmer I worked with named Praveen, dived right in and wrote some scripts in it without the slightest delay or opposition.

Apparently, Blizzard utilized people like the latter when WoWarmory.com was developed.

The World of Warcraft Armory site is a free web site created by Blizzard for its fans & customers to view details about any player character in the game. The information is intricately detailed and lavishly presented.

The character level, race, guild, skill levels, equipped gear - and tons of other things - are all easiy examined using the web site.

What a lot of people do not know is that the pages on this web site are all defined as XML files - not HTML, XHTML, Flash, etc.

Sure, what is rendered in your web browser is HTML or XHTML but that is not how the developers authored the page.

Here is a list of some XSLT stylesheets on the WOW Armory web site:

item-info.xsl

Generates an XHTML 1.0 web page for an item like . Outermost elements of the page are contained in this tiny XSLT template, along with references to two Javascript files for implementing AJAX. Then, the details of the particular item are all rendered using XSLT stored in item-info-data.xsl XSLT file.

item-info-data.xsl

Lengthy yet simple XSLT script that generates virtually the entire page content for an item detail web page.

item-info.xml

Tiny, 12-line text file containing all the data describing an item in the World of Warcraft game. Just the data. Nothing at all pertaining to how the item is to be presented is in this file with the exception of the bare filename of the icon file, sans file type suffix: e.g. inv_gauntlets_19. This XML data file includes a processing instruction at the top:

That is what tells the browser to download and execute item-info.xml.

Now, what is clever about this approach? Is it just fancy technophilia or does it serve a raal purpose?

The answer is this serves as a great solution to a number of problems.

1. The item-info.xml file, containing the detailed definition of the item, is tiny. It can probably be cached since nothing in it ever changes. In fact, it could probably be stored out on the file system - no need to dynamically generate it. The 2 XSLT files, item-info.xsl and item-info-data.xsl, can definitely be cached.
2. The little data file is completely application independent, platform independent, and presentation independent. In other words, any web developer, designer, or programmer with modern skills or tools can create his own presentation of this data. Their only limitations are what their intellect allows them to do with the data and what their artistic ability allows them to do with its presentation. Professionals have these skills in spades. So all kinds of wonderful things are getting generated by third-party developers from this site.
   

By giving this overview of how the World of Warcraft Armory (wowarmory.com) web site is constructed, I hope I have done several things.

1. Demystified the web site a little for you. Hopefully, you can see now kind of how it works. If you had glanced at it before but did not know how to connect the dots of how that perplexingly tiny data file shown by View Source command in your browser gets turned into a beautiful web page - now you know!
2. Explained the benefiits Blizzard is deriving from this solution both from economic (less network bandwidth, less server load, everything cached) and community empowerment (infinitely repurposeable data) standpoint.
3. Demonstrated that XML and XSLT technology are indeed worthwhile from practical business standpoints as well as a developer/designer technical point of view.

In this post, I have just explained how the game items are served and presented. I have not detailed characters - or covered guilds, guild rosters, and so forth. I think that would be interesting but I will save deconstructing these for another time.

If you think this was helpful, please post a comment.

Safari Guide

If you are using Safari web browser on the Mac, there is a handy little utility that works with it and lets you put your XSLT chops to some practical use.

The program is called Safari Guide. You run it alongside the version of the Safari web browser that comes with Mac OS X 10.4.

Safari Guide author Todd Ditchendorf:

New in version 1.3: XSLT!
* XSLT! -- Now you can also evaluate remote XSLT stylesheets or arbitrary XSLT source code against the frontmost Safari window.

* New in version 1.2: JavaScript support!

JavaScript! -- Now you can also evaluate JavaScript expressions against the frontmost Safari window.
Safari Guide is now a multi-window application... you can have multiple Safari Guide controller windows open simultaneously.


* New in version 1.1: XQuery support!
Using Safari Guide is easy...

Open a webpage or XML document in a Safari browser window.
Launch Safari Guide and type an XPath expression into the XPath text field, or an XQuery into the XQuery text area.
Click 'Evaluate' and watch the matching sequence of nodes matching your expression from the front Safari window appear.

Screen scraping is pretty popular. If not among programmers that have to do it, at least among those who tell them what to do.

Sometimes it is a bit of a pain. This program could make it a little less work to do, since you can test things interactively - and come back and test them that way a few weeks later to make sure they still work. Or tinker with the XSLT enough to create a fix, if you are informed the XSLT you wrote previously no longer works.

I rather suspect that people with the technical skills to use XSLT are using it to create their own ad hoc web page summaries. One indication of this is Firefox 2's capability to do exactly that. The Mozilla organization calls this feature Microsummaries.

Microsummaries are basically just binding an XSLT spreadsheet to selected data in a pre-specified collection of web pages. What is kind of cool, is that Firefox helps you create these summaries by selecting portions of the rendered HTML page itself to create them.

There might be some debugging/refining coming into play afterwards. I think the Safari + Safari Guide combination could be a useful way to carry out that debugging/refining.

Technorati tags: safari, xpath, xquery, xslt, javascript

Microsummaries feature of Firefox 2 which is at alpha 3

Firefox 2 will have a new feature in it called Microsummaries.

Firefox 2.0 recently issued an alpha 3 release. [Note the Microsummaries feature was already in it before this release. They are asking their alpha testers for continued help in testing this feature.]

The fact that Microsummaries are already implemented, and the nature of the feature - straight forward XML syntax, incorporating the already-implemented standards-based XSLT stylesheet mechanism - gives me a whale of a lot of confidence that this feature will not be cut before Firefox 2 ships.

Microsummaries in Firefox will almost certainly cause a spike in demand for and interest in XSLT stylesheet development.

One application will be to read all the documents that have been annotated with Microformats.

The Microformats will call attention to things like addresses, dates, product/service reviews (e.g. for movies, books, websites, etc.). For example, they will clue in the Technorati weblog social blog tagging/indexing/searching service that they are there.



Then, Firefox 2 Microsummaries can make those very things stand out on a page. In fact, they can cull them from a number of pages, winnow out the other content/verbage, and just present the information from the Microformats.



Along the way, they can sort the information, count it, and even sum up numbers in it. Pretty heady stuff.

People who have written XSLT pages already know something about them that most other people do not. XSLT can be used for a lot of things that have nothing to do with styling a web page.

They are a powerful tool for processing information that is in XML format. Thanks to Microsummaries, they will have more information on which to do their thing.

Web surfers will spend less time searching for information and have more time & ways to use the information.

The closest thing to Microsummaries in web browsers right now, is the optional Grease Monkey extension for Firefox 1.0 or 1.5. It sounds pretty neat but it works with Javascript. I do not think it works with XSLT.

Personally, I would rather write a simple stylesheet and wrap it in a Microsummary, than install a Grease Monkey script from the Grease Monkey script repository (Userscripts.org).

I think writing the XSLT to put in a new Microsummary would go faster than checking the leneage and pedigree of the Javascript. At least in some cases, it would. Time will tell.

I really am extremely XSLT

I taught myself XSLT back in 2001, when I stumbled over the open source Apache Cocoon software.

Cocoon used XSLT all over the place. The way it generated HTML web pages out of handy little XML data files was amazing.


I used it for some kind of project status reports or something like that back in 2001. Not much. I think that was about it.

I continued to study it and read quite a bit about it, grocking more and more about how it could be used and what it would be good at doing.

In 2002, I was fortunate enough to land a reports generating project.

Without going into details, it was pretty awesome.


The technique I came up with pulled Java business objects off a server, transmogrified them into XML, used XSLT I wrote for each report to format them into an XML based report format I invented, and then ran the output of that first XSLT transformation through reusable XSLT transformation I wrote for each file format.

So, in simple terms, the level of software reuse I got was amazing.

  (1 object-to-XML converter in Java) +

    (1 XSLT script per report) +

    (1 XSLT script per output file format)

Notice that is a plus sign - not a multiplication symbol - between the two XSLT terms. This is not an m * n cost. This is an m + n cost.

In effect, I created a way to do reporting deeds - and they're done dirt cheap, to cop a phrase from Dire Straits.


There were 3 file formats directly supported: HTML (styled with XSLT), XSL-FO, and GMR (Gnu Gnumeric spreadsheet). Free, open source software was used to transform those documents into other file formats - such as XLS (Microsoft Excel spreadsheets), PDF (Adobe Acrobat reports), and so on.


That project really drove home to me the excellence of XSLT and just how far you could go with so little effort, using XML for mundane IT work. And if anything is mundane IT work, it is generating business reports.

Another thing I was pleased about was the software costs of the project: $0. That is right, not one dollar was spent on purchasing software for this project. All the libraries, all the tools, all the frameworks, all the servers used were free.


Looking around and talking to other people since, many organizations will pay tens of thousands or hundreds of thousands of dollars to buy a workable report-generation scheme for Java - and they still have programming costs with each report they generate!.

I thought that was silly. Still do.

Some projects with odd reporting requirements will need special software. If they hunt around, I know they will find free tools they can use to slash their costs with little effort.


I have been a colossal XSLT fan ever since that reporting project. I sort of was before. Afterwards though, I had a huge excuse.