On 10/12/03 4:00 AM, "Lars Huttar" <lars_huttar(_at_)sil(_dot_)org> wrote:
It sounds like you don't want the "path" template to be
called for <element_four>.
Did you try David Carlisle's suggestion? I.e. change
<xsl:for-each select="/*//*">
to
<xsl:for-each select="//*[not(*)]">
or, since your criterion is "is a container and has no text",
<xsl:for-each select="//*[not(*) or text()]">
That should do what you want.
Hi Lars,
Yes, using the former <xsl:for-each select="//*[not(*)]"> per David's
suggestion did the trick. I wouldn't have thought of this--something that
would elude the beginner I think. This is saying to me, "select each child
that doesn't have any children." I think that's a simple way of putting it,
right? But that's not what I was thinking of at first.
When I was looking at
root/foo/manchu/chocolate/bar
I was thinking "How do I get to bar?" because in my head I'm thinking
"path". And yes, it *is* a path, but before I can map out a route I have to
understand the *relationships* within the data tree, i.e. parent/child
ancestor/descendant, etc. Knowing the relationship is the only way to get to
the route, yes? This, to me, is the curve ball, because in OOP, I'm dealing
with "objects in space"--they don't really have a root and they're not all
connected. This definition David gave me was enlightening:
"i.e. a network with one distinguished node, from which you can reach every
other node in the network, and there are no loops."
Because I was thinking of a railroad model at one point, but railroads can
have loops. But even that definition may imply understanding a route (from
which you can reach every other node) before understanding the
*relationships* that build routes. I guess what I'm suggesting is that a
possible explanation for an XPath path is that it is selected by node
relationships, not by node routes. A path implies an arbitrary route,
whereas the word relationship triggers the concept of "connections". Even a
bus route is arbitrary unless you know where it "stops" i.e. Know how it is
connected.
So yes, I would definitely recommend to anyone explaining the concept of
node selection to think of it in terms of relationships, not routes, just as
one is encouraged to think of "elements", not "tags". The path then becomes
incidental.
Incidentally, I agree that the XSL FAQ can be hard to
find answers in, and the answers there are difficult to
understand. What we need is for someone who has time, to
write up an FAQ that focuses on answering questions, rather than
a collection of scattered excerpts from discussions.
And someone needs to develop a good index for it.
Not a trivial task.
The main problem I'm having with XSL is definitely the terminology.
Sometimes I think I'm in a room full of lawyers with all the jargon that's
thrown around a conversation--inconsistently. "node sets", "fragment trees",
"copy-of vs. value-of", "matching vs. selecting", "result tree", "input",
"node structures"... And most of the terminology is counterintuitive. I have
heard this complaint over and over. This language would be more accessible
if things could be explained in either less technical terms or less
fragmented explanations. The learning curve for XSL is high because of the
non-intuitive references to XSL-specific jargon. It's bad enough that one
must "unlearn" previous programming logic to embrace XSL. I've read Mike Kay
state "This language is full of surprises." No bloody kidding.
However, the collection there is better than nothing, and
I appreciate Dave's time in putting it together.
I've found some good answers there.
Yes, eventually I've been able to accept what is there is better than
nothing, and I'm certainly not complaining about the effort that has been
put forth by this group and its participants. I'm just thinking it's time
for the "next wave" of progressive communication to occur, as more people
are trying to come on board but having difficulty. I'm one of them.
--
"A critic is a person who goes onto the battlefield after the battle has
been fought and shoots the survivors."
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list