Eddie Welker.com

I’ve been… not away, but simply taking pictures. I should get back to writing… more JavaScript (to refresh myself), more XLST, a little Django/Python here or there. I’ll do that soon.

On Mar 31, 2009, at 11:45 AM, Edward Welker wrote:

>> Aaron wrote:
>> This may be one of the best URLs I have ever seen:
>> http://www.ringling.com/FlashSubContent.aspx?id=11654&parentID=320&asset
>> FolderID=340
>>
>> Just looking at it, I can tell exactly what I can expect when I click
>> it.

***

To me, that URL tells a delightful children’s story…

FlashSubContent = a wonderful fantasy world
[elephant] id = 11654 [Dumbo]
[elephant] parentID = 320 [Mrs. Jumbo]
[cage] FolderID = 340 [because they took her Dumbo away, and Mrs. Jumbo got angry, so she had to get locked up]
aspx = evil clown makeup wearing Microsoft employees who locked Dumbo’s mother up

-e

I ran across a mention of “Prototype-Based Programming” back when I was first learning JavaScript.  I thought it would be an interesting read, but forgot to bookmark it, and forgot to look into it further.  Once I finally remembered it, it proved hard to find (and an expensive gamble from Amazon), until I found it through NIH’s interlibrary loan system.

I was quite excited to get my hands on a copy of this book, I was interested in learning more about the general theory that went into languages with prototypal inheritance.  I thought this would allow me a special insight into JavaScript.  However, as I found reading it… despite it’s 1999 publication date, JavaScript wasn’t even mentioned in the book!  Regardless, I found parts of it to be quite interesting and insightful.

The book is broken up into three sections (as mentioned on the cover), Concepts, Languages, and Applications.  Each section has 4 associated chapters which are really various papers, some of which seem to be difficult to find elsewhere.

The first section, “Concepts” was the most interesting. The first was titled “Classes vs. Prototypes: Some Philosophical and Historical Observations.”  This chapter provided a nice introduction to the topic, including the history of classification, going back to Aristotle and proceeding to Ludwig Wittgenstein who had an interesting example about classifying the characteristics of an item as simple as a “game”.  It goes on to transition to a programming perspective.  A point that is made repeatedly throughout many chapters that the idea of classical inheritance necessitating construction from the top (superclasses) to the bottom (subclasses) is inherently contradictory to the way humans think.  When unfamiliar with a domain, a person can more easily deal with concrete examples, and only discern the abstract general form after discovering these patterns in the concrete cases.  Though unable to put my finger on this idea, I’ve experienced it a number of times when programming myself, and couldn’t agree more.

The next chapter, “Classifying Prototype-based Programming Languages” sought to categorize the theoritical aspects of different prototypal languages.  This is the chapter where I most missed the reference to JavaScript, but I may look into doing that myself some other day.  “The Stripetalk Papers: Understandability as a Language Design Issue in Object-Oriented Programming Systems”, made an argument that prototype based systems could be used to enhance the learnability of languages.  Finally, the chapter “Classes versus Prototypes in Object-Oriented Languages” looked at the advantages and disadvantages of class-based and prototype-based languages.  This chapter was quite interesting, however brief.

The second section, “Languages”, lacking JavaScript, was less useful than I had hoped.  “Programming as an Experience: The Inspiration for Self” was interesting as it described the thought process going into creating the Self language, and expanded some of the ideas presented in the book’s second chapter.  Alas, I’ve haven’t yet gotten around to learning Self, but the ideas and history presented were interesting in the abstract.  “NewtonScript: Prototypes on the Palm” was interesting mostly because of it’s Lisp-like syntax and it’s description of internal closures, while “The Prototype-Instance Object Systems in Amulet and Garnet” took an in-depth look at the implementation of these two languages.  I only skimmed the “Omega: Statically Typed Prototypes” chapter, as it was rather brief, and I don’t feel confident enough (or have any real desire) to enter the static-typed/dynamic-typed languages argument.

The final section, “Applications”, was where this book showed it’s age.  “Self includes: Smalltalk” involved translating Smalltalk programs into Self, which is interesting, but I don’t see much practical application for this today (maybe if you’re translating Ruby to JavaScript? Not sure).  “Using Prototypes for Program Restructuring” demonstrated the use of an algorithm that would help to restructure code into a slot-based prototype system in a application called Guru.  “Prototype-Based Programming for Abstract Program Visualisation” ended up being skimmed, because while the topic matter seemed interesting, the demonstrations from the black-and-white mac era looked totally antiquated, and I am sure that they have been written many times in other languages since the writing.  Finally, “Agora: The Scheme of Object-Orientation, or, the Simplest MOP in the World” detailed the Agora language, a pure OO language which relied only on objects and message passing, while being implemented as a reflective language inspired by Scheme, of all things. Weird, but interesting.

