This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes XML and Related Technologies and the fly likes XPath expression constrained by a predicate doesn't work (//element[@attribute= Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Engineering » XML and Related Technologies
Bookmark "XPath expression constrained by a predicate doesn Watch "XPath expression constrained by a predicate doesn New topic
Author

XPath expression constrained by a predicate doesn't work (//element[@attribute="value"])

Ralf Wahner
Greenhorn

Joined: Jun 03, 2007
Posts: 21
Dear Colleagues

Could I kindly ask you for a hint concerning an XPath problem? Consider the following short XML document:

As far as I understand XPath, the expression //gchild[@b] is expected to find <gchild> nodes at any depth in the tree which own a b attribute, whereas //gchild[@b="first"] narrows the returned nodes to the subset, where the b attribute has the value first. With respect to the above short XML document, the former expression evaluates to both <gchild> nodes and the latter one produces the first <gchild> node, only. However, the following program, adapted from David Flanagans "Java in a Nutshell", page 283 and amended by a few lines (see comments):

behaves this way:

I spent a lot of time on this problem in the last few days. I assume that the XPath expression is correct, but I don't understand, why the evaluation fails.

Thank you for taking the time to read this posting.


SCJP (SE6), SCWCD (EE5)
g tsuji
Ranch Hand

Joined: Jan 18, 2011
Posts: 499
    
    3
When you feed the xpath to the application as a commandline argument, there comes the issue of special characters of its own. Double quote should be wrapped by double quotes (making it three consecutive double quote). You can use single quote to make life easier. Also, inside the predicate, space is non-generic surrounding equal (=), but again it becomes a problem for the console, you have to further wrap the whole path in double quotes. (One may think: what a mess!)

These are all expected to execute as expected.

These work but are considered unnecessary (case with no space in the xpath).
Ralf Wahner
Greenhorn

Joined: Jun 03, 2007
Posts: 21
Dear g tsuji

Thank you for your reply. Unfortunately, the situation remains unchanged. :-( Reading your message, I recognized that I could have been more precise in my description. I don't need to hand the XPath expression in from the command line. Sufficient to hard-code it the source code. However, changing the assigment to doesn't work as well. The runtime engine fails with this exception:

Where test.xml is the above short XML document. Note: On invocation on a bash/linux box with either of the six expressions you suggested, the runtime engine throws exactly the same exception. I am aware of escaping certain characters when handing in command line arguments and was already suspecting this effects but the cause seems to be something else. Perhaps this is a silly question, but I have no idea where to look for the cause.
g tsuji
Ranch Hand

Joined: Jan 18, 2011
Posts: 499
    
    3
>Content is not allowed in trailing section

I think that indicates you might have to take a look at your xml file itself. With expression set inside the code as shown, it should work.
Ralf Wahner
Greenhorn

Joined: Jun 03, 2007
Posts: 21
Dear g tsuji

Thank you again. Yes, test.xml was not valid. I'm sorry for this unheedfulness. However, the XPath expression doesn't find any matching elements. Setting up the expression inline as well as the six variants on the command line lead to an empty node set. In

the getLength() method returns 0, in all cases:

Are XPath expressions in Java source code syntactically different from XSLT, say like regular expression, where four backslashes in the code match one backslash in a windows file path?
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

Ralf Wahner wrote:Are XPath expressions in Java source code syntactically different from XSLT, say like regular expression, where four backslashes in the code match one backslash in a windows file path?


I guess "Yes" is the answer to this, although I don't know why you ask it. The backslash character doesn't have any function in XSLT, whereas it does have a function in Java. And you haven't used any backslashes anywhere in this post or in your code. So the question is really irrelevant to this post.
Ralf Wahner
Greenhorn

Joined: Jun 03, 2007
Posts: 21
Paul Clapham wrote:I guess "Yes" is the answer to this, although I don't know why you ask it. The backslash character doesn't have any function in XSLT, whereas it does have a function in Java. And you haven't used any backslashes anywhere in this post or in your code. So the question is really irrelevant to this post.


So is your reply. If you take a few minutes for reading you might understand, that I spent a lot of time and thorough thinking to describe an astonishing behavior. It is definitely not my fault, when expensive books and highly acclaimed companies predicate, that something works in a certain way, but it doesn't and people believe to have no time to write down the bare essentials other people need to get started. I gratefully appreciate your thoughts concerning the question, why the above XPath expression, //gchild[@b='first'], doesn't find a matching node.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

The usual explanation for "astonishing behaviour" is that you have done something wrong, or misunderstood something. It's not like that example is a strange corner case which might have been overlooked by the implementers, after all.

My explanation for why that XPath expression doesn't match anything in the document is that there is nothing for it to match. If you think there is, then perhaps you haven't looked closely enough for reasons why there is not.

However I don't mean to trivialize the work you have done, and I fear I may have done so, or at least appeared to do so. So I spent the time copying your code and test file into my machine. I did hard-code the XPath expression rather than passing it as a command-line parameter, and here's the output I got:

Found 1 matching nodes.
- [gchild: null]


Here's the code I used:


and here's the contents of the XML document I used:
Ralf Wahner
Greenhorn

Joined: Jun 03, 2007
Posts: 21
Dear Paul

Thank you very much for your second reply. I apologize, if my tone was inappropriate. English is not my native language and I felt defensive reading your first reply. Finally, it turned out, that I had mispelled an attribute name in my local XML file when reparing my request for this forum. test.xml on this posting is correct while my local version was not. :-( Even tough I'm sorry for taking your time, I'm glad to see that my understanding of the underlying concepts is right.

Thanks again and best wishes

Ralf
g tsuji
Ranch Hand

Joined: Jan 18, 2011
Posts: 499
    
    3
@Ralf Wahner

[0] There is no doubt in my mind if you specify the xpath expression in the code, as you've shown as well in your follow-up post, it should work. And you should debug looking for other mistakes until it works. That is a pre-requisition.


[1] As to the command line version, in my first response, I was meant to be in windows: cmd console. I should therefore response for bash console to be more pertinent. That I here do.

[1.1] I re-do it in a bash console. Incorrect result may result for the above xpath for the simple reason of the presence of single-quote. You should by all mean wrap the arg in double quote, like this, with variations which necessitate escape with backslash.

[1.2] And then there is a reason for the working with //gchild[@b] for the reason there isn't any quote _and_ because there isn't any space in the path. As I said previously, xpath spec implies a series of strings being generically the same xpath, in particular, the presence of non-generic ignorable whitespace. With that component, below illustrate the need of further escaping.

etc ...
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: XPath expression constrained by a predicate doesn't work (//element[@attribute="value"])
 
Similar Threads
XPath
XML Parsing
Java Web Services 2
below code is correct way to write the code in generic way if we receive different xml formats
How to Generalize the code?