This content has been marked as final. Show 6 replies
What's your XSLT processor?
This works on Saxon and Oracle's :
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:key name="versionGroup" match="/Root/VersionGroup" use="@inactive"/> <xsl:template match="/"> <xsl:variable name="verGpEnabled" select="key('versionGroup', 'false')/@enabled"/> <xsl:choose> <xsl:when test="$verGpEnabled='true'"> <xsl:text> TRUE </xsl:text> </xsl:when> <xsl:when test="$verGpEnabled='false'"> <xsl:text> FALSE </xsl:text> </xsl:when> </xsl:choose> </xsl:template> </xsl:stylesheet>
<Root> <VersionGroup inactive="false" enabled="false" /> </Root>
I am using XML Spy's processor, but actually that shouldn't be a problem. Because when I took your example, I am seeing the results in a correct way. Let me re-look at the huge XML which I have and take that particular node to see if there is an issue there. For obvious reasons I cannot post my whole XML and XSLT here, but let me try to bring to a point where I can post the exact snippet of the xml and xslt, without causing any security/violation concerns and we'll see whats happening there.
It should be noted that xsl:key acts like a index of pages with the selected keywords... The return of the keyword can be a set of pages where it appears. Same here. If it actually returns a kind of node-set, the boolean test will be cast to true if it is not empty.
Hence, you've to decide the position (ie, which one) you want to test or do a xsl:for-each on the return and decide how you want to true/false being appeared over the set. Take the simplest case of position interested is always the first node, this will be done like this.
<xsl:choose> <xsl:when test="$verGpEnabled = 'true'"> <xsl:text> TRUE </xsl:text> </xsl:when> <xsl:when test="$verGpEnabled = 'false'"> <xsl:text> FALSE </xsl:text> </xsl:when> </xsl:choose>
I feel terribly sorry that I mislead myself on this one and on the way mislead you. Though the multiplicity of the return is on the right track, the deduction was done a bit too hash.
Here is the correct systematics.
 If the key return nothing, no node-test will ever be done. Hence, there won't be a worry of error neither a print out of either TRUE or FALSE. The xsl:choose just let pass, since the op's version does not contain a branch xsl:otherwise (that's why).
 Where the return of the key is one node or multiple node, and suppose it contains true or false like this (true, false, false,...) or whatever. This is the reason why thing happened.
[2.1] It actually depends then on the order of xsl:when. If <xsl:when test="... = 'true'"> comes before the one of testing false, then if the set (true, false, etc...) contain ever one (at any position), it will make a success test. I mean even this order (false, ..., true,...) or (true,...,false,...). If the order of appearence of xsl:when testing true and false is reversed, ie, <xsl:when test="...='false'"> comes before the ='true', the same set containing both true and false entries will be this time as it 'false' won out. (It is not pretty for that dependence on the order of xsl:when.)
[2.2] If the return set contains only false, ie, (false, false,...), then xsl:when for false will win out and this time xsl:whe for true has no chance. Same for the case (true, true,...) with opposite effect.
 The return symbolically represented (..., true, ... , false, ...) may even behave very closely with xslt 2.0 (though here it is not xslt 2.0, it still is xslt 1.0) sequence. Hence, the ordering, by chance according to the capprice of the xslt author, plays the role clearly. Since (..., true, ... , false,...) = true is a truthful statement, and that (..., true, ... , false, ...) = false (symbolically) is also a truthful statement if it is a xslt 2.0 sequence proper.
I try to rectify the misfortunate misleading detail, and here I've done so. Sorry again!
Edited by: tsuji on Dec 2, 2011 4:19 AM