Robert,
At 12:05 PM 3/12/2003, you wrote:
my original question was based
more on aesthetics than efficiency.
Aesthetics is certainly a worthy concern.
it just struck me as curious that so many of the examples
i saw in the docs i was reading insisted on creating paths
that involved "backing up" to parents or ancestors, that's
all.
This may be due in part to the manuals' interest in demonstrating how XPath
allows you to walk all over the tree when you build location paths with
multiple steps. This needs to be demonstrated in the books but it could be
that in Real Life it's just a bit less common to need to do this than one
might expect (though occasions are certainly not unheard of especially for
ill-designed source formats). Examples cooked for demonstration aren't
really coming from the same direction as RL examples: oddly, in the books
the author actually has a legitimate reason to say "look you can use this
complicated thing", which may sometimes obscure a simpler solution to the
problem (artificially) posed.
i was just taking it as a challenge to rewrite such
paths using the second form.
It's a worthwhile challenge.
The axes and their application are redundant by design, and of course it's
always possible to say
../*/..
to get one's parent (and other such silliness) -- much more egregious than
what you've found -- and yet believe it or not stuff like that occasionally
turns up in the wild.
For example, some XSLTers apparently think they need to do
<xsl:template match="//element">
<xsl:apply-templates/>
</xsl:template>
possibly because they haven't quite clicked with the distinction between
matching and selecting that Lars and Jeni are talking about back over in
that there other thread.
Cheers,
Wendell
___&&__&_&___&_&__&&&__&_&__&__&&____&&_&___&__&_&&_____&__&__&&_____&_&&_
"Thus I make my own use of the telegraph, without consulting
the directors, like the sparrows, which I perceive use it
extensively for a perch." -- Thoreau
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list