2

I have been facing this issue for 2 days since we have updated the library. We have a lot of xpath of this kind:

/root/temp[@attr!='abcd']

and these aren't working anymore since we updated the library to 2.13. These were working fine with the 2.11 version, but they does not work anymore with the >=2.12 versions. The issue is easy to reproduce:

String test = "<root><attr temp='abcde'></attr></root>";
VTDGen vg = new VTDGen();
vg.setDoc(test.getBytes());
vg.parse(false);
VTDNav vn = vg.getNav();

AutoPilot ap = new AutoPilot(vn);
ap.selectXPath("/root/attr[@temp!='abcd']");
System.out.println(ap.evalXPath());//expecting a positive int, get -1 instead

We have updated because of another bug, but now we are really stuck with this. Any ideas? Is there another syntax we can use to bypass this error? We tried with the /root/attr[not(@temp='abcd')] and it's working with this simple case, but we aren't sure this is valid for every xpath that involves an "!=" as operator.

Please note that 2.11 was working even with an xpath like /root/attr[@temp!=''], after that version it seems that != operator is broken, at least for the use we are used to.

EDIT: The reason why we wouldn't use the "not" syntax is because in case like this

<root>
    <nodes> 
        <node attr="1" />
        <node attr="2" />
        <node attr="3" />
    </nodes>
    <nodi>
        <nodo attr="1" />
        <nodo attr="2" />
        <nodo attr="3" />
    </nodi>
</root>

These xpaths:

/root/nodes/node[@attr!=/root/nodi/nodo/@attr]

/root/nodes/node[not(@attr=/root/nodi/nodo/@attr)]

return different results. I know it's a pretty trivial example, it's just we can't really be sure all keeps working as expected by simply find-and-replace. I just dove into the source code and I noticed that the parser simply cut the ! out of the xpath expression.

Damiano
  • 35
  • 3
  • 1
    Cross-check: Can you try this alternative XPath `/root/temp[not(@attr = 'abcd')]`? Also, please confirm that your XML does not contain any namespaces. – Tomalak May 23 '17 at 11:17
  • @Tomalak we actually did and it works (I forgot to put the @ in my post at first, fixed), but... I edited my post with an example that shows why we would like to avoid to change all the xpaths blindly – Damiano May 23 '17 at 13:33
  • *"Is [a != b] always equivalent to [not(a = b)] in XPath?"* would make for an excellent question, by the way. Short, precisely answerable, and so far I don't think it has been asked before. – Tomalak May 24 '17 at 12:40
  • ok, I will look into it... I remember someone brought up this issue and had it fixed already in 2.13... will look at it again – vtd-xml-author May 24 '17 at 21:53

1 Answers1

0

I pasted your code into my eclipse editor and the answer I got is 2.. not -1 as you have indicated...

So what I can say is that you have not gotten the latest edition, which is 2.13.1.

Would you please go to vtd-xml web site and get version instead.

https://sourceforge.net/projects/vtd-xml/files/vtd-xml/ximpleware_2.13_2/ximpleware-2.13.2-java.zip/download

Edit: please go to cvs repo and download this parser.java file... this is where my fix went... make sure you have that...

http://vtd-xml.cvs.sourceforge.net/viewvc/vtd-xml/ximple-dev/com/ximpleware/xpath/parser.java?revision=1.33

Edit: I have posted a fix to this bug as version 2.13_2 and it went out today..

vtd-xml-author
  • 3,319
  • 4
  • 22
  • 30
  • Hi @vtd-xml-author !I was already using the 2.13_1, but I double checked downloading again and still get -1.I found the bug(I think) and I noticed it is still present in the downloadable version.In the class parser,package com.ximpleware.xpath,method CUP$parser$do_action, case 8 handles the "!=" operator,but inside that case BinaryExpr.EQ is always used except for the last "else".I just replaced BinaryExpr.EQ with BinaryExpr.NE everywhere in that case and now it seems to work.Of course we are still testing but I am pretty confident that was the problem.Could you please confirm it? – Damiano May 25 '17 at 08:07
  • I will do a double check and push out a release to correct that bug if I can confirm that... – vtd-xml-author May 25 '17 at 20:52