You know as well as I do that computer technology is a moving target, and something published in 1999 will be outdated to a certain degree.  The good part of this book is that the abstract notions in it are rather timeless, as they have been built on over time.  Parts of this book may be out of date, but parts aren’t, and regardless, it’s an interesting read.  I recommend it, if you’re even slightly interested.

Based on the title, Expert Python Programming, (by Tarek Ziadé) I had expected a book covering the Python language… syntax, advanced data structures, maybe some functional programming… stuff like that. This book surprised me. Rather, it contains a hodgepodge of information about the world of Python development, from setting up editors to distributed version control to application distribution. “Expert Python Programming” does contain some information on the Python language itself, but not as much as I would have hoped. While it does contain a good amount of useful information, overall, I’d have to say that it misses the target.

Quickly summarized, the book contains 3 chapters on package management and distribution, 2 on syntax, 2 on optimization, and one each on language setup, naming conventions (style guide), version control, project management, documentation, test-driven development, and design patterns. Based on the content, I might have titled this book “Expert Python Development Practices”, and think I would have been happier reading it in that case. The discrepancy between the title and the content is especially bothersome to me, since it would be easy to assume this book focused specifically on programming, rather than code management.

Expert Python Programming’s greatest asset is the number of tools and utilities that it covers. As a mostly casual Python programmer, there were a number of things that I learned, especially with regard to package management and distribution. I’ve never needed to build a package, and never used Atomisator or zc.buildout before, so I found these chapters rather interesting (though not personally useful at the moment). To be sure, when I need to use these, this book will the be the first place I come.

I was familiar with a decent amount of the information in the documentation, test-driven development, and style-guide chapters from reading some of the Python Documentation and a few of the PEPs (Python Enahncement Proposals). These chapters would be good for anyone who doesn’t want to have to go and search for this information on their own, and I think it would be rather handy to have all of this information in one place.

The weakest part of the book were the chapters focusing on Python itself. The majority wasn’t anything particularly groundbreaking here that I haven’t read elsewhere, while the interesting sections, such as “How Python Deals with Memory” and “Multithreading” were short and not particularly detailed. The sections on optimization were nice, but limited.

My only other observations were that the Mr. Ziadé at times made statements of opinions that he presented as fact. I would have preferred him presenting code as evidence towards these opinions and leaving the reader to decide for themselves. To be fair, these moments were infrequent enough that they weren’t that bothersome.

Through no fault of the author, Packt Publishing did let a number of small editorial mistakes slip through. Additionally, I found myself often wanting a better presentation of code samples. The overall design of the code examples and body text of the book ended up being quite similar, and I wish that they had made a bigger differential between the two.

Personally, I was disappointed that the Expert Python Programming’s didn’t feature aspects about the language as prominently as the everything else. I can only recommend that any potential buyers of this book borrow a copy, or make a trip to the local bookstore to flip through it first. Otherwise, this may not be the book that you were looking for.

My orchestra is playing Sibelius 1 tomorrow in Columbia, Maryland. It’s not my favorite symphony, seems a little naive, though he wrote it when he was 35. If you wanna check it out, first check out the site.

I love reading programming books, especially to learn a new programming language.  Learning XSLT, I read a large number of books, as there are quite a few available.  The quality of the XSLT books struck me as particularly all over the place, some were quite good while others weren’t even worth the time to skim.  So I’m throwing together a simple list of my current collection of XSLT references, which happened to be my favorites of the bunch.   These books are all geared towards specific audiences… beginners, advanced, etc, so I included their audiences.

• XSLT – Mastering XML Transformations, Doug Tidwell
  This is my favorite XSLT book.  Mr. Tidwell did a great job of combining an introduction to the language, a tutorial on how to write XSLTs, and a reference all into one book.  On top of that, I found it to be written in the clearest, most conversational style I’ve found in many a programming book.  I find this book covers 90% of my day-to-day needs, and when I forget how something works, this book usually answers my questions.  (Plus, hey, you can get the 1.0 version for about $3 used.)
