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
... 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
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.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list