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