• XSLT: Programmer’s Reference, Michael Kay
  If Mr. Tidwell’s book covers 90%, this book covers all 100%, and then some.  Mr. Kay (who wrote the Saxon processor, if you weren’t aware) presents what amounts to an annotated specification in book form.  One of my co-workers calls this book the XSLT dictionary, and I can’t argue with that.  This book is probably best for advanced programmers.
• XSLT and XPATH on the Edge, Jeni Tennison
  Once you’ve got the basics of the language down, you’ve got to use it to write real-world code.  I found this book helps to smooth down the rough edges of working with the language.  This book requires a mid-level familiarity with the language.
• XSLT Cookbook, Second Edition, Salvatore Mangano
  I reach for this book whenever I’ve got to do something weird.  I use it to find the solution to some odd edge case, or for my “can I do this with XSLT” questions.  The book covers everything from faking regular expressions, to set operations on different node-sets, to functional programming with XSLT.  I don’t use it often, but it’s like gold when I do.  This book is mostly for advanced users.
• XPath and XPointer, John E. Simpson
  The content in this book is totally covered in each of the other books, and it isn’t really XSLT, because it only covers XPath.  But this book is my simple reference to 90% of the XPath questions I have.  It is a nice little book that I could live without, but it certainly makes my life easier having it around.  I think new users will likely get the most out of this book. (Another book that can be had for about $3 used.)

(For disclosure, I did make the links amazon referrals. I feel kinda weird, but figured why not. I don’t expect any results, but if I got some, it’d go straight to buying a new book.)

Simply put, thanks to everyone who visited in the past year. Still amazing to me that people from nearly 80 countries took a look at something I did.

Cheers to the new year, may it be good to all of us!

Recursion is one of the core concepts in programming. It’s valuable not only as a technique for writing programs, but as a general concept for solving problems. XSLT provides many useful elements such as for-each (and apply-templates), but occasionally you will run into a problem which must be solved with recursion. Let’s take a look at a real-world (no Fibonacci!!) example, where we have to operate on a simple string of numbers separated by commas. We’ll take a step-by-step approach to writing a recursive template.

Let’s say we have the following source document, short and sweet. We want to take each number, and wrap it with an element.

<?xml version="1.0" encoding="UTF-8"?>
<comma>1,2,3,4,5,6,7,88,99,100</comma>

The easy way to do this is to use the EXSLT str:tokenize function, which takes a string and some delimiters and splits the string based on those delimiters. All we do is add the xmlns:str and extension-element-prefixes attributes to our xsl:stylesheet declaration, and then call the str:tokenize function.

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
version="1.0" xmlns:str="http://exslt.org/strings" 
extension-element-prefixes="str">
 
    <xsl:template match="/>
        <xsl:for-each select="str:tokenize( comma, ',')">
            <xsl:copy-of select="."/>
        </xsl:for-each>
    </xsl:template>
 
</xsl:stylesheet>

The result is, (new-lines added for readability):

<?xml version="1.0"?>
<token>1</token>
<token>2</token>
<token>3</token>
<token>4</token>
<token>5</token>
<token>6</token>
<token>7</token>
<token>88</token>
<token>99</token>
<token>100</token>

Excellent. But let’s say that we don’t have access to the EXSLT functions, and we have to write a template to perform the same thing.

So now we think up a recursive algorithm. Let’s look at a simplified list with three numbers, such as “1,2,3”. First, we print the “1”, the value before the first comma, and then we discard the first comma. At that point, our list will be “2,3” and we repeat, printing the new first value, and discarding the new first comma. Finally, the list becomes only “3”. There is no comma, so we simply print out the rest of the list, “3”. So we will be recursing over the string printing the first number, and then popping off the first number and first comma. This technique will work with a three number list, or a million-number list (though your processor will probably run out of memory before that).

XPath’s “substring-before”, “substring-after”, and “contains” functions are all of the tools that we’ll need to implement our algorithm. “substring-before” lets us obtain the number before the first comma. “substring-after” lets us discard the first number and first comma, and “contains” allows us figure out the last, comma-less case.

Our function starts in the same manner as all recursive functions, dealing with the last case, and then all of the cases before it. The last case will be the comma-less case from our algorithm. So here’s our template skeleton.

    <xsl:template name="splitcommas">
        <xsl:choose>
            <xsl:when test=" not(contains($comma, ','))">
                <!-- do something -->
            </xsl:when>
            <xsl:otherwise>
                <!-- do something -->
            </xsl:otherwise>
        </xsl:choose>
    </xsl:template>

