Oleg Tkachenko <oleg@N...> wrote:

>Mark Johnson wrote:

>> So I asked. Is the context node simply
>> that used to generate an XPath node-set, but not then part of that
>> node-set.

>That depends. Context node is a node in which context any given XPath 
>expression or part of XPath expression is evaluated. There is always exactly 
>one context node.

The context node is that upon which the XPath expression is evaluated.
So the context node is, by definition, that used to generated the
returned node-set. It's not necessarily part of that node-set, unless
included - but isn't anything special compared to the rest of the
nodes.

Perhaps, context node has two meanings, then. It's a) the node used to
create the nodeset, by an XPath expr, assuming relative location
paths. B) it's more typ used to refer to whatever node is being
examined by a particular template match or for-each on the node-set
returned from the first sense of that, context node? 

So position() returns what is called the, context position. But that
node at that position, is also called, the context node?


>> Is the context size simply the number of nodes returned by an XPath
>> expression? I don't see that explained, anywhere. 

>You seems to think about XPath expression as monolitic black box.

Black box? Isn't a function(), a black box? An axis even? A location
path? I don't understand the objection.

You mean, a node-set returned from an XPath expr is constantly being
modified? changed in size, and context?


>> Node types:
>> 
>>                                for context node 
>>                              string          node-set 
>> 1) element            name()         * 
>> 2) text                 text()  
>> 3) attribute                             @* 
>> 4) namespace       namespace-uri()   namespace:: 
>> 5) comment                              comment() 
>> 6) instruction   
>> 7) root node  

>> Is that accurate, and/or what would be the missing axes or functions?

>It's not clear to me what do you want to sort out in this table?

For instance, to get the string name of the element, you use the
name() function, which I guess is short for local-name()? But to get
the elements under it, you'd use the asterick. To get the string of
text for an element, you'd use the text() function. There wouldn't be
a node-set, because there wouldn't be multiple text nodes for any one
element. Right? To get an attribute value, it would just be the at
sign and name of the attribute. But to get all attributes for an
element in a node-set? And so on.