XalanJ2
  1. XalanJ2
  2. XALANJ-1431

bug with evaluation of a matching clause

    Details

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

      Description

      Hi,
      In using xalan I ran into the following issue:

      in evaluating a match condition the conditions pertaining to attributes are not
      tested completely before evaluating the condition following an or clause.

      Example:

      <xsl:template match='@*[.!='']|node()'>
      <xsl:copy>
      <xsl:apply-templates select='@*'/>
      </xsl:copy>
      </xsl:template>

      Input:
      <elemen1 a='1' b='' c='3'/>
      <element2/>

      Output From XALAN:
      <elemen1 a='1' >
      <element2/>

      The bug is the fact the non empty attribute followed by the empty attribute was
      not matched. It was somehow skipped.

      I have tried this in xalan 1.2 C and xalan2 and xala 2_4 and have seem similar
      behavior. In xalan 1.2 the behavior was worse since the non empty attribute
      was copied to the subsequent element.

      Atleast the xalan 2 and 2_4 versions do not copy the attributes to next node.
      But they are still missing the non empty attribute occuring after the empty
      attribute.

      In SAXON the output is correct :

      <elemen1 a='1' c='3'/>
      <element2/>

      thanks in advance for fixing this.

      ds

      1. XalanJ1431_GoodPatch.txt
        1 kB
        Yash Talwar
      2. XalanJ1431_Patch.txt
        1.0 kB
        Yash Talwar

        Activity

        Hide
        Igor Hersht added a comment -

        Just the runable test-case
        in file
        <elemen1 a='1' b='' c='3'/>
        xsl file
        <?xml version="1.0"?>
        <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

        <xsl:template match="@*[.!='']|node()">
        <xsl:copy>
        <xsl:apply-templates select='@*'/>
        </xsl:copy>
        </xsl:template>

        </xsl:stylesheet>

        Show
        Igor Hersht added a comment - Just the runable test-case in file <elemen1 a='1' b='' c='3'/> xsl file <?xml version="1.0"?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:template match="@* [.!=''] |node()"> <xsl:copy> <xsl:apply-templates select='@*'/> </xsl:copy> </xsl:template> </xsl:stylesheet>
        Hide
        Igor Hersht added a comment -

        XSLTC has the same behavior

        Show
        Igor Hersht added a comment - XSLTC has the same behavior
        Hide
        Igor Hersht added a comment -

        I just entered Bugzilla Bug 27009 for XSLTC

        Show
        Igor Hersht added a comment - I just entered Bugzilla Bug 27009 for XSLTC
        Hide
        Yash Talwar added a comment -

        I have reproduced the problem with Xalan Interpretive and XSLTC.
        The problem is that that when an empty attribute value is encountered, a text node is being created
        with empty string.
        Henry Zongaro has helped finding the XSLT 1.0 specs. that suggest a text node with empty string should not be created. URL http://www.w3.org/TR/xslt#value-of has the following information:

        "The xsl:value-of element is instantiated to create a text node in the result tree. The required select attribute is an expression; this expression is evaluated and the resulting object is converted to a string as if by a call to the string function. The string specifies the string-value of the created text node. If the string is empty, no text node will be created. The created text node will be merged with any adjacent text nodes."

        I have created a patch for this issue.

        Show
        Yash Talwar added a comment - I have reproduced the problem with Xalan Interpretive and XSLTC. The problem is that that when an empty attribute value is encountered, a text node is being created with empty string. Henry Zongaro has helped finding the XSLT 1.0 specs. that suggest a text node with empty string should not be created. URL http://www.w3.org/TR/xslt#value-of has the following information: "The xsl:value-of element is instantiated to create a text node in the result tree. The required select attribute is an expression; this expression is evaluated and the resulting object is converted to a string as if by a call to the string function. The string specifies the string-value of the created text node. If the string is empty, no text node will be created. The created text node will be merged with any adjacent text nodes." I have created a patch for this issue.
        Hide
        Yash Talwar added a comment -

        Brian Minchau to reveiw the submitted patch.

        Show
        Yash Talwar added a comment - Brian Minchau to reveiw the submitted patch.
        Hide
        Brian Minchau added a comment -

        Assigning a reviewer

        Show
        Brian Minchau added a comment - Assigning a reviewer
        Hide
        Brian Minchau added a comment -

        I have reviewed the patch and it looks fine to me.

        However, I can not apply the patch to CVS as-is becuause the patch for XALANJ-2033 which covered a similar early return issue.

        Comments in the patch are fine, but the if(...) at the start of the method should be:
        if (length == 0 ||
        (m_inEntityRef && !m_expandDTDEntities))
        return;

        Show
        Brian Minchau added a comment - I have reviewed the patch and it looks fine to me. However, I can not apply the patch to CVS as-is becuause the patch for XALANJ-2033 which covered a similar early return issue. Comments in the patch are fine, but the if(...) at the start of the method should be: if (length == 0 || (m_inEntityRef && !m_expandDTDEntities)) return;
        Hide
        Yash Talwar added a comment -

        Created patch to include fix for XALANJ-2033 as suggested by Brian.

        Show
        Yash Talwar added a comment - Created patch to include fix for XALANJ-2033 as suggested by Brian.
        Hide
        Yash Talwar added a comment -

        Patch applied to currentCVS.

        Show
        Yash Talwar added a comment - Patch applied to currentCVS.
        Hide
        Brian Minchau added a comment -

        ds, as the issue reporter please confirm that this is fixed to your satisfaction in the Xalan-J 2.7 release, that was released on Aug 8, 2005, then we can close this issue.

        Show
        Brian Minchau added a comment - ds, as the issue reporter please confirm that this is fixed to your satisfaction in the Xalan-J 2.7 release, that was released on Aug 8, 2005, then we can close this issue.
        Hide
        Brian Minchau added a comment -

        Closing this issue since 'ds' has not responded to verify the fix, and it is over a year
        since the fix went out with Xalan 2.7.0

        Show
        Brian Minchau added a comment - Closing this issue since 'ds' has not responded to verify the fix, and it is over a year since the fix went out with Xalan 2.7.0

          People

          • Assignee:
            Yash Talwar
            Reporter:
            ds
            Reviewer:
            Brian Minchau
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development