• 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 just scrolled down my own blog, and saw a post titled “Down to three bugs.”  Funny enough, three months later, we’re still trying to push the website out. (Wow, those were some really big bugs!!!  Haha, jk…)  In fact, I’ve been pressing for the last 2 days, trying to expedite a few last-minute bugs so that QA testing could begin (for about the 18th time, now in snapshot 21).  Kinda odd, when QA finds bugs in round 20 that they didn’t find in round 10… despite no code changes in the meantime…

But I’m not going to complain.  Programming is still a lot of fun when you’re actually doing it.  It ends up being almost therapeutic when you’ve got other stuff going on that you’re trying to ignore.  Not only that, but there’s always room to improve.  A co-worker came to my desk yesterday and schooled me on how to write code.  When you’re young, you’re stupid.  He had lots of experience, and was… well, right… most of the time.  I was boxed into a corner at some points, but also made a few bad decisions.  The good thing is that I always learn from my mistakes, and next time will be much better.

I remember writing 3.5 websites before I really got common code working the way I wanted.  It was similar to the way I learned how to write CSS.  Excerpting common code so that I would only edit once, vs. editing 6 files just to make one update.  It was easy when I was using CSS, SSI’s, or PHP includes to simply import exactly what I needed, but I find it is far more difficult when using XSLT’s.  Why?  Because in XSLT you need to know not only the structure, but the context.  That’s what makes it difficult… writing context dependent generic code is difficult.

[Of course, dirty secret (I know you're skimming at this point, not really reading) is that I'm almost on only my 2 year anniversary (Sept. 20) of doing programming/development work.  So my progress is still quite good.]

Alright, I admit that this post was far more stream-of-conciousness than actual post, but it was good for me.  It wasn’t intended to be a “I haven’t written in a month, here’s what I’ve been doing” post, but more a “I’m busy, I’ll be back soon, but I don’t know when” type post.  So on that note…

[I think it's Siouxsie that's making me intentionally ambiguous. ]

Ta ta!

-e

[this post is like an email I never wrote to anyone...]

I’ve got to admit, thought, that I don’t really like PHP.  I’m not going to bash PHP outright (as I’ve heard MANY people do).  It is a programming language, and it certainly has it’s place.  I’ve used many things written in PHP.   In fact, I feel bad about the way people dismiss PHP.  That said, I still don’t like it.   My problem is that I feel PHP is simply too verbose.  There seems to be a function for everything.  It is the total opposite of Scheme, where every function is a based on a handful of core functions.  I have had to deal with a number of languages in my life, and I certainly prefer languages with as little syntax as possible.

I spend a lot of time googling the functions.  And then the parameters.  And then the return types.  And then I run across another function that is kinda like the first one that I saw, but slightly different (maybe even described as more or less efficient!)  And then I have to research the return types.   I’m mostly bothered by the related functions.  Just give me something I can use in different ways.  Don’t give me the kitchen sink and tell me to choose the faucet type.

This is the same problem that I have with XSLTs.  It is a rather verbose language (which happens to usually be interspersed in XML/HTML).  This makes it hard to pick-up in a hurry, and makes it unintuitive.  This is important.  Unintuitive.  I spend a major part of my work day making sure that all of the webpages, all of the components, all of the behavior… even the URLs of my work are intuitive.  So I don’t like to accept much less from the tools I work with.

To extend the analogy slightly further… I have seen that when websites are unintuitive, that said websites can fail.  Is the same thing the case for programming languages?

My orchestra, The Columbia Orchestra, is playing Beethoven’s Ninth Symphony for our next concert. The orchestra is trying to make at least a small cultural event out of it. There is a website (embracingthemillions.com) a flickr discussion group (flickr.com/groups/embracingthemillions), and a number of artists (not just musicians) participating in the event. Since I threw together the website (no comments please, I’ve been very busy), I know the statistics of people visiting it. And there are quite a few people visiting.  What I can’t figure out is with 30 or so people visiting per-day, why hasn’t anyone a) commented, b) written something on the discussion board? I made a post in the discussion group.  It took me a few minutes at best.  No one else has posted.  Are people’s lives really so busy that they can’t be bothered? I’m confused by this.  Technology aside, I am delighted to be playing Beethoven, he was simply a genius.

I went to see the Ingmar Bergman film, The Magician the other day at the AFI Silver Theater. I liked the quirky nature of the film, and found it to be totally engaging (I’ve yet to see one of his films that isn’t). I regret not being able to see more movies from the first part of the Bergman Retrospective they are doing now, as I have been ridiculously busy of late. However, I do own most of them on DVD (I don’t own the Magician). I look forward to the next few parts of this retrospective, as I don’t know as many of his later works.

I have been working extremely hard on the next version of My NCBI, the preferences section of the NCBI website. This is where you can set preferences for PubMed, Blast, and all of the rest of the NCBI sites/databases. It is hard, writing everything in a internally-created language, which is slightly buggy and tends to make easy things easy, but hard things very hard, with XSLTs completing the system. I haven’t had to write a ton of recursive XSLT functions or anything, (mostly because of the inclusion of EXSLT extensions), but development time is still very slow. It also seems that with every step I take forward, I discover 4 new things I have to do. Throw in the fact I made time estimates without knowing the language, and the NCBI announcement that the budget fell flat (and actually decreased) this year and people were dismissed, and that makes my life particularly fun. I knew what I was getting into when I signed up, and I wanted to do a LOT of work, but that doesn’t mean I feel that way every second of every day.

