Re: [xsl] Checking element to see if it has children...

Subject: Re: [xsl] Checking element to see if it has children...
From: JCS <subscriber@xxxxxxxxxxxxx>
Date: Wed, 10 Dec 2003 02:29:57 +1300
On 10/12/03 1:50 AM, "David Carlisle" <davidc@xxxxxxxxx> wrote:

>> I want the path to end with the element only if it doesn't contain other
>> elements, i.e. what railroad fans might call a "stub":
> Since xml is normally called a tree rather than a network, that's a leaf
> not a stub.

Well when I think of the tree analogy a few things come to mind, so I'm glad
you mentioned it. Of course the most obvious to me is that trees grow "up"
from the root, not down or sideways, and hierarchy XML data looks like
something growing out sideways rather than upwards. And most diagrams
depicting an organizational structure go from top down, but I'm not sure why
XML has to be depicted in this fashion. So when I'm thinking of a tree, and
leafs, I'm thinking about attributes because they're not extensible. But I
thought about "stub" because you can add onto a stub--just like an element.

But that tree analogy always bugs me because the analogy should be used
correctly, not adjusted to fit within the structure of XML. (IMO, it would
be better to say "It's *like* a tree rather than it *is* a tree--if we're
using analogies.)

> <xsl:for-each select="/*//*">
> selects ever descendent of the first child, ie every element except teh
> document element, you want every element with no child element that's
> <xsl:for-each select="//*[not(*)">
> (testing for no children (and generating path expressions) are both in
> the faq for this list at

Okay, thanks for that. And I mean no disrespect to anyone here or this list
but just because the FAQ contains "examples" they aren't "tutorials"--and
they're not part of a progressive learning system--otherwise I wouldn't be
posting to this list for help. I appreciate it when people take the time to
help me but I don't appreciate it when people refer me to the FAQ. If I'm
here in the list, it means I've already exhausted my resources and I need to
work it out with human help--and patience. I realize that veterans who still
wish to help out beginners may have little patience when answering the same
questions over and over again--and there's a solution to that problem--start
rewriting the FAQ to make it easier to comprehend for the "next wave" of
people learning this stuff. This stuff isn't hard to learn--however it's
hard to decipher everyone's techtalk. I should be able to teach this stuff
to a literate ten-year old with no difficulties. At present, the concepts
are presented incorrectly for incidental learning as there aren't any
conceptual relationships (analogies) being taught. I'm sure I'm not the only
one with this opinion.

Best regards,

/johnny :)

Pay no attention to that man behind the curtain.
-- The Wizard of Oz 

 XSL-List info and archive:

Current Thread