Re: [xml] xpath treatment of absent nodes

On Mon, Nov 05, 2012 at 04:49:49PM +0000, Alex Bligh wrote:
I am seeing a difference between command line xpath under linux and libxml. I am wondering which is right.

If I have a tree like this:

  <bar id='0'>
   <bip>it is zero</bip>
  <bar id='1'>
   <bip>it is one</bip>
  <bar id='2'>
   <bip>no baz element</bip>

Now if I run xpath, I see:

$ xpath -e '//foo/bar[baz=1]/bip' < test.xml
Found 1 nodes in stdin:
-- NODE --
<bip>it is one</bip>

$ xpath -e '//foo/bar[baz!=1]/bip' < test.xml
Found 2 nodes in stdin:
-- NODE --
<bip>it is zero</bip>
-- NODE --
<bip>no baz element</bip>

That's what I'd expect.

However, libxml's xpath appears to not find the second match (where there is no 'baz') element on the 
second xpath query. Which is right?

  The spec, just the spec, use it, it's free :-)

"If one object to be compared is a node-set and the other is a number,
then the comparison will be true if and only if there is a node in the
node-set such that the result of performing the comparison on the number
to be compared and on the result of converting the string-value of that
node to a number using the number function is true."

 In the document on the last bar, the node set "baz" is empty. The
comparison operator is '!='.
But there can't be a node in that set where the cast would be true
so the test has to fail, and the last bar child must not be selected.

 So clearly /usr/bin/xpath which is apparently coming from Perl
has a bug. Be careful with comparison operators on XPath node sets
they don't alway obbey to standard expectation.

  Assuming I look right, lease report the bug to Perl :-)


Daniel Veillard      | Open Source and Standards, Red Hat
veillard redhat com  | libxml Gnome XML XSLT toolkit | virtualization library

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]