Additionally, I’ve had to meet a bunch of deadlines for the legal aspects of my dad’s passing. Trips/talks to lawyers, a visit to DC Vital Records, Orphan’s Court (yes, they call it that!) and NASA have really been a… treat, let’s say.

Also, some of the better (or at least unexpected) and smaller moments of the month were:

• Re-discovering IRC. I hadn’t even thought of IRC until I saw it mentioned in a twitter post. I found, however, that the groups in irc.freenode.net are going strong. I’ve read some of the #scheme discussion, answered a considerable number of questions in the #html and #css groups, and just lurked watching #microformats and #javascript. Interesting stuff.
• I’ve been taking a number of photos. I like holding on to moments, which is probably why I like taking pictures so much. Hopefully I will continue. I keep telling myself that if I do, I’ll upgrade to a D-SLR when I finally get all of my money issues (paying my father’s bills) worked out.
• I went on a kick of listening to nothing but David Bowie (thanks @ashleylynn) which was nice. I’ve been floundering around, listening to whatever CD was closest for a while now. I love finally regaining some direction. I also feel a Prokofiev kick coming on. Maybe, maybe not.
• I got a new monitor. A Dell 24″ flatscreen, which I really like. I knew they were coming out with new models (which have since arrived on their website), and luckily the only real difference was HDMI inputs, which I don’t need since I don’t plan on watching HD movies or TV on it (unless from my computer). My PC now has the 24″ as the main, and my 20″ rotated 90 deg. as a secondary. It is an extremely useful setup. I love the multiple inputs, since the press of a button on the front will switch me from PC to Mac and back again
• The Giants won the Superbowl. That was teriffic. So my Red Sox took the World Series, my Giants have the Superbowl, who will win the NBA Championship? (Ha, not the Knicks!) But I would love to see Detroit or Boston make the finals. Especially Detroit, I think.
• I ordered a new laptop hard-drive from Newegg, which should arrive either today or Monday. I installed Leopard on it last month, and during that time got tired of squeezing everything onto my tiny 60gb drive. So 250gb will be here soon, and I’ll transfer. I’ve found the only thing I really like about Leopard is Spaces, the virtual window manager. On the otherhand, it works in ways I don’t expect (or think it should work). Eventually, I will look to see if there are some command line settings I can use to change behavior. For now, it will just occasionally annoy me.

Finally, I am quite tired of the weather. Continual cold with occasional teases of warmer temperatures have made this, in my mind, one of the longest winters ever. I can’t wait for even slightly warmer temperatures, so I can convince myself to get back outside on my bike. I haven’t rode, again, in forever. I look forward to changing that.

To prepare, I looked through a few books. I looked through Jeni Tennison’s Beginning XSLT 2.0 book, but it wasn’t for me. I didn’t like how wordy it was… I got lost in the dialogue, and it distracted me from the points and the examples. On the otherhand, Doug Tidwell’s book, XSLT-Mastering XML Tranformations was precisely what I was looking for. It was concise and organized very methodically. PLUS, it only cost me $7 with shipping from Amazon.  Heh, gotta love that!

[note: because we only use 1.0 on the job, older books were better, as I didn't have to figure out what was a 2.0 feature and what was a 1.0 feature... and again, the books were cheaper]

Fun stuff aside, XSLT is a pretty cool language.  I’m too new to it to debate if it is a functional programming language or simply based on those attributes, but I’m happy to get to play with its functional aspects.  I am kinda thrilled to dust off my recursive-function-writing skills.  I hope to use it early and often, so I can get a good amount of practice in.

The class was useful because it showed me things I didn’t pick up from the books.  First was the concept that the root node is placed above what I called the XML root node.  The class called the XML root node the “document node.”  Solved one problem that I had been having. The other really enlightening aspect was the axes.  When I read the book and saw that there 13, I simply skimmed it.  It was good to sit down with , as the following:: and preceding:: axes were not what I thought.

Debbie Lapeyre and Wendell Piez, the instructors, were great and worked with us to answer all of our questions… even my weird set theory questions.  Wendell, in particular (because he led the third day) was helpful, showing me some of the common “hacks” people use to make 1.0 do things it wasn’t intended to do [despite my incredibly poorly phrased question!].  Now that I can understand XPath a little better, I can break down the pieces of the hacks… so things like the Muenchian method actually make sense now.

Hopefully I will get to keep working with XSLT’s, I’m definitely not an expert from three days.  But since they’re core to the portal system I work with, I expect to get a lot more practice in.  If I get good enough, I’d love to post some information that may be useful to others.  Stay tuned!

On my list of things to touch in full… 1) Advanced DOM Scripting.  I finished the book (a while ago) but haven’t had a chance to review it yet.  At the risk of ruining the surprise for my one (hopefully) reader, it was teriffic, and I highly recommend it.   I will do a full write-up later.  2) My comments on The Little Schemer.  This is simply an amazing book that’s opened up a number of paths in my brain.  I’m afraid that any review wouldn’t do it justice.  Maybe some thoughts on the book everyone should read. 3) Random thoughts on Bethesda, Kensington, Rockville (my new home!), riding my bike again, the Tchaikovsky concert coming up, my xslt class coming up, my recent css exploits… as you can see, I’ve got a lot of things that I am thinking about, but nothing to put down on paper… yet.  (Yes, I know, really, there is no paper… shut up!)

Contrast that with the time that I MUST spend with friends, and the potential Boston trip coming up… and I’ve got a lot to do!!  Better get started.  Washing my clothes now…