[ 
https://issues.apache.org/jira/browse/XALANJ-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579717#action_12579717
 ] 

David Marston commented on XALANJ-2438:
---------------------------------------

The input file can be shared across test cases. There should be separate 
stylesheets for each increment of difficulty. You submitted:
  <xsl:key name="seperator-key" match="seperator" use="@level" /> 
  <xsl:key name="para1-key" match="para[preceding::seperator[1]/@level = 1]" 
use="1" /> 
  <xsl:key name="para2-key" match="para[preceding::[EMAIL PROTECTED]@level = 
2]]" use="2" /> 
  <xsl:key name="level-key" match="para" use="preceding::seperator[1]/@level" 
/> 
  <xsl:key name="structure-key" match="*" 
use="generate-id(((ancestor::*|preceding::*)[ self::document or ( @level and 
(not(current()/@level) or (@level < current()/@level)) ) ])[last()])" /> 

The first one, name="seperator-key", is probably tested adequately already. One 
step up in difficulty is to put a predicate on the match pattern, as in
match="[EMAIL PROTECTED]"
then have two sequential predicates, then nested predicates as in the 
name="para1-key" example.

The name="structure-key" key has several complications that should be isolated:
use of a union
predicates on a parenthesized nodeset
predicates on self or preceding (I think predicates on ancestor might be 
covered)
use of [last()]
use of [last()] against preceding
use of and/or/not in a predicate
use of generate-id() in general in keying
use of generate-id() as shown, on an element that is essentially unrelated to 
the one that was matched

I hope that clarifies what I'm advocating. I expect that the code will pass 
some of those cases, but apparently not all.

> [PATCH] XSLTC ignores XPath predicates in xsl:key elements
> ----------------------------------------------------------
>
>                 Key: XALANJ-2438
>                 URL: https://issues.apache.org/jira/browse/XALANJ-2438
>             Project: XalanJ2
>          Issue Type: Bug
>          Components: XSLTC
>    Affects Versions: The Latest Development Code
>         Environment: Linux and Windows XP with Sun JRE 1.5.0_14, 1.5.0_15, 
> 1.6.0_04 and 1.6.0_05
>            Reporter: Helge Schulz
>            Priority: Blocker
>             Fix For: The Latest Development Code
>
>         Attachments: PredicateInKey-Xalan-SVN-r584164.patch, 
> PredicateInKey-XSLT-Test.jar, PredicateInKey.out, PredicateInKey.xml, 
> PredicateInKey.xsl
>
>
> The Xalan XSLT compiler (XSLTC) ignores XPath predicates in xsl:key
> elements since the class 'org.apache.xalan.xsltc.compiler.Stylesheet'
> was rearranged in august 2003 to reorder the compilation of top level
> XSLT elements (including keys) to respect dependencies between global
> XSLT variables and keys. Method 'compileTopLevel' was changed to emit
> code also for key elements and not emit code calling the method generated
> by 'compileBuildKeys'. For this reason the byte code for each key element
> is generated twice: First time into generated method 'buildKeys' from
> 'compileBuildKeys' and second time into generated method 'topLevel'
> from 'compileTopLevel'. Method 'buildKeys' is still necessary, because
> it is called by the XSLT 'document' function, if additional input
> documents are loaded later.
> Unfortunately the translate method of some XPath elements expected to
> be called only once and they remove sub elements while their first execution.
> So all XPath predicates get lost in class 
> 'org.apache.xalan.xsltc.compiler.FilterExpr'
> and 'org.apache.xalan.xsltc.compiler.Step' by a remove operation on
> the '_predicates' container while the execution from 'compileBuildKeys'.
> So 'compileTopLevel' generates wrong code for all key elements containing
> predicates in their XPath expressions.
> The attached patch changes the 'FilterExpr' and 'Step' class to use an
> index variable to determine the current predicate and to not remove them.
> This patch was tested with the current Subversion version of Xalan
> (last change of Xalan tree in revision 584164) and with Sun JDK 1.5.0_14,
> 1.5.0_15, 1.6.0_04 and 1.6.0_05.
> This bug exists also in Sun JRE 1.6 (1.6.0 up to 1.6.0_05) and JRE 1.5
> (since 1.5.0_12 up to 1.5.0_15) in classes
> 'com.sun.org.apache.xalan.internal.xsltc.compiler.FilterExpr' and
> 'com.sun.org.apache.xalan.internal.xsltc.compiler.Step'. The attached
> test JAR file contains also patches for these versions and fixes in form
> of JAR files to be installed into '../jre/lib/endorsed' directories of
> Sun JRE installations. The last Sun JRE version with correct handling
> of xls:key elements is 1.5.0_11.
> Please add the attached test files to the Xalan test suite. I have
> released them under Apache license  version 2.0.
> Helge Schulz - OpenSHORE.org

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to