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

Subject: Re: [xsl] A Question **TO** XSLT Newbies
From: Andrew Watt <andrew@xxxxxxxxxxxxxx>
Date: Mon, 21 Apr 2003 20:20:15 +0100
At 14:14 21/04/2003 -0400, you wrote:
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 ;-)

Entitled "Confessions of a Former XPath Newbie"? :)



Taking that into account, I agree. XPath is WAY harder to grok than XSLT.

I am finding this fascinating. It isn't what I expected to hear.


The online documentation is way poor (the XSLT spec is pretty good, the XPath spec is shite).

Interesting. Same author/editor for both specs. So maybe he didn't anticipate that people would find such difficulties with XPath either.


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.

I am pretty sure this is deliberate. I assume the thinking is that XSLT and XPath are used together so teach them together.


XPath seems to have all kinds of special cases.

Care to share what you found particularly troublesome?


The syntax is totally overloaded

Is that the inevitable downside of compact? Or do you have something else in mind?


... I feel like the designers wanted something simple but instead it just looks simple and really is complex. Debugging XPath is very hard.

Again, very interesting.


How often do you debug XPath? Or do you mean difficulty in getting the XPath expression correct in the first place?

To gripe a little badly, the XPath section in the XSLT FAQ isn't the strongest section ...

Could that be because there aren't many XPath questions asked? Or questions perceived as XPath questions?


Without writing an essay here and now, the thing that put a light on in my head 2 or 3 years back was to liken XPath to a series of street directions. If you start at a particular place you get instructions like go north (an axis) 3 blocks, see if it's a particular kind of junction (node test) settle on that junction if there is a particular color house on the corner (predicate). Repeat as necessary.

I used the street directions analogy in Pro XSL, written late 2000, and it was new to at least some of the tech editors then.

I don't know if it was an original way of explaining it or not. If someone else had used it I wasn't aware of it. Or didn't recall it. Thinking of XPath expressions as street directions around the in-memory tree just made the XPath jigsaw make sense for me after that.

The street directions that you get depend on where you start from (the context node).

Coincidentally I was asked a few days ago if I thought there would be a healthy market for an XPath 2.0 book (this is looking a few months ahead obviously). I gave a lukewarm response. If I had already had this conversation I might have given a different response. Do you think there is a *need* for an XPath (2.0) book? What should be in it? A Cookbook-type approach which shows problems which people find hard but show them a way to do things, provide working code *that will run as is* and an explanation of how to extend the idea? Something different? Would people buy it?

I hope that Tommie is ok with this discussion going on. If we can better understand the problem areas, we can help people learn XSLT and XPath better.

Andrew Watt




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



Current Thread