[
https://issues.apache.org/jira/browse/XALANJ-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528173
]
Deborah Pickett commented on XALANJ-2399:
-----------------------------------------
Hi David,
It appears that in the process of producing a small test case, I have
oversimplified the problem to the point where it appears that a workaround
would suffice. Sorry, but it won't.
All the <xsl:key> elements are in separate stylesheets, which are imported into
a master stylesheet. This is an encapsulation requirement brought about by the
fact that only the master stylesheet knows which sub-stylesheets are being
imported. The "concept" stylesheet must know only about concepts, and so on.
The literal string isn't always the same as the @type attribute. This might
happen too, if an "article" is a special kind of "concept":
<xsl:key name="group" match="[EMAIL PROTECTED]'article']" use="'concept'"/>
In this case the string "concept" isn't anywhere in the element being matched,
so only a literal will do.
I need the additive-in-spite-of-import-precedence property of keys, so there
isn't another way of implementing this while maintaining the (very important)
encapsulation requirement.
> key() on xsl:key with literal @use returns too many nodes
> ---------------------------------------------------------
>
> Key: XALANJ-2399
> URL: https://issues.apache.org/jira/browse/XALANJ-2399
> Project: XalanJ2
> Issue Type: Bug
> Affects Versions: 2.7
> Environment: Windows XP Pro x64; JRE 1.5.0_12
> Reporter: Deborah Pickett
>
> Using a literal* string value for @use in an xsl:key causes key() to return
> too many nodes in the node-set for that key.
> I define a key in a couple of places (same stylesheet or different, seems to
> behave the same):
> <xsl:key name="name" match="foo" use="'string'"/>
> <xsl:key name="name" match="bar" use="..."/>
> <xsl:key name="name" match="baz" use="..."/>
> It does not seem to matter what the "..." are.
> Calls to key('name', 'string') should give a node-set only of <foo> elements,
> but I also get <bar> and <baz> elements, essentially every node that has a
> presence in the "name" key.
> Calls to key('name', 'never-seen-before-string') return an empty node-set.
> * Or, it seems, an expression that can be optimized into a literal. This
> makes the bug go away:
> <xsl:key name="group" match="[EMAIL PROTECTED] = 'concept']"
> use="concat(substring(@type, 1, 1), 'oncept')"/>
> but this still has the bug:
> <xsl:key name="group" match="[EMAIL PROTECTED] = 'concept']"
> use="concat(substring(@type, 1, 0), 'concept')"/>
> Small test case follows.
> Source document:
> <root>
> <link href="somewhere.xml" type="concept"><linktext>C1</linktext></link>
> <link href="somewhere.xml" type="concept"><linktext>C1</linktext></link>
> <link href="somewhere.xml" type="concept"
> importance="required"><linktext>C1 Prereq</linktext></link>
> <link href="somewhere.xml" type="reference"
> role="cousin"><linktext>R2</linktext></link>
> <link href="somewhere.xml" type="reference"
> role="sibling"><linktext>R1</linktext></link>
> <link href="somewhere.xml" type="reference"
> role="sibling"><linktext>R1</linktext></link>
> <link href="somewhere.xml" type="task"><linktext>T1</linktext></link>
> <link href="somewhere.xml" type="topic"><linktext>X1</linktext></link>
> <link href="somewhere.xml"><linktext>X0</linktext></link>
> <link href="somewhere.xml" type="unknown-thing"
> role="sibling"><linktext>X2</linktext></link>
> <link href="somewhere.xml" type="concept"><linktext>C1</linktext></link>
> </root>
> Stylesheet:
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
> version="1.0">
> <xsl:key name="group" match="[EMAIL PROTECTED] = 'concept']"
> use="'concept'"/>
> <xsl:key name="group" match="[EMAIL PROTECTED] = 'task']" use="'task'"/>
> <xsl:key name="group" match="[EMAIL PROTECTED] = 'reference']"
> use="'reference'"/>
>
> <xsl:template match="/">
> <xsl:apply-templates select="key('group', 'concept')"/>
> </xsl:template>
> </xsl:stylesheet>
> Expected output:
> C1C1C1 PrereqC1
> Output with Xalan-J 2.7.0:
> C1C1C1 PrereqR2R1R1T1C1
> $ java -cp c:/Program\ Files\ \(x86\)/Oxygen\ XML\ Editor\ 8.2/lib/xalan.jar
> org.apache.xalan.xslt.EnvironmentCheck
> #---- BEGIN writeEnvironmentReport($Revision: 1.29 $): Useful stuff found:
> ----
> version.DOM.draftlevel=2.0fd
> java.class.path=c:/Program Files (x86)/Oxygen XML Editor 8.2/lib/xalan.jar
> version.JAXP=1.1 or higher
> java.ext.dirs=C:\Program Files (x86)\Java\jre1.5.0_12\lib\ext
> version.xerces2=Xerces-J 2.9.0
> version.xerces1=not-present
> version.xalan2_2=Xalan Java 2.7.0
> version.xalan1=not-present
> version.ant=not-present
> java.version=1.5.0_12
> version.DOM=2.0
> version.crimson=not-present
> sun.boot.class.path=C:\Program Files
> (x86)\Java\jre1.5.0_12\lib\rt.jar;C:\Program Files
> (x86)\Java\jre1.5.0_12\lib\i18n.jar;C:\Progr
> am Files (x86)\Java\jre1.5.0_12\lib\sunrsasign.jar;C:\Program Files
> (x86)\Java\jre1.5.0_12\lib\jsse.jar;C:\Program Files (x86)\Java\
> jre1.5.0_12\lib\jce.jar;C:\Program Files
> (x86)\Java\jre1.5.0_12\lib\charsets.jar;C:\Program Files
> (x86)\Java\jre1.5.0_12\classes
> #---- BEGIN Listing XML-related jars in: foundclasses.java.class.path ----
> xalan.jar-path=c:\Program Files (x86)\Oxygen XML Editor 8.2\lib\xalan.jar
> #----- END Listing XML-related jars in: foundclasses.java.class.path -----
> version.SAX=2.0
> version.xalan2x=Xalan Java 2.7.0
> #----- END writeEnvironmentReport: Useful properties found: -----
> # YAHOO! Your environment seems to be OK.
--
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]
