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

Subject: Re: [xsl] Re: XPath 2.0: Problems with the two boolean constants true and false
From: Dimitre Novatchev <dnovatchev@xxxxxxxxx>
Date: Thu, 9 Oct 2003 06:23:29 -0700 (PDT)
> I don't understand the point that you're making here. All the types
> have lexical (string) representations of their values, and there is
> never implicit casting from those string representations to the
> relevant value. For example, you will get type errors if you have a
> template whose parameters are typed as xs:date or xs:double if you
> pass strings to those parameters, as in:
>   <xsl:template name="AddDateAndDuration" match="test:*">
>     <xsl:param name="arg1" as="xs:date"/>
>     <xsl:param name="arg2" as="xdt:yearMonthDuration"/>
>     <xsl:value-of select="$arg1 + $arg2"/>
>   </xsl:template>
> with the call:
>    <xsl:apply-templates select="document('')/*/test:*[1]">
>      <xsl:with-param name="arg1" select="'2003-10-08'"/>
>      <xsl:with-param name="arg2" select="'P2M'"/>
>    </xsl:apply-templates>
> In what way is xs:boolean any different?

You are right -- in no way is xs:boolean different -- now.

But if the Data Model were saying that 0 and 1 are not simply "string
representations" (note that I didn't use '0' and '1' in my previous
example but just 0 and 1 -- that is not the strins '0' and '1')
but that 0 and 1 are *the* two xs:boolean constants,


it would make difference as the result of evaluating a boolean expression
would be not a "representation" but a real (or native, or genuine) boolean

Isn't it natural for a type to have its own genuine values and not only a


Dimitre Novatchev. -- the home of FXSL

Do you Yahoo!?
The New Yahoo! Shopping - with improved product search

 XSL-List info and archive:

Current Thread