We use the XPath “not(contains($comma, ‘,’))” to, obviously, test whether our list contains a comma. As you probably noticed, we don’t actually have a $comma variable defined, so we’ll add our xsl:param to the template.

    <xsl:template name="splitcommas">
        <xsl:param name="comma"/>
        <xsl:choose>
            <xsl:when test=" not(contains($comma, ','))">
                <!-- do something -->
            </xsl:when>
            <xsl:otherwise>
                <!-- do something -->
            </xsl:otherwise>
        </xsl:choose>
    </xsl:template>

Now we fill in the holes in the template’s framework. First, we’ll handle the comma-less case, simply outputting the value wrapped in a “value” element.

<value><xsl:value-of select="$comma"/></value>

Then we will deal with the otherwise case. We’ll first print out the number before the first comma in the same manner that we printed the comma-less case.

<value><xsl:value-of select="substring-before($comma, ',')"/></value>

Then we’ll perform the same operation on the list after discarding the first number and first comma. We’ll call the template again, passing everything after the first comma (thus excluding both the first number and the first comma).

<xsl:call-template name="splitcommas">
    <xsl:with-param name="comma" select="substring-after($comma, ',')"/>
</xsl:call-template>

Finally, we’ll put all of these parts together, as well as adding a root template that will call our “splitcommas” template.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
 
    <xsl:template match="/">
        <xsl:call-template name="splitcommas">
            <xsl:with-param name="comma" select="comma"/>
        </xsl:call-template>
    </xsl:template>
 
    <xsl:template name="splitcommas">
        <xsl:param name="comma"/>
        <xsl:choose>
            <xsl:when test=" not(contains($comma, ','))">
                <value><xsl:value-of select="$comma"/></value>
            </xsl:when>
            <xsl:otherwise>
                <value><xsl:value-of select="substring-before($comma, ',')"/></value>
                <xsl:call-template name="splitcommas">
                    <xsl:with-param name="comma" select="substring-after($comma, ',')"/>
                </xsl:call-template>
            </xsl:otherwise>
        </xsl:choose>
    </xsl:template>
 
</xsl:stylesheet>

When applied to our source document, we get exactly what we wanted, each number of the string, enclosed in a element (I added new-lines for readability).

<?xml version="1.0"?>
<value>1</value>
<value>2</value>
<value>3</value>
<value>4</value>
<value>5</value>
<value>6</value>
<value>7</value>
<value>88</value>
<value>99</value>
<value>100</value>

So we accomplished what we were looking to accomplish by writing a recursive template, however our template only deals with commas. What if our list was separated by spaces instead of commas? We’d have to either write a new template that deals with spaces, or, better yet, modify our template to be more generic and handle many cases. I invite you to take a look at the actual implementation of the str:tokenize function. It isn’t that much more complicated, but does contain a few interesting wrinkles.

If you’re interested in the basics of recursion in general, I highly recommend The Little Schemer which is the most outstanding book I’ve read on the subject.

Using XSLT to copy elements is extremely common when you’re transforming a source document of a certain type (XML, HTML, etc.) to the same type. Often, you need an exact copy of an element verbatim, but other times you need to selectively choose certain elements to copy and others to discard. XSLT makes this process quite elegant using it’s xsl:copy-of and xsl:copy elements. The following is a setp-by-step tutorial on how these elements are used.

When you need an exact copy of an element and it’s children, you use the xsl:copy-of element, which makes an exact copy of the selected element and it’s children. Given the following XML data, which represents a (trivial) inventory of a store, let’s say you want an exact copy of any items with the name “XSLT”.

<?xml version="1.0" encoding="UTF-8"?>
<inventory>
    <item id="1">
        <name>The Little Schemer</name>
        <type>book</type>
        <author>Friedman</author>
        <author>Felleisen</author>
        <list-price>29.95</list-price>
        <sell-price>26.99</sell-price>
        <cost>17.92</cost>
    </item>
    <item id="2">
        <name>XSLT</name>
        <type>book</type>
        <author>Tidwell</author>
        <list-price>49.95</list-price>
        <sell-price>34.99</sell-price>
        <cost>22.92</cost>
    </item>
    <item id="3">
        <name>Romeo and Juliet</name>
        <type>compact disc</type>
        <conductor>Rostropovich</conductor>
        <list-price>18.98</list-price>
        <sell-price>13.99</sell-price>
        <cost>9.92</cost>
    </item>
</inventory>

You simply apply the following XSLT stylesheet to your source document:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
 
    <xsl:template match="/">
        <xsl:copy-of select="inventory/item[name = 'XSLT']"/>
    </xsl:template>
 
