> 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,

then

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

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



=====
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