I’ve been trying to learn XSLT for a few projects, and I find it both a fascinating and extremely frustrating language! I read about the designers goals (from Michael Kay’s XSLT: Programmer’s Reference) and just shake my head, i.e. : "XSL stylesheets should be human-legible and reasonably clear" and in the next sentence "Terseness in XSL markup is of minimal importance." It seems to be because terseness wasn’t a goal, they decided to see just exactly how verbose they could make it! This IMO directly counters the goal of making it human-legible and reasonably clear!
For example, I wanted to be able to display days as "3rd" and "10th" without having to store the "rd" and the "th" in my data so I decided to write a function (template) called "suffix-day" to do so:
<xsl:template name="suffix-day">
<xsl:param name="day" />
<xsl:variable name="last-digit">
<xsl:value-of select="$day mod 10" />
</xsl:variable>
<xsl:value-of select="$day" />
<sup>
<xsl:choose>
<xsl:when test="$last-digit=1">st</xsl:when>
<xsl:when test="$last-digit=2">nd</xsl:when>
<xsl:when test="$last-digit=3">rd</xsl:when>
<xsl:otherwise>th</xsl:otherwise>
</xsl:choose>
</sup>
</xsl:template>
Of course to call "suffix-day" the XSTL designers wouldn’t have been so forward thinking as to allow syntax such as this:
<xsl:call select="suffix-day($issue-day)" />
Or even this to allow expliticly specifying the parameter name:
<xsl:call select="suffix-day(day:$issue-day)" />
Noooooo, that will not do! It must be VERBOSE or it is not in keeping with the lofty aspirations of XSLT! Instead, we must call it like so!:
<xsl:call-template name="suffix-day">
<xsl:with-param name="day">
<xsl:value-of select="$issue-date" />
</xsl:with-param>
</xsl:template>
Or even better, what if we have a template that needs five parameters? Oooh. So instead of:
<xsl:call select="this-little-piggy($market, $stayed-home,$roast-beef, $none,$wee-wee-wee)" />
We’ll get to bask in verbosity with this!:
<xsl:call-template name="this-little-piggy">
<xsl:with-param name="piggy1">
<xsl:value-of select="$market" />
</xsl:with-param>
<xsl:with-param name="piggy2">
<xsl:value-of select="$stayed-home" />
</xsl:with-param>
<xsl:with-param name="piggy3">
<xsl:value-of select="$roast-beef" />
</xsl:with-param>
<xsl:with-param name="piggy4">
<xsl:value-of select="$none" />
</xsl:with-param>
<xsl:with-param name="piggy5">
<xsl:value-of select="$wee-wee-wee" />
</xsl:with-param>
</xsl:template>
Now now, doesn’t that feel more righteous? I’m just warm and fuzzy, and tingly all over right now. :-)
Jeesh.
Okay, I’m probably dead wrong with my criticsm of XSLT. There’s probably many great reasons why it should be verbose and I’m just being ignorant and short-sighted. Normally I never want to come across ignorant or short-sighted and I normally want to be objective and willing to acknowledge when I’m in the wrong.
But not today. I just wanted to vent. No, actually I just want to rant! Rant, rant, rant! So I don’t want to hear it from you why I’m wrong. Go away and leave me alone. Sue me if you don’t like it. :)
You’re right!
It seems to me that XSLT should not be hand-coded any more than HTML should ;)
It beats me why people want to code XML, XSLT or even CSS. We don’t write our own RTF or PostScript (well, not many of us).
XML and its flavours were designed as a machine-readable portable representation language. Perhaps XSLT itself does not need to change but computers should do the hard work of creating it, not us.
True.
I wanted to add that the particular problem you’re looking at could also be solved with a .NET callback, assuming you’re only evaluating this through .NET. Then you’ve got your function syntax.
I could add that the reason for the ugly calling syntax is to keep XSLT as fully legal XML that could be validated, but the syntax for calling templates still sucks.
>> It beats me why people want to code XML, XSLT or even CSS. We don’t write our own RTF or PostScript (well, not many of us).
Someone here implemented our newsletter system to use XSLT. He then handed it off to another employee who wrote XSLT files like they were HTML files, hand coding every one. It drove me mad, but until he left it wasn’t my area. Now I’m creating generic XSLT templates that are driven by XML files so we can change the data each week instead of using XCOPY inheritance and hand coding the changes!
One thing though: I think XSLT was probably the best choice for our newsletters giving the requirements, but I don’t know how I could create an XSLT file of the complexity I’m using w/o hand-coding it. To have a WYSIWYG XSLT editor that would take an XML file and generate HTML as I edit it would be a pretty advanced tool, wouldn’t it?
>> I wanted to add that the particular problem you’re looking at could also be solved with a .NET callback, assuming you’re only evaluating this through .NET. Then you’ve got your function syntax.
1.) I’m not sure what you mean (i.e. which particular problem to which I am referring, and how a callback would work), but more importantly,
2.) I have an existing working deployed and debugged system. It was written in .NET, but w/o going back through a .NET development, test, and deployment phase I have XSLT to work with. It would be an order of magnitude more expensive in time and cost to redo the .NET code. XSLT is basically the extensibility mechanism for our system. So having the solution be diving down into .NET code is not a realistic option. Yes we *could* do it that way, but imagine if this was a system that we purchased, not one we built?
>> I could add that the reason for the ugly calling syntax is to keep XSLT as fully legal XML that could be validated, but the syntax for calling templates still sucks.
Yeah, Michael Kay told me *all* about it! :) But I stil think they could have make it legal XML and not nearly as nasty.
I could add that the reason for the ugly calling syntax is to keep XSLT as fully legal XML that could be validated, but the syntax for calling templates still sucks.
I just found this page as the first link for a google search for "date suffix xslt template st rd th".
It’s a pity your suffix template doesn’t work!
Did you test it ever on the 11st, 12nd or 13rd?
Dude, it was an example. Not meant to be used. But if you find one that you want me to add a link to or include as an update for future googlers of "date suffix xslt template st rd th", I’d be more than obliged. ;-)
<xsl:template name="suffix-day">
<xsl:param name="day" />
<xsl:variable name="last-digit">
<xsl:value-of select="$day mod 10" />
</xsl:variable>
<xsl:value-of select="$day" />
<xsl:choose>
<xsl:when test="$day=11">th</xsl:when>
<xsl:when test="$day=12">th</xsl:when>
<xsl:when test="$day=13">th</xsl:when>
<xsl:when test="$last-digit=1">st</xsl:when>
<xsl:when test="$last-digit=2">nd</xsl:when>
<xsl:when test="$last-digit=3">rd</xsl:when>
<xsl:otherwise>th</xsl:otherwise>
</xsl:choose>
</xsl:template>