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