</xsl:stylesheet>

Which gives you exactly what you were looking for, the “item” with the name “XSLT”.

<?xml version="1.0" encoding="utf-8"?>
<item id="2">
    <name>XSLT</name>
    <type>book</type>
    <author>Tidwell</author>
    <list-price>49.95</list-price>
    <sell-price>34.99</sell-price>
    <cost>22.92</cost>
</item>

That was easy, so now let’s say you want to do a little more with your inventory document. Your boss wants a copy of it to look at the numbers and do some accounting. She doesn’t care about the authors or conductors, so she’d like that information left out. Also, she would like an additional piece of information for each item, the amount of profit off each item sold, the difference between the sell-price and the cost.

Because we are adding a piece of information and getting rid of elements that don’t affect the accounting, we can’t use a xsl:copy-of, because that would output an exact copy of the item element, it’s attribute nodes, and it’s child nodes. This exact copy is called a deep copy, because it not only copies the element, but all of it’s children as well. The solution is to use xsl:copy which performs a shallow copy, which means it only copies the current node, and ignores all children or attribute nodes.

Since xsl:copy only copies one element at a time, you need to explicitly specify that you want to continue copying attribute nodes and child nodes. xsl:apply-templates gives us the leverage to write a template that accomplishes that. The following template starts by matching attribute and children nodes, then copies the node, and recursively applies itself to any attribute or child nodes found in the source tree.

<!-- @* matches any attribute node on the current element,
       node() matches any child nodes of the current element -->
<xsl:template match="@*|node()">
    <!-- shallow copy... 
          only copy the node you're on (be that attribute or child node) -->
    <xsl:copy>
        <!-- apply this template to any other attribute or child nodes found -->
        <xsl:apply-templates select="@*|node()"/>  
    </xsl:copy>
</xsl:template>

Using this template, I can write a XSLT stylesheet that will copy the entire source document without any changes. This isn’t quite what we were looking for, because we wanted to add and remove child elements of item, but this is the first step.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
 
    <xsl:template match="/">
        <xsl:apply-templates/>
    </xsl:template>
 
 
    <!-- copy all attribute or child nodes in place -->
    <xsl:template match="@*|node()">
        <xsl:copy>
            <xsl:apply-templates select="@*|node()"/>  
        </xsl:copy>
    </xsl:template>
 
 
</xsl:stylesheet>

So how do we add the profit made from each item and remove the unnecessary information? We use the fact that our xsl:match=”@*|node()” template has a very low priority. Determination of default XSLT priorities are an advanced topic I won’t go into right now, but feel free to explore the topic if you are interested. Our template is essentially given a priority of -.5. Templates such as xsl:template match=”foo”, however, are given a default priority of 0. Because templates matching element names are higher priority, we can easily figure out how to remove the “author” and “conductor” elements, just declare templates without outputs!

<xsl:template match="author"/>
<xsl:template match="conductor"/>

We use the same technique to add an element to our “item” elements. First we use xsl:copy to copy the item node itself. Then we apply-templates to any attribute or children nodes found. When an author or conductor element is found, it will match our explicit rules and produce no output, therefore they will not be copied into our result. Finally, we create a new element named “profit” which will contain the difference between the sell-price and the cost.

<xsl:template match="item">
    <xsl:copy>
        <xsl:apply-templates select="@*|node()"/>
        <profit><xsl:value-of select="(sell-price - cost)"/></profit>
    </xsl:copy>
</xsl:template>

So we arrive at our final XSLT stylesheet, which looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
 
    <xsl:template match="/">
        <xsl:apply-templates/>
    </xsl:template>
 
    <!-- for each item, copy the <item> element, and apply-templates
         to it's attributes and children. Finally, create a <profit> 
         element, the difference between the sell-price and the cost.  -->
    <xsl:template match="item">
        <xsl:copy>
            <xsl:apply-templates select="@*|node()"/>
            <profit><xsl:value-of select="(sell-price - cost)"/></profit>
        </xsl:copy>
    </xsl:template>
 
    <!-- don't copy these, when they're found, there is no output -->
    <xsl:template match="author"/>
    <xsl:template match="conductor"/>
 
    <!-- copy all attribute or child nodes in place -->
    <xsl:template match="@*|node()">
        <xsl:copy>
            <xsl:apply-templates select="@*|node()"/>  
        </xsl:copy>
    </xsl:template>
 
 
