Subject: Re: [xsl] Checking element to see if it has children... From: David Carlisle <davidc@xxxxxxxxx> Date: Wed, 10 Dec 2003 01:26:53 GMT |
> 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? Almost. select each descendant element that does not have a child element. *[not(*)] would select each child that doesn't have a child (ie it would only look one generation down) it's // that forces the full depth descendant axis to be used. the child axis includes text nodes comments and PIs as well as elements so "no child" would be not(node()) rather than not(*), which you want depends on which of these you think has a child <x>a</x> <x><!--a--></x> <x/> > 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. you lost me there (actually you lost me at "curve ball" this is presumably a sporting analogy, but I'm not sure if having curved balls is good or bad, sounds good, compared to having square wheels, which is usually considered bad) > The path then becomes incidental. I'm still lost. How can a path be incidental in an Xpath? I'm all for a simplifying explanation if one can be found, but I find this suggested terminology baffling (whereas the usual Xpath terminology, and Xpath itself is fairly natural to anyone who's used a filepath on a unix or windows/dos file system, or a URL.) > 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", Xpath only has five types, and that's 2 of them, 5 is rather few types in most programming languages (Xpath2 has about 1050, as they have just inflicted schema typing on it) Would you expect a list devoted to Java never to mention a double, or a class or any other words for java constructs? > "matching vs. selecting" I don't see how you can discuss xslt without that. Just about every xslt expression has either a selcet= attribute or a match= attribute. We could call it "a" and "b" if you don't like those words but then how would youknow whether template match="xxx" was of type "a" or type "b", The words used to describe the language have to bear at least _some_ resemblance to the language constructs. > , "result tree", "input", Most programs have an input and an output, how can you avoid mentioning that? > "node structures"... this isn't a term I see used. But I would assume it means node tree. > And most of the terminology is counterintuitive. Like all languages it has some idioms that are not particularly intuitive using keys for grouping is a particular;y spectacular example, it's fairly simple and can give orders of magnitude speed improvements over more natural expressions but it could not by any stretch of the imagination be called an intuitive (the technique is usually known as muenchian grouping around here in honour of the person who thought of it) but I would not class any of the items you mentioned in this category, they are the names of the basic constructs in the language. > It's bad enough that one > must "unlearn" previous programming logic to embrace XSL. That of course depends on your previous programming experience. Not everyone has a java background, and the functional programming paradigm of which xslt is part has a much longer history than the OO programming paradigm that Java uses. It's perhaps less popular at the moment. People who haven't programmed much before tend to pick up xslt fairly quickly, java programmers find it harder as they have strange expectations like variables changing their value. David -- http://www.dcarlisle.demon.co.uk/matthew XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Checking element to see i, JCS | Thread | [xsl] Clearing up XSL-speak, JCS |
Re: [xsl] Converting to uppercase, Mukul Gandhi | Date | [xsl] Clearing up XSL-speak, JCS |
Month |