XalanJ2
  1. XalanJ2
  2. XALANJ-1912

match="and" causes error - doesn't comply with XPath spec section 3.7

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.6
    • Fix Version/s: 2.7
    • Component/s: XSLTC
    • Security Level: No security risk; visible to anyone (Ordinary problems in Xalan projects. Anybody can view the issue.)
    • Labels:
      None
    • Environment:
      Operating System: Other
      Platform: PC
    • Xalan info:
      PatchAvailable

      Description

      Trying to compile a stylesheet with 'template match="and"' or with 'template
      match="or"' causes an error. The compiler reports a syntax error. Probably it
      interprets the expression "and" as an OperatorName.
      However, the XPath spec in section 3.7 (http://www.w3.org/TR/xpath#exprlex)
      states clearly that a token must not be recognized as an OperatorName unless
      there is a preceding token (other than @, ::, (, [, , or an Operator).
      In the expression "and" there is only one token (namely "and"). There is no
      preceding token, so the token "and" must NOT be recognized as an OperatorName!
      Instead it should be recognized as a NameTest, matching an XML element named "and".
      The same applies to "or".

      Regards,
      Michał Borowiecki

      1. XalanJ1912Patch.txt
        11 kB
        Yash Talwar
      2. xpath.lex.patch
        11 kB
        Santiago Pericas-Geertsen

        Activity

        Hide
        Henry Zongaro added a comment -

        Bug priority was lost in migration from Bugzilla.

        Show
        Henry Zongaro added a comment - Bug priority was lost in migration from Bugzilla.
        Hide
        Jeff Turner added a comment -

        Restoring description

        Show
        Jeff Turner added a comment - Restoring description
        Hide
        Brian Minchau added a comment -

        This is a valid problem, and it has to do with the way the parser for the XPath grammer is implemented. It is implemented using reserved words for tokens like "and", "or".

        A Java equivalent of Lex (Lex/YACC) is being used. Lex has a 'state' option where reseved words don't matter (pointed out by John G.). Not sure if the Java equivalent of Lex has this feature.

        It needs to make allowances for those words to appear in QNames in appropriate places, and it isn't doing that right now. Don't know how difficult this is to fix.

        Workaround arounds are cumbersome, such as rather than matching on the QName "and", match against *[name()='and']

        Show
        Brian Minchau added a comment - This is a valid problem, and it has to do with the way the parser for the XPath grammer is implemented. It is implemented using reserved words for tokens like "and", "or". A Java equivalent of Lex (Lex/YACC) is being used. Lex has a 'state' option where reseved words don't matter (pointed out by John G.). Not sure if the Java equivalent of Lex has this feature. It needs to make allowances for those words to appear in QNames in appropriate places, and it isn't doing that right now. Don't know how difficult this is to fix. Workaround arounds are cumbersome, such as rather than matching on the QName "and", match against * [name()='and']
        Hide
        Brian Minchau added a comment -

        Assigning to Santiago P-G, after the Xalan JIRA meeting on April 5, 2005 he sent me a not agreeing to look into this one.

        Show
        Brian Minchau added a comment - Assigning to Santiago P-G, after the Xalan JIRA meeting on April 5, 2005 he sent me a not agreeing to look into this one.
        Hide
        Santiago Pericas-Geertsen added a comment -

        I'm attaching a patch to solve this problem. It is a tricky one because the lexer is created using JLex. It should, however, work in most cases. XSLTC is now able to parse expressions such as "and and and" or "preceding-sibling and child". We need a reviewer for this patch.

        Show
        Santiago Pericas-Geertsen added a comment - I'm attaching a patch to solve this problem. It is a tricky one because the lexer is created using JLex. It should, however, work in most cases. XSLTC is now able to parse expressions such as "and and and" or "preceding-sibling and child". We need a reviewer for this patch.
        Hide
        Yash Talwar added a comment -

        Hi ,
        I used eclipse to apply your patch. I get an error that says "Patch file dow not contain vaild patch"
        Can you please re-check the patch.

        Thanks!

        Show
        Yash Talwar added a comment - Hi , I used eclipse to apply your patch. I get an error that says "Patch file dow not contain vaild patch" Can you please re-check the patch. Thanks!
        Hide
        Yash Talwar added a comment -

        Santiago has sent me the updated xpath.lex file, I have recreated the patch using eclispe for org/apache/xalan/xsltc/compiler/xpath.lex
        This patch contains the changes from Santiago; just the patch is in different format.

        Show
        Yash Talwar added a comment - Santiago has sent me the updated xpath.lex file, I have recreated the patch using eclispe for org/apache/xalan/xsltc/compiler/xpath.lex This patch contains the changes from Santiago; just the patch is in different format.
        Hide
        Yash Talwar added a comment -

        I have reviewed the patch XalanJ1912Patch.txt.
        I have verified that there is no regression introduced in alltest.conf and alltest.conf.xsltc suits. Smoketest is fine also.

        I have also verified that the patch resolve the orginal reported problem.
        I approve this patch.
        Thanks!

        Show
        Yash Talwar added a comment - I have reviewed the patch XalanJ1912Patch.txt. I have verified that there is no regression introduced in alltest.conf and alltest.conf.xsltc suits. Smoketest is fine also. I have also verified that the patch resolve the orginal reported problem. I approve this patch. Thanks!
        Hide
        Sarah McNamara added a comment -

        Hi Santiago, we'd like to get this patch committed for the Xalan Java 2.7 release. Yash has reviewed. Can you please commit the patch.
        Thanks.

        Show
        Sarah McNamara added a comment - Hi Santiago, we'd like to get this patch committed for the Xalan Java 2.7 release. Yash has reviewed. Can you please commit the patch. Thanks.
        Hide
        Sarah McNamara added a comment -

        The patch has been applied in cvs. The fix will be avaliable in the Xalan Java 2.7.0 release.

        Show
        Sarah McNamara added a comment - The patch has been applied in cvs. The fix will be avaliable in the Xalan Java 2.7.0 release.
        Hide
        Brian Minchau added a comment -

        Micha, this fix made it into the Xalan-J 2.7 release. Please confirm that it is fixed, then we can close this issue.

        Show
        Brian Minchau added a comment - Micha, this fix made it into the Xalan-J 2.7 release. Please confirm that it is fixed, then we can close this issue.
        Hide
        Michal Borowiecki added a comment -

        I confirm that it is fixed in 2.7.0

        Show
        Michal Borowiecki added a comment - I confirm that it is fixed in 2.7.0
        Hide
        Sarah McNamara added a comment -

        Closed per Michal's comments that the fix is verified as good.

        Show
        Sarah McNamara added a comment - Closed per Michal's comments that the fix is verified as good.

          People

          • Assignee:
            Santiago Pericas-Geertsen
            Reporter:
            Michal Borowiecki
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development