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 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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] XPath 2.0: Problems with , Michael Kay | Thread | RE: [xsl] Re: XPath 2.0: Problems w, Michael Kay |
Re: [xsl] hierarchical sorting prob, Mukul Gandhi | Date | [xsl] complex alternative row color, thea |
Month |