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 www.dpawson.co.uk) > 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: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Checking element to see i, David Carlisle | Thread | Re: [xsl] Checking element to see i, David Carlisle |
Re: [xsl] Missing nodes are ruining, Rupert Howell | Date | Re: [xsl] Checking element to see i, JCS |
Month |