I've also started using the XQuery-required explicating casting of values
even though XSLT usually lets you get away with implicit casting, because it
makes it clearer to me what my intent was (and makes it easier to copy XPath
expressions into XQuery, if that's something you need to do).
Just to clarify this, we could perhaps use the terms
* strong casting - as performed using the "cast as" expression or a constructor
function like xs:integer()
* weak casting - as performed by the (badly-named) function conversion rules.
Includes atomization, numeric promotion, and conversion of xs:untypedAtomic to
the required type
* exact match - the supplied value must match the required type exactly.
XSLT uses weak casting (of the supplied value to the declared/required type)
for arguments in function calls, parameters of templates, and variable bindings
(both local and global variables).
XQuery uses weak casting for arguments of function calls, but exact match for
variable bindings.
So XSLT allows
<xsl:variable name="x" as="xs:double" select="2"/>
but XQuery doesn't allow
declare variable $x as xs:double := 2;
Note that "let" expressions in XPath don't allow a required type to be
declared. One reason for this is that XSLT and XQuery wouldn't agree on whether
weak casting or exact match should be used in this situation.
A small number of contexts effectively do implicit strong casting to xs:string:
these include the arguments to concat() and string-join(), and embedded
expressions in attribute constructors / AVTs.
Michael Kay
Saxonica
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--