bug in processing XPATH with this simple regular expression?
Take this input:
<div id="ps-content">foobar</di
and apply this XPATH 2+:
//div[matches(@id,"^s-cont
I tried with BaseX and it matched! despite the fact that "^" in regex language means "the start of the string".
Why does it match?
<div id="ps-content">foobar</di
and apply this XPATH 2+:
//div[matches(@id,"^s-cont
I tried with BaseX and it matched! despite the fact that "^" in regex language means "the start of the string".
Why does it match?
ASKER
Thanks for testing it with Saxon!
I now also tested it with Xidel too and it correctly doesn't match, while it matches if I add the "p".
Do you know where is the right place to report the bug?
I now also tested it with Xidel too and it correctly doesn't match, while it matches if I add the "p".
Do you know where is the right place to report the bug?
I did not find any bugtracker tool on the site
(I was at an XML conference this weekend in London and actually was surprised not to meet any of the basex guys there, I could have asked)
anyway, you could try baseX talk
basex-talk(at)mailman.uni-
(I was at an XML conference this weekend in London and actually was surprised not to meet any of the basex guys there, I could have asked)
anyway, you could try baseX talk
basex-talk(at)mailman.uni-
ASKER
Done, I reported the bug to that email (mailing list): https://mailman.uni-konstanz.de/pipermail/basex-talk/2013-June/005241.html
Let's see what they say...
PS: wow, an XML conference, interesting!
Let's see what they say...
PS: wow, an XML conference, interesting!
yeah, well actually it was pretty interesting
http://xmllondon.com/
a whole weekend, me and the other nerds :-)
http://xmllondon.com/
a whole weekend, me and the other nerds :-)
ASKER
I read the program at http://xmllondon.com/programme.jsp
Really interesting!
Too bad that I'm so far... being in Italy...
Really interesting!
Too bad that I'm so far... being in Italy...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I've requested that this question be closed as follows:
Accepted answer: 0 points for lucavilla's comment #a39268339
for the following reason:
Solution found by experimenting
Accepted answer: 0 points for lucavilla's comment #a39268339
for the following reason:
Solution found by experimenting
If you want to accept your own answer (a bit inappropriate here actually) make sure it contains a solution. 'win 7 command-line related' is too vague.
Note I confirmed it is a bug and it should not return values, that on its own is an acceptable reassurance
What did baseX reply? What exactly is the command-line related issue? How can your accepted answer help others that run in the same issue?
If you pasted the XPath in a file and it works ... it still could be a baseX issue, them doing the wrong thing with windows command lines. Still they should look into it. I can imagine that they parse out the command line the wrong way
Note I confirmed it is a bug and it should not return values, that on its own is an acceptable reassurance
What did baseX reply? What exactly is the command-line related issue? How can your accepted answer help others that run in the same issue?
If you pasted the XPath in a file and it works ... it still could be a baseX issue, them doing the wrong thing with windows command lines. Still they should look into it. I can imagine that they parse out the command line the wrong way
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
did you try adding '^^' instead of '^', should work if I read this
ASKER
yes and it worked but it was becoming too difficult to consider the various special characters in a XPATH to escape them automatically.
Added to the possibility to reach the command-line length limit, I preferred to avoid the problem :)
Added to the possibility to reach the command-line length limit, I preferred to avoid the problem :)
I can confirm it should not match
and using Saxon, it rightfully does not match
I suggest you report it to BaseX as a bug to look into, because a bug it is