xmlXPathEval: evaluation failed

Do you have an xpath evaluated expresion in your report? Something like {=mynode} . I'll work on improved handling but this code should only be executed with tags that begin with "=". Can you look at your report and see if such a tag exists?

Hmm... Ok I'll do some testing. Would you be willing to attach a copy of your .frx file so that I can see if I can replicate the problem?

Its' been a while, is this still an issue?

In trying to get this very old issue moving forward, and because I think I've seen other issues with somehow similar error messages, I did some similar (I think) xPath related testing in version 7.x-3.11. where I encountered this message now:

Warning: SimpleXMLElement::xpath(): Invalid expression in FrxReport->render_section() (line 230 of 
...\sites\all\modules\forena\FrxReport.inc).
Warning: SimpleXMLElement::xpath(): xmlXPathEval: evaluation failed in FrxReport->render_section() (line 230 of ...\sites\all\modules\forena\FrxReport.inc).

Taking into account some of the forena coding refactoring (between 6x and 7x), it looks to me that this is a similar issue now for 7.x-3.11.

My report sample contains quite a few xPath expressions, but I'm about sure that these messages are produced because of something that is wrong in this part of my report:

<tr frx:foreach="//result[{parm.Operator}({parm.Header},{parm.Value})]" id="forena-2">

So what I'm trying to achieve here is to use 3 report parms, i.e.:

• Header (think of a table column header)
• Operator (which should be a valid xPath 'operator' to use in an xPath expression)
• Value (some value to use in the xPath expression)

My understanding (correct me if I'm wrong) is that using either contains or starts-with are valid values for Operator (within my xPath expression). But still for 'some' reason I get the above mentioned error messages. My questions:
a) What is the recommended way to somehow debug my forena report, so that I can find out which xPath expression in my report is causing these messages?
b) is there anything that can be done in the forena coding to provide some more details in the actual error messages (eg: if I'd use an invalid operator like 'ttt', is it possible to somehow include that 'ttt' in the error message?

PS: note that I changed "Version" in this issue now also ...

Hello Pierre,

I just realized how long I let this issue simmer. It still seems relevant, i suppose. In most cases I have refactored the 7.x-4.x code to supress the warning messages and return no data, but I'm unsure as to whether this is your desired behavior. Do you think this issue should be changed to a feature request to change the behavior of the way xpath behaves in the reporting engine?

We let this simmer and no repsonse, so assuming this strategy works in 7.x-4.0 seriees.

David, I just did 2 similar experiments in a forena 7.4-beta3 setup, a minor variation of the sample.state_summary report.

Scenario 1, using an xPath expression like this:

frx:xpath="*[ends-with( state , 'M' )]"

No graph got created, but instead these error messages appeared (actually this msgs block showed up twice):

Warning: SimpleXMLElement::xpath(): xmlXPathCompOpEval: function ends-with not found in FrxRenderer->xmlToValues() (line 804 of .../sites/all/modules/forena/renderers/FrxRenderer.inc).
Warning: SimpleXMLElement::xpath(): Unregistered function in FrxRenderer->xmlToValues() (line 804 of .../sites/all/modules/forena/renderers/FrxRenderer.inc).
Warning: SimpleXMLElement::xpath(): Stack usage errror in FrxRenderer->xmlToValues() (line 804 of .../sites/all/modules/forena/renderers/FrxRenderer.inc).
Warning: SimpleXMLElement::xpath(): xmlXPathEval: 2 object left on the stack in FrxRenderer->xmlToValues() (line 804 of .../sites/all/modules/forena/renderers/FrxRenderer.inc).

Scenario 2, using an xPath expression like this:

frx:xpath="*[starts-with( state , 'M' )]"

In this the generated graph was perfect, and not any error messages were produced.

Based on the results of these 2 scenario's, this is my current perception of all this:

- The first error msg line of scenario 1 clearly tells me now that "ends-with" seems to be not a valid xPath function, so this helps a lot to understand what my actual problem seems to be. The subsequent 3 lines are probably caused by the problem described in the first msg.

- If I uses xPath function 'starts-with' (as in scenario 2), or 'contains', I don't experience any problems (the charts get created fine. However if I use 'ends-width' (as in scenario 1) or 'matches', then I get the errors as in scenario 1. After doing some more research about available xPath functions, I seem to understand that functions 'contains' and 'starts-with' are available in xPath 1.0, while 'ends-with' and 'matches' were only introduced in xPath 2.0.

- what isn't clear to me yet though, is what exactly determines which version of xPath is being used. Is that something coded within forena? Maybe something related to SimpleXMLElement? Maybe even related to the version of Drupal you're using (like D7 comes with a more recent jQuery version as compared to D6)? Maybe there is something I can do (like "upgrade" or change some setting somewhere), so that xPath version 2.0 is used, so that functions like 'ends-with' start to work also?

The version of XML is determined by the libxml implementation on your server and has very little to do with Forena or drupal. There is no known implementation of php XML parsing that supports xpath 2.0 and the libXML xpath 2.0 support seems to be indefinitely stalled. There is not much possilbity of that support. I would recommend trying to deal with complex query needs in the data block and not try to make this happen with XPATH.

PS: Given that the current beta is still reporting these error messages shoul we be activating this issue? What is the concensus about whether the error messages should be reported or shouldn't? Should the xpath expression fail silently or behave as it exists.

David, a few additional replies on this:
- if my data block is an XML file (not SQL), do I have anything else apart from xPath for such complex query?
- My latest testcase was in beta3, "current beta" is beta4 (just to to make sure, though I will do a similar check soon in beta4).
- I'd vote to continue to report these error messages. That way it appears easier to understand the actual problem. If you'd suppress them, and if by accident you'd have some typo in your xPath function, it would be really hard to find what the actual problem is, no?
- I don't think we need to activate (= reopen?) this issue. Because now I understand that I should only use xPath 1.0 functions. Something we may want to add somewhere in the new tutorials maybe?

Yes you are correct, of course, that if you only have XML, then xpath is your only possiblity for filtering.

My initial thought was the same as yours. It's a bit of a pain that the error messages repeat so many times in certain circumstances, but I'm glad to hear that you agree that we should show the error messages.

I agree that it seems like a good idea to add to the tutorials.

OK, I'll remember to apply some minor update to the new tutorials related to this xPath 1.0 support. I'm assuming that this also explains why the xPath 2.0 Aggregate Functions such as max,min and avg are not supported yet, while xPath 1.0 functions like count and sum work fine. However, looking at what's described in #2116023 (about FrxTotal as a custom renderer), I wonder if it's a good idea to try to come up with similar custom renderers that provide an alternative for those xPath 2.0 functions, expressions?

FYI: for XML data blocks shown in a report in tabular format (not an SVG graph), I often use the dataTables plugin because of the search box that it supports (if you enable that search box). That appears to me as a partial work around, because at least you can use it as an alternative for "ends-with". The downside of it is that you cannot limit that search to a selected column, at least not that I know. The nice thing about it is that the search box also supports searching for only those rows that have both string1 AND string2. This simply by typing string1, then a space, and then string2 in that search box.

I have no real interest in trying to come up with custom renderers to try and support XPATH 2.0 expressions. And we are getting off topic here. If you are needing to do a lot of analysis on data prior to handing off to forena, then I'd recommend looking into making your own php data blocks that handle the analysis that you need. EIther way any such requests for support should be filed against a new issue.