Bug 283214 - [xpath2] Conditional Expressions cause XpathParserException
Summary: [xpath2] Conditional Expressions cause XpathParserException
Status: RESOLVED FIXED
Alias: None
Product: WTP Source Editing
Classification: WebTools
Component: wst.xpath (show other bugs)
Version: unspecified   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: 3.2 M1   Edit
Assignee: David Carver CLA
QA Contact: David Carver CLA
URL:
Whiteboard:
Keywords: helpwanted
Depends on:
Blocks: 262765
  Show dependency tree
 
Reported: 2009-07-10 20:11 EDT by David Carver CLA
Modified: 2010-08-11 17:07 EDT (History)
1 user (show)

See Also:


Attachments
Code changes in grammar file for this change (8.07 KB, patch)
2009-07-13 19:12 EDT, Jesper Moller CLA
d_a_carver: iplog+
Details | Diff
Updated test cases with more success than failure (10.38 KB, patch)
2009-07-13 19:13 EDT, Jesper Moller CLA
d_a_carver: iplog+
Details | Diff
Generated lexer and grammar (752.20 KB, patch)
2009-07-13 19:14 EDT, Jesper Moller CLA
d_a_carver: iplog-
Details | Diff
Fix the remaining three tests (4.73 KB, patch)
2009-07-14 19:13 EDT, Jesper Moller CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Carver CLA 2009-07-10 20:11:12 EDT
The CUP based parser has problems with parsing XPath if then else statements.    In particular the parser throws an error when it reaches the "then" statement.

http://www.w3.org/TR/xpath20/

XPath             ::= Expr:exps {: RESULT = new XPath(exps); :} ;

Expr              ::= ExprSingle:ex 
			{: 
				Collection exps = new ArrayList();
				exps.add(ex);
				RESULT = exps;
			:}
                    | Expr:exprs COMMA ExprSingle:ex 
		    	{: 
				exprs.add(ex);
				RESULT = exprs;
			:} 
		    ;

ExprSingle        ::= ForExpr:n {: RESULT = n; :}
                    | QuantifiedExpr:n {: RESULT = n; :}
                    | IfExpr:n {: RESULT = n; :}
                    | OrExpr:n {: RESULT = n; :}
		    ;

IfExpr            ::= IF LPAR Expr:exps RPAR THEN ExprSingle:t ELSE ExprSingle:e
			{: RESULT = new IfExpr(exps, t, e); :}
		    ;
		    
Are the current definitions.
Comment 1 David Carver CLA 2009-07-10 20:13:21 EDT
The simple xpath expression throws a parsing exception at the "then" statement:

if (1 != 0) then 2 else 3
Comment 2 Jesper Moller CLA 2009-07-13 19:00:23 EDT
This is fixed by differentiating reserved and non-reserved words in the QName production, so that if ( ex ) doesn't look like a function call of an unqualified function. Patch underway.
Comment 3 Jesper Moller CLA 2009-07-13 19:12:01 EDT
Created attachment 141460 [details]
Code changes in grammar file for this change
Comment 4 Jesper Moller CLA 2009-07-13 19:13:02 EDT
Created attachment 141461 [details]
Updated test cases with more success than failure

I still get three failures in this test.
Comment 5 Jesper Moller CLA 2009-07-13 19:14:51 EDT
Created attachment 141462 [details]
Generated lexer and grammar

If you don't have CUP and JFlex set up in your lib folder yet. (big patch, breaks 250 code line, but it's all just generated code.
Comment 6 David Carver CLA 2009-07-13 19:20:29 EDT
Okay, I'll take a look at these, and will just regenerate based on the grammar changes and the updated test cases.   I'll see about getting this in later tonight.   Thanks for the patches Jesper.
Comment 7 David Carver CLA 2009-07-13 21:46:52 EDT
I've applied the Grammar patches and unit test patches.   The last three conditional tests will need to be tweaked so that we can compare the correct results as they are XQuery tests and not strictly XPath 2.0 tests (i.e. the results file is XQuery).  We need to compare the two attributes values and not the entire XML String for Test 12.


Comment 8 David Carver CLA 2009-07-13 22:42:28 EDT
Code checked into HEAD, build started.  Thanks for the patch.  I'll keep this bug opened until we resolve the last three remaining unit tests.
Comment 9 Jesper Moller CLA 2009-07-14 19:13:42 EDT
Created attachment 141583 [details]
Fix the remaining three tests

One was just about expecting XML nodes instead of text (using buildXMLResultString)

The next required extending the buildXMLResultString to also be able to format atomic results (in effect making buildResultString obsolete)

The last one was tricky, since there was a real bug in comparing result sequences containing untyped atomic values (copy-and-paste error). Also, the extected result had to be massaged.

So now it's all green!
Comment 10 Jesper Moller CLA 2009-07-14 19:15:53 EDT
I mean, the if-then-else tests are all green now, not the entire suite...

The comparison bugfix actually fixes some 11 other test failures :-)
Comment 11 David Carver CLA 2009-07-15 00:01:07 EDT
latest patch applied to head, and build passes. Thans for the patches Jesper.