Apple in Half, by LuLu Witch

The Scheme steering committee has decided to sever the Scheme language into “Large Scheme” and “Small Scheme.”  Can we expect the same from Scheme-inspired languages like JavaScript? 

]]> http://www.eddiewelker.com/2009/08/24/cutting-scheme-in-half/feed/ 0 http://www.eddiewelker.com/2009/08/03/check-in/ http://www.eddiewelker.com/2009/08/03/check-in/#comments Tue, 04 Aug 2009 02:42:19 +0000 Eddie http://www.eddiewelker.com/?p=247 Not a technical post, but a personal update.  I promised over a week ago.

I’ve been exceptionally busy at work, we’re beginning to finish up a much needed, much discussed by librarians, redesign of PubMed.  We’ve put a ton of user interaction effort into this project, as well as a good sprinkling of graphic design (watch out, I even did some parts!)  I think people will be really positive about these new changes.

[Just for the record, if someone happens to stumble upon this from the librarian community, yes, release date is still end of summer, and yes, there will be a Beta period, so no need to worry about a short timeline to update your class or instructional slides.  We do listen!]

It’s also been exciting that we’ve brought a few new people on board.  Always exciting to have new hires, despite the fact that it’s a lot of work… and all of the trainings I have to do.

What else…  I’m planning on attending the DelveUI masterclasses this week in Brooklyn.  It will be interesting to see what some of the heads of state have to say about the field.  I’m a little excited, this masterclass format isn’t the usual boring no-content fluff that you hear at most conferences. I get the feeling that there will actually be code present!  My thanks to the lovely Jina “Sushi & Robots” Bolton for the opportunity for the free ticket.

I’ve been reading… way too many things.  I’ve been reading Learning jQuery 1.3, jQuery UI 1.6, and jQuery in Action and you’ll see the reviews of those two books very soon.  (Can you tell that we’ve switched to jQuery at NCBI?)  I’m a little behind with that reading, but I’ve been working hard on other things.  Additionally, I went on an Amazon spree, and started reading Programming the Semantic Web, An Introduction to Lambda Calculi for Computer Scientists, To Mock a Mockingbird, 101 Things I learned in Architecture School, Code Complete 2.   Last but not least, I’ve also been reading any photography book that I can get my hands on.

Yes, that is a lot of books, and I haven’t had much time for them.  I’ve been working hard at work, and I want to relax a bit when I come home.  Once summer ends, things will return to a slightly more regular pace.  I’ve been learning so much on the job, that I’m not very worried about falling behind in reading.

It’s the summer, so I have been riding… not a ton, but some.  I wish I had time to do more, but I don’t have time for everything.  I have been taking long-ish 7 mile rides home, and then going out to play some basketball with my roommates.  That’s a good time.  As soon as I finish this post, I am going to go and fix my fixie… my favorite Bianchi… I somehow mashed the pedals hard enough to shear off part of the thread of both the crank and the pedal, so there go the original cranks and some lovely MKS Sylvan Track Pedals that were on there. I’ve got a new, generic replacement crankset and new Sylvan’s.  Also, I’m moving from a 42×15 to a 46×17, but with the change in crank length (172.5 down to 165mm) I’ll have the same gear ratio as before.  I’m interested in seeing how the shorter cranks feel.

Not to mention le Tour this year… I was captivated.

And then I’ve been taking some photos.  Still have been good on my New Year’s resolution of taking a photo every day… with the exception of Jan 20 (yes, Inauguration Day, the day more people in my Washington DC area took photos than any other this year).

I also got an iPhone.  While I was in California for Joel and Olga’s wedding, I dropped my phone of more than 5 years on a rug, and the antenna that had been barely holding on for a few months finally fell off completely.  I had previously told myself that I would try to wait until my phone broke before getting a new one. So I was going to buy one at the first sight of antenna problems, until it was suggested that I wait for a new version.  Well, my phone’s demise and the new version’s release coincided, so now I have a 3GS.  Really the thing I like most is having my calendar with me at all times.  The only other part I really like is the speaker, so I can listen to music while on my bike for the first time.

Alright, so that’s about that for the moment. Go out and do something summer-y, that’s what I’m doing.

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.

• 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.)

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.

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.

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.

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.