RE: Clearing up XSL-speak

> 
> 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