Boolean

Mike Brown

test="$foo" is like test="boolean($foo)". Following the rules for XPath boolean(), and the XSLT spec's info on result tree fragments, the test will be true if $foo...

Result tree fragments are true because they always contain a 'root' node.

Wendell Piez

<xsl:template match="sales">
   <h2>Regions Selling More than 300 Units:</h2>
   <xsl:for-each select="region">
     <xsl:variable name="units_gt_300">
       <xsl:choose>
         <xsl:when test="number(units) &gt; 300">
           <xsl:value-of select="true()"/>
         </xsl:when>
         <xsl:otherwise>
           <xsl:value-of select="false()"/>
         </xsl:otherwise>
       </xsl:choose>
     </xsl:variable>
     <xsl:if test="$units_gt_300='true'">
       <h3><xsl:value-of 
     select="concat(@name, ' (', units, ' units)')"/></h3>
     </xsl:if>
   </xsl:for-each>
</xsl:template>
    

Note the assignment of Boolean true() or false() to the variable, and the <xsl:if> test. Why can't the latter be simply:

   <xsl:if test="$units_gt_300">

i.e., why the need to test vs. the string value "true"? Does using the true() and false() functions in a variable coerce their return values to string type rather than their "native" Boolean?

It's not the boolean test that's coercing $units_gt_300 to a string ... it's the original <xsl:value-of select="true()"/> -- or false() -- that creates it....

Note this is different from saying <xsl:variable name="units_gt_300" select="true()"/> where the assigned value is the Boolean.

Obscure little corners of the spec....

Evan Lenz expands:

Ah yes, boolean conversion of result tree fragments. The first thing you need to know to explain the behavior of your stylesheet is that whenever an <xsl:variable> element is not empty, it will always return a value of type Result Tree Fragment. More to the point, <xsl:value-of/> always copies the *string-value* of the designated XPath expression, boolean or otherwise.

Try hard-coding the true() value, first as a child of <xsl:variable> and then as the value of the select attribute.

This returns an RTF:

  <xsl:variable name="units_gt_300">
    <xsl:value-of select="true()"/>
  </xsl:variable>

This returns an XPath boolean:

  <xsl:variable name="units_gt_300" select="true()"/>

Your if test will evaluate differently depending on the variable's type.

In the first case, the comparison is between an RTF and a string. The processor first converts the RTF to a string and subsequently performs a string comparison. Thus, you are effectively comparing 'true' with 'true' or 'false' with 'true'. If you changed the if test to "$units_gt_300" or "$units_gt_300=true()" (same thing), it would not work correctly, because 'true' and 'false' will always evaluate to true, being non-empty strings.

In the second case, the comparison is between a boolean and a string. The string is first converted to a boolean and then the comparison is made. If the string you include is not empty, then it will always convert to true, which effectively gives you the same result as "$units_gt_300" or "$units_gt_300='anything'".

This behavior is described in the XPath spec as follows:

P.S. For all practical purposes, a Result Tree Fragment containing just text will look and act the same as an XPath string containing that text, except that an RTF with an empty string value will still convert to boolean true, just like a node-set containing one root, which is what it will be in the future after XSLT 1.1 rids itself of the confusing RTF data type.

Mike Kay adds:

The <xsl:value-of> converts the booleans to strings; and the use of xsl:variable with content creates a result tree fragment containing this string as a child node. So you are quite right, test="$units_gt_300" would always succeed, because it is testing whether the node-set equivalent to the RTF contains any nodes: converting an RTF to a boolean always returns true (despite what my book says on page 81 [sorry!].

But why don't you just write <xsl:variable name="units_gt_300" select="units &gt; 300"/> That way you get a variable whose type is boolean.

Steve Muench

| Consider these potential siblings:
| 
| <object type="building">hospital</object>
| <object type="building">school</object>
| <object type="building">bank</object>
| 
| How can I test for BOTH the value of type= AND for the text contents of
| <object>?
	

test="object[@type='building' and .='hospital']"

If there might be whitespace in the text content of <object>, you might consider:

test="object[@type='building' and normalize-space(.)='hospital']"

Mike Kay

Not the same thing at all!

A != A, where A is a node-set, is true if there is some node in A that is unequal to another node in A. So "not(A != A)" is true if all the nodes in A have the same string value (brilliant, Jeni!). While "A = A", of course, is true if any node in A has the same value as some node in A - which will always be true, so long as A is not empty, because every node is equal to itself.

(This is actually the first time I have ever seen A != B, where the operands are both multi-node node-sets, used for a serious purpose; perhaps I will have to reconsider my previous assumption that it wasn't worth optimising!).