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

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