[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XPath 2.0: Problems with the two boolean constants

Subject: 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
xs boolean valid value
> 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
   xs:boolean($arg).

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)"/>
  </xsl:template>

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
item().

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
and
    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.



=====
Cheers,

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







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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.