</xsl:stylesheet>

When applied to our source document, we get the result our boss wanted, it excludes any “author” or “composer” elements, and includes a “profit” element.

<?xml version="1.0" encoding="utf-8"?>
<inventory>
    <item id="1">
        <name>The Little Schemer</name>
        <type>book</type>
        <list-price>29.95</list-price>
        <sell-price>26.99</sell-price>
        <cost>17.92</cost>
        <profit>9.07</profit>
    </item>
    <item id="2">
        <name>XSLT</name>
        <type>book</type>
        <list-price>49.95</list-price>
        <sell-price>34.99</sell-price>
        <cost>22.92</cost>
        <profit>12.07</profit>
    </item>
    <item id="3">
        <name>Romeo and Juliet</name>
        <type>compact disc</type>
        <list-price>18.98</list-price>
        <sell-price>13.99</sell-price>
        <cost>9.92</cost>
        <profit>4.07</profit>
    </item>
</inventory>

Using this technique, we can then easily prepare another XSLT stylesheet to generate an inventory list for the customer, which will exclude the “cost” element, since we don’t want them knowing it! All we need is to match all attribute and children nodes and copy them as normal, while providing no output when the XSLT processor encounters a “cost” element.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
 
    <xsl:template match="/">
        <xsl:apply-templates/>
    </xsl:template>
 
 
    <!-- don't copy the cost, the customer doesn't need to know! -->
    <xsl:template match="cost"/>
 
 
    <!-- copy all attribute or child nodes in place -->
    <xsl:template match="@*|node()">
        <xsl:copy>
            <xsl:apply-templates select="@*|node()"/>  
        </xsl:copy>
    </xsl:template>
 
</xsl:stylesheet>

Personally, because I end up transforming XML sources to XML output, I end up using xsl:copy-of and xsl:template match=”@*|node()” all the time. In fact, xsl:template match=”@*|node()” just happens to be the first piece of code in my XSLT toolbox.

I don’t typically link to other blogs/articles, nor do I mention classical music particularly often, but I found this article and blog entry so interesting and thought-provoking that they deserve a re-post.

First, a moving blog entry from David Finlayson, trombonist in the New York Philharmonic, and second, the New York Times article describing the background, as well as referencing the blog post.

While I’ve never had a specifically parallel experience, I can relate to the concepts of “fakes” in a particular industry.  I find Mr. Finlayson’s reaction (that all musicians must take responsibility and blame for the situation) to be both bold, yet… well, correct.  It takes a strong person to identify a stormy situation clearly and react in an appropriate fashion.  I only hope that I would react the same way given the circumstanses.

Working with more than a few new-hires over the last few weeks, I’ve noticed that new XSLT developers often write pull-style XSLTs by default. However, this tends to defy XSLT’s functional heritage, and is not as useful as the opposite form, push-style XSLTs.

Pull-style XSLTs reach into the source document and pull out the data they need to transform. The pull-style is similar to template systems like those found in Rails or Django, or inserting PHP commands between HTML elements. For example, given the trivial input:

<?xml version="1.0" encoding="UTF-8"?>
<books>
    <book>
        <title>The Scheme Programming Language</title>
        <author>R. Kent Dybvig</author>
    </book>
    <book>
        <title>Essentials of Programming Languages</title>
        <author>Daniel P. Friedman</author>
    </book>
    <book>
        <title>An Introduction to Information Theory</title>
        <author>John R. Pierce</author>
    </book>
</books>

an XSLT novice will produce a stylesheet like the following (note lines 11 and 12 which reach into the source and grab the data):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
    <xsl:template match="/">
        <html>
            <head>
                <title>books</title>
            </head>
            <body>
                <dl>
                    <xsl:for-each select="books/book">
                        <dt><xsl:value-of select="title"/></dt>
                        <dd><xsl:value-of select="author"/></dd>
                    </xsl:for-each>
                </dl>
            </body>
        </html>
    </xsl:template>
</xsl:stylesheet>

which transforms into:

<html>
   <head>
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <title>books</title>
   </head>
   <body>
      <dl>
         <dt>The Scheme Programming Language</dt>
         <dd>R. Kent Dybvig</dd>
         <dt>Essentials of Programming Languages</dt>
         <dd>Daniel P. Friedman</dd>
         <dt>An Introduction to Information Theory</dt>
         <dd>John R. Pierce</dd>
      </dl>
   </body>
</html>

