Q: reasonable for novice programmers? A: XSLT (depends); Perl(depends); T::T(good bet).

Q: How is XSLT in practice? A: See below for more info.

Q: Is language-neutrality an XSLT advantage? A: No. Any XSLT 'neutrality gains' are illusory when you consider the differences in parsers (eg XALAN, SAXON, msxsml.dll (various versions), msft "dotNet", perl et al..) and difference in coding styles (which affects every programming language, not just XSLT) and the inevitable "turf battles" and "politics" of it all. Forget "language neutrality", its a marketing phrase. I've used each of the systems you specified, and have (or at least had) a particular affinity for each of them. Here then is one person's opinion.

The short version is this. Avoid XSLT unless you know *exactly* what you're getting into ahead of time. It is not pretty. Use T:T if you have to work with non-technical people on your production team. Use Perl if you have a professional coding style that is eyeball friendly to whomever may inherit your code (thus bypassing the pervasive stigma that some hold against perl). This of course presumes you have no constrains re: technical proficiency; and no vendors or language zealots influencing your decisions.

By the way, the reason all of this is relevant on a perl website is because nearly *every* criticism of XSLT that follows is the diametric opposite of perl. In other words, everywhere XSLT gets it wrong, perl gets it right.

When XSLT (actually XSL) first came out in the last millenium, you might say I was an eager and avid "early adopter". Having had favorable experience with perl templating (and templating tools in general), the assumption was that XSLT would be a versatile transformation and templating system: "just like perl, but with the structure of XML".

That assumption was dead wrong.

Don't get me wrong ... no software is perfect when it first comes out, but the design and direction of XSLT have absolutely convinced me that its principle advocates designers rarely (if ever) actually *use* it themselves for routine tasks. Certainly not as much in comparison to the principle advocates and designers of Perl, or even Template Toolkit for that matter (both of which have advantages and are worth learning).

XSLT "pros"

• XSLT is prevalent, and has the marketing-friendly kewl name that starts with the letter "X"
• XSLT is good if you are selling books, software, certification and courses in XSLT
• XSLT is good if you are a hobbyist who enjoys working with it for its own sake
• XSLT is good if you had a role in designing it
• XSLT is good if it keeps you employed

XSLT "cons"

• "XSLT is not intended as a completely general-purpose ... language" (see http://www.w3.org/TR/xslt) but people use it that way anyhow.
• XSLT appallingly re-invents the wheel for the most rudimentary programming concepts (eg functions, loops, and variables). Moreover, the wheels are *all* square.
• XSLT assumes too much, is too verbose, and too disjointed to be tolerable after the initial novelty wears off, which will be fast, unless you reap one of the "pros".
• XSLT will have you searching for hours on how to do things that the XSLT designers tried to 'over engineer'
• XSLT has too many 'reserved character sequences' that make it a pain to actually write code

For a real-world comparison, here are some snippets of code. DISCLAIMER: These are old code snippets, and may not reflect the optimal way to get the job done. They are just here to give a general idea.

### perl example
print q©
    Hello World!
©for(1..10);
[download]

    [%# Template Toolkit Example %]
    [% FOREACH [ 1 2 3 4 5 6 7 8 9 10 ] %]Hello World!
    [% END %]
[download]

   <!-- XSLT example -->
   <!-- [..snip.. some stuff taken out for brevity] -->
    <xsl:call-template name="SayHelloTenTimes">
     <xsl:with-param name="i">1</xsl:with-param>
     <xsl:with-param name="count">10</xsl:with-param>
    </xsl:call-template>
    <xsl:if test="$i &lt;= $count">
      Hello world!!
    </xsl:if>
    <xsl:if test="$i &lt;= $count">
      <xsl:call-template name="SayHelloTenTimes">
          <xsl:with-param name="i">
              <xsl:value-of select="$i + 1"/>
          </xsl:with-param>
          <xsl:with-param name="count">
              <xsl:value-of select="$count"/>
          </xsl:with-param>
      </xsl:call-template>
    </xsl:if>
   <!-- [..snip..] -->
[download]

MVC is a great model to follow, but I wouldn't want to try to implement it using XSLT, not unless you want to buy my book on how to do it ;-)