Hi,

>   in many of the XSL books/tutorials i've seen, there are numerous
> examples of string functions that involve the current node, as in
> 
>   //element[contains(., "fred")]				
> 
> or
> 
>   //element[starts-with(., "abc")]
> 
> 
>   in examples like this, i'm assuming that "." can be rewritten in
> the long form, with either of:
> 
>   self::node()
>   self::*
> 
> although i suspect the former is used more widely.

In the above case they can be rewritten like that, but remember if you have

  //@attribute[contains(., "fred")]

this cannot be rewritten to 

  //@attribute[contains(self::*, "fred")]

because the principal node type for self axis is element and "--A node test * is true for any node of the principal node type--". See <http://www.w3.org/TR/xpath#node-tests>.

>   in addition, using the current node reference in a string function 
> context is implying that the string() function is being used so,
> once again, i could rewrite this even more verbosely with any of:
> 
>   //element[contains(string(.), "fred")]
>   //element[contains(string(self::node()), "fred")]
> 
> and so on.  yes, i realize it's painful, but i just wanted to 
> verify that it was equivalent.

Yes.

>   the last point is one that seems to be glossed over a lot, and
> that is that the string value of a node is defined as the 
> concatenation
> of all text nodes within the scope of the element's start and end
> tags.
> 
>   all the examples i've seen invariably show a really simple 
> example involving a node with no child elements, so the string
> value is obvious.  but the authors rarely seem to warn about
> cases where the self node() might contain multiple descendant
> text nodes, which will all contribute to the eventual string value
> of the current node, right?
> 
>   so just writing
> 
>   //element[contains(., "fred")]
> 
> has to take into account any descendant text nodes as well, yes?

Yes.

Cheers,

Jarno - Wumpscut: Wreath of barbs (Album Mix)

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list