Okay, right. Is there a difference between using the word
"select" and the word "find?"
No, there isn't. Using "select" is more usual.
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/>
Node() means "all nodes," correct? If you notice I've
appended the suffix _node to element above to get
element_node. This is something I was thinking about
today--that which adds to my confusion is that XSL terms are
used loosely. Because this is new to me, it's still hard to
think of an element as an "element node" because my head
wants to encapsulate all other nodes into the element node! I
would prefer it if people were more specific when referring
to nodes: "attribute node", "element nodes", etc, rather than
"element" or "attribute". Why? So when the term node() pops
up in conversation, my mind gathers all the node types
together quite easily. It helps me draw _relationships_.
Others learning XSL would find this beneficial as well.
Because when people start talking "nodes," without that
_node_ suffix used to anchor the types of nodes in people's
heads, an element is an element. It's NOT a node. Does that
make sense?
In the context of the data model, an element is always a node. But I
agree that it can be useful to stress this by saying "element node", if
you want to make it quite clear that you are talking about the data
model, and not about lexical XML (or about chemistry). In this example,
I don't think there was any risk of confusion.
Michael Kay
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list