Re: [xsl] A Question **TO** XSLT Newbies

Subject: Re: [xsl] A Question **TO** XSLT Newbies
From: S Woodside <sbwoodside@xxxxxxxxx>
Date: Mon, 21 Apr 2003 14:14:21 -0400

On Monday, April 21, 2003, at 01:24 PM, Larry Garfield wrote:


I have to agree on this one. Frankly, I found XSLT itself to be fairly easy to learn, once I got into it. And thinking declaritively in general wasn't a problem. It's figuring out how to pull data out properly that is the problem, vis, XPath. I HATE XPath. :-) I don't know how universal this is, but XPath is always the part of any XSLT script that gives me the most hassle, every single time.

I would have agreed with you a few months ago. Now with the help of people on this list (thanks!) I feel like I've come a lot closer to mastering it. Maybe I should write an article ;-)


Taking that into account, I agree. XPath is WAY harder to grok than XSLT. The online documentation is way poor (the XSLT spec is pretty good, the XPath spec is shite). A lot of the resources about XSLT don't make it clear where the line between something being an XPath problem and an XSLT problem is drawn. XPath seems to have all kinds of special cases. The syntax is totally overloaded ... I feel like the designers wanted something simple but instead it just looks simple and really is complex. Debugging XPath is very hard. To gripe a little badly, the XPath section in the XSLT FAQ isn't the strongest section ...

FWIW I thought the original post presented a good idea about teaching XSLT to newbies to programming.

My thinking about presenting it to procedural programs is to emphasize that essentially the data makes "function calls" to the templates (which is the opposite of how procedural code works, where the program is in charge of flow, in XSLT the data is in charge of flow... my thinking on this is still pretty immature)

simon


XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list



Current Thread