Subject: Re: [xsl] Checking element to see if it has children... From: JCS <subscriber@xxxxxxxxxxxxx> Date: Wed, 10 Dec 2003 08:51:07 +1300 |
On 10/12/03 4:00 AM, "Lars Huttar" <lars_huttar@xxxxxxx> 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] Checking element to see i, Lars Huttar | Thread | Re: [xsl] Checking element to see i, David Carlisle |
RE: [xsl] Converting to uppercase, Norma Yeazell | Date | RE: [xsl] Accessing variable with c, Michael Kay |
Month |