[lxml-dev] problem\bug in xpath compare() with text in tail

[Raymond Wiker]

On May 24, 2008, at 22:41 , Matan Ninio wrote:

> Raymond Wiker <rwiker <at> gmail.com> writes:
>
>>
>> On May 24, 2008, at 21:46 , John W. Shipman wrote:
>>
>>> matan ninio wrote:
>>>
>>> +--
>>> | Is there some good place to look for information about XPath?
>>> +--
>>>
>>> If I might recommend my modest XSLT reference:
>>>
>>>   http://www.nmt.edu/tcc/help/pubs/xslt/
>>>
>>> It has a section on XPath.
>>
>> There's also some good stuff on  http://www.zvon.org.
>>
>
>
>
> Thanks for the links.  I have already read several of them,  
> including the very
> nice one in zvon.org mentioned above.  But I'm yet to find the bit of
> information i'm missing.  Why dose the behavior of "text()" change  
> to exclude
> tail elements when moving from "//text()" to "// 
> *[contains(text(),'ABC')]"?
> What does the "text()" function *actually* do?  I can see that if an  
> element
> where to have more then one text value, the meaning of  
> "contains(text()," may be
> unclear.  But they why is the //text() version actually pulling out  
> the tail
> elements?

The text() function is a predicate that returns true for XML text  
nodes - it is not a function that returns the concatenation of text  
nodes under a specific element. Thus, //text() returns all text nodes  
in a tree. If you want to return all text nodes that contain the  
string "ABC", the correct test might be something like "//text() 
[contains(., 'ABC')]"