RE: Re: What is the best way to cast integer to string

> Hey all,
> 
> This thread and another recent one regarding X(Path|SL) 2.0 
> has raised a few questions for me.  I am late to the party 
> and I wonder if someone can direct me to language in the 
> recent drafts regarding the behavior of those functions which 
> rely upon
>http://www.w3.org/TR/xmlschema-2/

>over a merely well-formed instance, that is, for which no schema is
available. In the absence 
>of type information, the behavior of many of the functions of XPath2.0
would seem to be 
>indeterminate.  Where's the prose in the draft that answers to this
situation?

A "Basic XSLT Processor" supports atomic values conforming to the
built-in types defined in XML Schema. So you can do things like

xs:duration("P10H30M") + xs:duration("P12H15M")

to add two durations. 

With a Basic XSLT Processor (i.e. one that does not support schema
validation), the nodes in a source document will always be untyped. If
an attribute contains a dateTime, then it will be cast automatically to
an xs:dateTime if you use it in a function call where a dateTime is
required. So you can do things like:

get-year-from-dateTime(@date-of-birth)

This will fail with a run-time error if the attribute value is not
lexically a legal dateTime.

Michael Kay


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list