The real power of XSLT, however, is defining templates for the elements found within the source document. These are push-style XSLTs. They have two main advantages. First, push-style gracefully handles complex source structures, including recursively nested elements. It would be near impossible to handle the following source document using pull-style,

<div><div><div>a</div></div></div>

if you didn’t know how deep the recursive divs would go. A push-style solution, though, is incredibly simple.

<xsl:template match="div">
     * <xsl:apply-templates/> *
</xsl:template>

Will transform the previous source into the following.

* * * a * * *

In addition to handling complex source structures, push-style allows code reuse. This is of course an ideal of any programming language. Push-style XSLTs have a greater ability to be reused, because the individual templates can be reused. When you only have one template, it is quite difficult to make it general without resorting to numerous choose-when statements. Here is an example of code reuse, where we extend a previously written template with the xsl:apply-imports rule.

Given the input,

<images>
    <image>
        <url>http://www.filmjunkie.com/drinks/blixa/blixa.jpg</url>
        <alt>Blixa!</alt>
    </image>
</images>

and the XSLTs,

    <xsl:import href="imageformat.xsl"/>
 
    <xsl:template match="image">
        <div class="wrapper">
            <xsl:apply-imports/>
        </div>
    </xsl:template>

and the rule in “imageformat.xsl” (the template being extended in this case),

    <xsl:template match="image">
        <img src="{url}" alt="{alt_text}"/>
    </xsl:template>

the processor will apply the higher-precedence template first, and then apply the imported (and lower-precedence) template to yield the following output.

<div class="wrapper">
    <img src="http://www.filmjunkie.com/drinks/blixa/blixa.jpg" alt="Blixa!"/>
<div>

Push-style XSLTs are not the most obvious thing to pick up unless you’ve been exposed to a functional programming language like Lisp or Scheme. However, considering their great value, they should be among the first disciplines studied when learning XSLT.

The final installment… a little late.

• Amityville Horror – (The OLD one, not the new one.)  I’d watched this before, but it was so much better than I remember it.  In fact, I felt it was the scariest movie that I ended up watching.  The scene at the beginning where the priest goes into the house was totally blood chilling.
• House of 1000 Corpses – I waited for years to see this movie, only to end up kinda disappointed.  I figured Rob Zombie had to know what he was doing with a horror movie, but the plot was so off-the-wall that I couldn’t believe anything, resulting in my rather ambivalent feeling towards it.  Too many characters killing too many other characters.  The creepy clown was the only interesting/memorable character.
• The Devil’s Rejects – I also waited a number of years to see this movie, but was prevented under the reasoning that I had to see House of 1000 Corpses first.  With that finally out of the way, I was now allowed, but I was wary… especially after the last film.  For the Devil’s Rejects, Rob Zombie took the large number of characters and un-realistic plot from the first movie, and turned it on it’s head… keeping the cast numbers low and keeping the entire movie realistic.  Zombie made the 3 bad guys out to be quasi-good guys, and the cop into a revenge obsessed bad guy.  The result was a really good character study of some truly bizarre people.  This movie wasn’t particularly scary, but it was quite good.
• Carrie – One of the best scary movies ever… my favorite part is at the end where Carrie’s hand… well, you know.
• The Exorcist – I LOVE this movie. I saved this pick until Halloween night. I love Max von Sydow, the early scenes in the desert, Father Damien, the fact that the movie is based on something that happened in a part of Maryland I frequent, that the movie’s steps are right down the street from where I used to work in Georgetown.  My favorite.

Latest installment…

• The Blob – Pure 60’s cheese (well, technically 1958, but close enough). Not scary, more silly than anything else. I was amazed that at one point, there was 24 minutes of no blobbing. Instead, we were shown a nearly 30 year old McQueen pretending to be a high schooler.  At least I can say I’ve seen it once.
• Hellbound: Hellraiser II – I had heard (multiple times) that this lived up to, if not surpassed, the original.  I didn’t quite think that was true.  [spoiler] I didn’t like Pinhead reverting to a human and dying.  A hero has an air of invincibility, and a super-villain (from hell no less) should be the same.  The plot set him up against the true villain of this movie, and Pinhead lost.  What a shame.  That said, it was immensely psychological, and quite a captivating movie (we were all watching with baited breath throughout). I thought it was terrific, just not as good as the first.
• Dead Alive – What can you say about a movie like that? Tons of gore and grossness, with only a hint of a plot. It is indeed a “classic.” Did I like it?  Ehh, it was ok… but I can appreciate it, especially viewed through the eyes of others.

