XSL Is a Declarative Language – Why Do I Care?

One of the comments I sometimes get when I talk about the beauty of Data View Web Parts (DVWPs) in SharePoint is “You know, XSL is a declarative language, not a procedural one.” I gave a talk last night at the Boston Area SharePoint User Group (BASPUG) called Developing in SharePoint’s Middle Tier and it came up again so I thought I’d try to figure out a better way to respond than “Uh-huh”.

I turned to my esteemed colleague Ian Dicker (he thinks I should call what I do in the Middle Tier “middletation”) to see what I should think about this. Ian’s view is that XSL can be both declarative and procedural, and I concur. Of course, I couldn’t concur fully until I did a little Binging to try to find out what “declarative language” and “procedural language” meant and how they differed.  This is theoretical computer science stuff to me. Sure, I studied that in college (I majored in Computer Mathematics at the University of Pennsylvania, which was a hybrid math/computer science degree they offered at the time) but the theory of these things doesn’t play much of a role in my daily life. I usually just try to get things done. Well.

Turning to Wikipedia (everything there is true because it’s on the Internet):

Declarative programming

In computer science, declarative programming is a programming paradigm that expresses the logic of a computation without describing its control flow.^[1] Many languages applying this style attempt to minimize or eliminate side effects by describing what the program should accomplish, rather than describing how to go about accomplishing it.^[2] This is in contrast with imperative programming, which requires an explicitly provided algorithm.

Procedural programming

Procedural programming can sometimes be used as a synonym for imperative programming (specifying the steps the program must take to reach the desired state), but can also refer (as in this article) to a programming paradigm, derived from structured programming, based upon the concept of the procedure call. Procedures, also known as routines, subroutines, methods, or functions (not to be confused with mathematical functions, but similar to those used in functional programming) simply contain a series of computational steps to be carried out. Any given procedure might be called at any point during a program’s execution, including by other procedures or itself.^[1]

and thus

Imperative programming

In computer science, imperative programming is a programming paradigm that describes computation in terms of statements that change a program state. In much the same way that imperative mood in natural languages expresses commands to take action, imperative programs define sequences of commands for the computer to perform.

(See the specific Wikipedia entries I’ve linked to above if you’d like to follow the citations.)

So, as in the title, why do I care? I think that the bottom line is that I don’t. But I also don’t agree that XSL can’t be used as a procedural language. I’m probably missing some of the nuances of the theory, but let me give an example.

SharePoint Designer sets up XSL templates itself and I do, too, in my custom solutions. An XSL template looks something like this:

<xsl:template name="StripHTML">
  <xsl:param name="HTMLText"/>
  <xsl:choose>
    <xsl:when test="contains($HTMLText, '&lt;')">
      <xsl:call-template name="StripHTML">
        <xsl:with-param name="HTMLText" select="concat(substring-before($HTMLText, '&lt;'), substring-after($HTMLText, '&gt;'))"/>
      </xsl:call-template>
    </xsl:when>
    <xsl:otherwise>
      <xsl:value-of select="$HTMLText"/>
    </xsl:otherwise>
  </xsl:choose>
</xsl:template>

This is an example from my SPXSLT Codeplex Project which strips all HTML tags from a chunk of text. It’s most often useful in displaying the Body of an Announcement without all of the goofy formating that the authors insist on using. It recursively calls itself until there are no more HTML tags to strip out the of chunk of text.  You call it like this:

<xsl:call-template name="StripHTML">
  <xsl:with-param name="HTMLText" select="@Body"/>
</xsl:call-template>

So based on the definitions above I suppose that this isn’t truly imperative (am I changing the program’s “state“? [Wikipedia: “In computer science and automata theory, a state is a unique configuration of information in a program or machine. It is a concept that occasionally extends into some forms of systems programming such as lexers and parsers.”), but it provides a reusable, procedural result. Again, I’m not sure if I care what the theoretical definition is, as long as I can use this template multiple times in the same DVWP, as needed. And I can, calling it with the @Title, @Body, and any other columns for which I need it, getting a consistently formatted chunk of text back, just the way I want it.