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.
Michael Kay
-----Original Message-----
From: owner-xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
[mailto:owner-xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com] On Behalf Of
Dimitre Novatchev
Sent: 06 October 2003 11:15
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: RE: [xsl] XPath 2.0: Problems with the two boolean
constants true and false
I see two problems with the boolean constants true and false:
1. They cannot be used in an XPath expression -- cannot be
distinguished from child::true and child::false
There are no constants "true" and "false". As in XPath 1.0,
the truth
values are represented by the function calls true() and false(). No
change here from 1.0.
2. boolean('false') is true. This is especially confusing
and may be the source of many programmers' headaches.
Again, no change here from 1.0. I haven't seen this cause
much problem
in practice, though the introduction of xs:boolean alongside
[fn:]boolean may be confusing. xs:boolean() uses the schema
rules: '0'
and 'false' give false, '1' and 'true' give true, any other
string is
an error.
Because of these I chose in my code to use functions
returning xs:integer (0 and 1) and for templates to write
code like the following:
<xsl:template name="And"
match="*[namespace-uri()='allTrue-And']">
<xsl:param name="arg1"/>
<xsl:param name="arg2"/>
<xsl:value-of select="number(number($arg1) and
number($arg2))"/>
</xsl:template>
Am I wrong? Is there a way to overcome the above problems?
It seems odd to me to use numbers instead of booleans because you
don't like the string-to-boolean conversions. If you don't like the
string-to-boolean conversions just don't use them; you can
still use
booleans!
My confusion is due to the following:
This transformation:
<xsl:stylesheet version="2.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
xmlns:xs="http://www.w3.org/2001/XMLSchema";
xmlns:f="http://fxsl.sf.net/";
xmlns:test="my:test"
exclude-result-prefixes="f xs test"
<xsl:output omit-xml-declaration="yes"/>
<xsl:template match="/">
<xsl:apply-templates select="document('')/*/test:*[1]">
<xsl:with-param name="arg1" select="'false'"/>
<xsl:with-param name="arg2" select="1"/>
</xsl:apply-templates>
</xsl:template>
<test:test/>
<xsl:template name="And" match="test:*">
<xsl:param name="arg1" as="xs:boolean"/>
<xsl:param name="arg2" as="xs:boolean"/>
<xsl:value-of
select="xs:boolean(xs:boolean($arg1) and
xs:boolean($arg2))"/>
</xsl:template>
</xsl:stylesheet>
Produces:
true
But
<xsl:value-of
select="xs:boolean(xs:boolean('false') and xs:boolean(1))"/>
produces:
false
Is this a bug in Saxon 7.7?
=====
Cheers,
Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list