[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

[xsl] Re: XPath 2.0: Problems with the two boolean constants true and false

Subject: [xsl] Re: XPath 2.0: Problems with the two boolean constants true and false
From: "Dimitre Novatchev" <dnovatchev@xxxxxxxxx>
Date: Tue, 7 Oct 2003 07:10:06 +0200

> Yes, this is a bug (or at any rate, it's a XSLT 2.0 feature that I
> haven't implemented yet but that isn't on my published list of features
> that I haven't implemented yet - there are probably quite a few of
> these, and for the time being I am treating them as bugs in the
> documentation rather than bugs in the code).
> What's actually happening is that no type checking or conversion of
> parameters is being done on the apply-templates call, but the code that
> references the parameters is assuming they are of the declared type. The
> net result is that the "A and B" is taking the effective boolean value
> of the value actually passed in the parameters, and the effective
> boolean value of the string 'false' is true.

Actually, the parameters are converted to booleans but not using the cast

In reality the convertion is done using the EBV of the supplied arguments.

This makes 'false' into true

This template will work OK:

  <xsl:template name="And" match="*[namespace-uri()='allTrue-And']">
    <xsl:param name="arg1"/>
    <xsl:param name="arg2"/>
         <xsl:value-of select="xs:boolean($arg1) and xs:boolean($arg2)"/>

Here I deliberately do not specify the type of the parameters and perform
the conversion in my own code.

So what is the benefit of typing? In this case it simply does not work and I
have to do it myself in code -- I am forced to produce ugly code because the
so advertised typing does not work.

The template that applies the current template is a generic one -- it may
apply many different templates and cannot provide conversions of any type
and cannot assume that its own parameters are of a type more specific than

No problem like this would have existed if the value of a boolean output by
xsl:value-of  or xsl:copy-of or xsl:sequence was 1 or zero instead of 'true'
or 'false' and if 0 and 1 were valid boolean values. Or if boolean() and
xs:boolean() had the same definition/behaviour -- that is
     xs:boolean('false') = false
    boolean('false') = false

This is the original problem I wanted to describe.

The solution to this problem is to represent the boolean values only as 1 or
0 and to accept 0 and one as valid xs:boolean. (I understand that changing
boolean() to behave the same as xs:boolean() is out of the question, because
there must be compatibility with XPath 1.0)

It is obvious to me that changing the XPath data model to encorporate this
would be an improvement, because it would eliminate this type of problems.


Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

Current Thread