DO NOT REPLY [Bug 13850] New: - xsltc type match problem with docbook test in xsltmark

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13850>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13850

xsltc type match problem with docbook test in xsltmark

           Summary: xsltc type match problem with docbook test in xsltmark
           Product: XalanJ2
           Version: CurrentCVS
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Critical
          Priority: Other
         Component: org.apache.xalan.xsltc
        AssignedTo: xalan-dev@xml.apache.org
        ReportedBy: tom.amiro@sun.com


We run a docbook test as part of a customized XSLTCMARK performance 
test suite. 

I caught a regression on the docbook testcase in the xsltmark performance
benchmark with XSLTC. Santi thought it had something to do with the
Xalan/XSLTC integration extension work Morris Kwan recently did.


Here is the error message:

  docbook:            docbook.xsl         ERROR:  'Cannot convert
argument/return type
           in call to method
'org.apache.xalan.lib.ExsltSets.leading(reference, reference)''
javax.xml.transform.TransformerConfigurationException: Could not compile
stylesheet
        at
org.apache.xalan.xsltc.trax.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:662)

        at
com.datapower.xsltmark.XSLTCTRAXDriver.loadStylesheet(XSLTCTRAXDriver.java:77)

        at com.datapower.xsltmark.XSLTMark.runBenchmark(XSLTMark.java:72)
        at com.datapower.xsltmark.XSLTMark.main(XSLTMark.java:509)

I attached the docbook stylesheet where the problem seems to be happening
and
here is a snippet that might help you understand it.

 <xsl:template name="unwrap.p">
   <xsl:param name="p"/>
   <xsl:choose>
    <xsl:when test="function-available('exsl:node-set')
                    and function-available('set:leading')
                    and function-available('set:trailing')">
      <xsl:apply-templates select="exsl:node-set($p)" mode="unwrap.p"/>
    </xsl:when>
    <xsl:otherwise>
      <xsl:copy-of select="$p"/>
    </xsl:otherwise>
   </xsl:choose>
 </xsl:template>


Here's another snippet from the same xsl file (html-rtf.xsl)

  <!-- This template should never get called if these functions aren't
available -->
  <!-- but this test is still necessary so that processors don't choke on
the -->
  <!-- function calls if they don't support the set: functions -->
  <xsl:if test="function-available('set:leading')
                and function-available('set:trailing')">
    <xsl:choose>
      <xsl:when test="$blocks">
        <xsl:variable name="leading" select="set:leading($nodes,$blocks)"/>
        <xsl:variable name="trailing" select="set:trailing
($nodes,$blocks)"/>

Morris Kwan responded:

I can reproduce the problem. I would not call it a regression because the
underlying problem exists before the extension integration. It did not show
up because previously function-available("set:leading") returned false and
the block inside <xsl:if> did not get evaluated. With the extension
changes, function-available() returns true. Now more code runs through the
compiler and you have a better chance to uncover a problem which was not
caught before.

The problem has something to do with the type of a <xsl:param>. In the
instruction set:leading($nodes,$blocks), both $nodes and $blocks are
parameters. The default type of a parameter is Reference. However, the
set:leading function expects the two arguments to be of type nodeset. The
types do not match and the exception is thrown.

I also notice other problems when using parameters in function arguments. I
am going to find a solution for this problem. I will let Santiago review
the solution before putting it in.