Peter's Gekko

public Blog MyNotepad : Imho { }

XSLT again

My previous chatter on XSLT was possibly stated a little to strong. I do not want to ban every use(r) of it, I do even see places where it is useful. At the time of writing I was pissed of to be confronted with it without asking for it. The comments to my dislikes were quite interesting (thanks Frans an Joseph), reason enough to try to clarify my opinion.

Let's take this XSLT sylesheet (From Dino Esposito's book "Applied XML-programming"

<xsl:stylesheet
xmlns:xsl:"http://www.w3.org/1999/XSL/Transform"
version="1.0">

<xsl:template match="/">
    <HTML>
        <BODY>
           <H1>Northwinds's Employees</H1>
                <TABLE>
                    <xsl:apply-templates
                        select="MyDataSet/NortwindEmployees/Employee"
                </TABLE>
            </BODY>
        </HTML>
</xsl:template>

Imho, the yellow part is just data, the processor will copy it straight to the resulting document. It is surrounded by xsl-code which will be processed by the xsl processor. Where the data stops and the code begins is completely unclear to the reader of the document. And even the XSL processor makes mistakes, like the one in IE trying to display an aspx document.

To everything else than the xslt processor the whole stylesheet is data, after all it is just a XML document. A XAML file is a XMLdocument as well, in here the pieces of code can be recognized as being CDATA sections. A XAML file is no code, it is processed to generate the source of real C# classes, a CData section is not processed. This resulting source will be fed to the compiler to produce something executable. Here the distinction between code and (meta)data is a little clearer.

The latter brings me to my other problem with xslt. The only development tool I really trust is a compiler. It will check every character of my source and immediately report on every typo or stupidity. When it comes to processing the style sheet I will not be aware of any problem until the crash has happened. So when I have a choice I'd rather use some XML(xpath)document objects. Of course this is partly a matter of taste. I am very strongly biased to stay away from xslt, but will it stay away from me ?

Blog on,

Peter

Published Nov 17 2003, 12:36 PM by pvanooijen

Comments

JosephCooney said:

Hi Peter - re: the example from Dino's book, if you want to turn XML into HTML somehow these pieces of literal text would have to be included somewhere. If the job that a piece of XSL is performing is to turn some XML into HTML then you would think that this is an acceptable place to include this, right? I guess the fact that you are producing an XML document (or XML-like document) means it is a little harder to see the difference between literal output and XSL constructs (hint: if it has <xsl: > at the start it is probably XSL). Ironically from my experiences producing XML documents as output is where XSL is strongest (rather than producing non-XML output).

Re: XSL blowing up at "transform time" rather than at "compile time", yes, this is a problem altho in my case the "run without error but mysteriously fail to give the correct output" was more typical. I guess the closest thing you can do to compiling is to validate your XSL document against the XSL schema. I downloaded Visual XSLT from ActiveState today to check it out (after Don Box raved about how good it was, and then I saw a glowing review on ActiveState's site from Aaron Skonnard). I seem to go through waves of infatuation with XSLT (always for codegen). I wonder how long this one that you have innitiated will last.

# November 17, 2003 11:16 AM

Peter van Ooijen said:

hi Joseph.
The location of the HTML is OK, I would like the "code" to be somewhere else :). Yes it is confusing, I know I can see by the namespace of the tag if it is an xsl thing, but nevertheless.
I took a look at Visual XSLT. Couldn't install it properly, guess it takes my side-by-side Whidbey for the active VS. But the idea looks great. As it takes the schema of the XML doc as a starting point, it could be a whole different ball-game. As I am by origin a strongly typing OO programmer and used to love things like COM typelibraries. Schema's are my way to go. Couldn't check yet how Visual XSLT lets's you enter the passive data, like the html in the example. The tool is on my to-do list.

"run without error but mysteriously fail to give the correct output" :) Well known phenomenon...
XSLT Infatuation ? Have to look that up in the dictionary. Ah yes.. Well you're productive using it:

http://dotnetjunkies.com/WebLog/JosephCooney/posts/3660.aspx

That will be another step in my crash course.

# November 18, 2003 1:43 AM

JosephCooney said:

Hi Peter - I'm glad to see you didn't take my previous comments the wrong way. On re-reading it I couldn't help think that I sounded like a know-all prick. I know I don't know everything, but I could be a prick. Productive with XSLT? Sometimes, but my templating code generator uses ASP.NET style <% %> syntax, not XSLT to generate code (but it does use XPath a bit). My brother Dom says XSLT is deprecated in favour of XQuery anyway.

# November 18, 2003 9:03 PM

Peter van Ooijen said:

Hi Joseph. You're a great "sparring partner" to get my thoughts clear. :> I'll do one more post.

Visual XSLT may be nice but its setup smells. After a failure in installing I had to reregister VS 2003 with IIS to be able to debug again and I had to repair my Whidbey installation because all components had gone. Guess it's a part of the alpha game.

# November 19, 2003 8:35 AM