Continuing the reviews of my house’s October horror movie film-fest:

• 28 Days Later – Rick told me that this was among the most realistic zombie movies ever made.  While it had a realistic look and feel, I had a problem with the unrealistic (and porous) plot line.  Of the 4 or so main characters, the supporting father and daughter roles were sympathetic, but I cared nothing for the main male and female leads.  That would be fine, if I didn’t also have to care about the weak plot (and yes, I know we’re talking about a zombie movie, but still!).  I didn’t dislike the movie, but it wasn’t my favorite.
• Hellraiser – I’ve been excited about watching this ever since I first heard the (rejected) soundtrack by Coil.  It was well worth it.  The movie’s imagery was pure 80’s (a compliment) and quite realistic, compared to the only-special-effects imagery I’m used to after watching modern movies. I won’t soon forget the rats nailed to the walls.  Hoping I can sneak Hellraiser II in before Halloween.
• The Shining – I’m sure I don’t need to mention how this movie helps to define the horror genre.  It’s spooky, creepy, and maintains the feeling that things are about to descend into total chaos for so long that you’re exhausted by the end.  My only problem is that the Simpson’s parody is so good that’s all I could think of at times.  Teriffic movie.
• Feast – Ok, I didn’t get all the way through this last night, but I’ve seen it (a few times) before.  It doesn’t take itself too seriously, and is a quintessential example of a trashy, gorey, funny horror movie.  You’d think the end woud be a let-down after how front-heavy the action is, but you’d be wrong.

I recently read Object-Oriented JavaScript, by Stoyan Stefanov. In reviewing it, I found it was one of the most interesting books I’ve read in a while, for some good reasons and a few more curious reasons.

Object-Oriented JavaScript was authored by Mr. Stefanov, who is a developer at Yahoo. It features an impressive number of reviewers (twelve), among them Douglas Crockford, the author of JavaScript: The Good Parts, and Ross Harmes, author of JavaScript Design Patterns, both of whom are Stefanov’s Yahoo co-workers. In a reasonable 330 pages, it features eight chapters on JavaScript’s History, Basic Syntax/Features, Functions, Objects, Prototypes, Inheritance, the DOM, and Patterns/Best Practices.

Readers with little to no JavaScript knowledge will be able to read this book, but I’m uncertain how much they’ll be able to glean from the meaty inner chapters (functions, objects, prototypes, and inheritance). Readers with moderate JavaScript understanding should be able to learn a great deal from this book. At the very least, advanced readers should be reminded of some of the language’s quirkier parts, as well as benefiting from an organized chapter on inheritance techniques.

It is tricky placing Object-Oriented JavaScript in context of the corpus of JavaScript literature. This book includes more than a little introductory material (chapters 1-2), while the core chapters (3-6) are way beyond an introduction. Only after those chapters (which I will discuss in a second) is the reader introduced briefly to the DOM and XHR before a chapter on design patterns and best practices. At a minimum, every chapter is useful and full of hints that are difficult to grep from run-of-the-mill JavaScript books. The book steers clear of the murky world of browser differences unless they’re pertinent to the topic of Object-Oriented JavaScript, which seems perfectly acceptable.

Back to those middle chapters, they are sheer gold. I am going force myself to make time to re-read this book, if not those chapters alone. They present, in a clear and organized fashion, many difficult aspects of the language, including closures, prototype, and 12 different methods for inheritance. In comparison, I believe Harmes’ book isn’t as well organized, and Crockford’s book isn’t as clear. Stefanov doesn’t break much new ground here, but the clarity describing these techniques is quite valuable regardless.

Object-Oriented JavaScript appears occasionally try to be something to everyone. This is kind of disappointing, since I would have loved to have seen any additional discussion or insight the author could have offered in the core chapters. There are tons of introductory JavaScript books, so I don’t know what a book titled Object-Oriented JavaScript gains by including more introduction. This shouldn’t detract from the book’s overall value. All of the chapters are well written and useful. However as a reader gains a better understanding of JavaScript, the introductory chapters will become far less useful, while the other chapters will remain an excellent reference.

In my mind, the three best JavaScript books are Flanagan’s JavaScript The Definitive Guide, Crockford’s JavaScript: The Good Parts, and Harmes’ and [Dustin] Diaz’s Pro JavaScript Design Patterns. Object-Oriented JavaScript doesn’t belong in that company for the reasons mentioned above. However, I would easily give it fourth place, and recommend it as a clear description of JavaScript’s harder parts.